[gccsdk] Dynamic library path handling

Lee Noar leenoar at sky.com
Sun Jul 6 03:44:11 PDT 2008

Peter Naulls wrote:
> I've made a local terrible hack (but seemling robust) to include the 
> riscosify handling into libdl, so that it has some more sophisticated
>  and consistent handling than the current simplistic processing.
> This is a cut down version of the code that is used in SCL, for this
> specific usage.  I'll check this in in due course.
> However, my question is, what should be the behaviour for finding 
> libraries?   For example, I need to set:
> set LD$Env "LD_WARN=1 LD_LIBRARY_PATH=/Firefox:"
> And note the slightly unsatisfactory slash due to riscosify; but as a
>  general solution this isn't great.

I agree that it's not the best solution because it applies to all
programs rather than just the current one as is the case with Linux. In
fact that applies to all LD_* variables.

> !GCC sets:
> GCCSOLib$Path : SharedLibs:lib
> But it's not clear to me that this is used anywhere, and in any case 
> that is the default search path.

GCCSOLib$Path is used by RISC OS GCC only, so that the linker can find 
the shared libraries.

> But a solution like this would be fine, using the binary name as a
> basis, as we do for other things.

So, you would like to use something like:


? I should be able to add something like this.

> I also changed the bogus (in the case of RISC OS) "/lib" search path
> to an empty string, which makes absolute paths work (or more
> specifically, paths relative to a RISC OS path variable).


> In my testing I also saw that errno wasn't being set from a dlopen 
> failure - not sure of the best way to fix this.

AFAICT, the dynamic loader doesn't actually set errno, in fact, I think 
it generally avoids accessing it.

I'm currently working on a port of v2.7.0 of the dynamic loader which 
should provide more features and better handling of shared libraries. 
It's a lot more complex than v1.9.9 though and is an integral part of 
glibc so it'll be a while before I have something that works.

Peter Naulls wrote:
> In message <29fc69ba4f.peter at chocky.org>
>           Peter Naulls <peter at chocky.org> wrote:
>> Finally, I see this, which I haven't investigated yet:
>> Text relocation of data symbol '' found: Firefox:libxlibrgb/so (offset
>> 0x16EC0)
>> Which is presumably due to this library being misformed.
> This is actually mentioned in the manual, although reporting an error
> about a blank symbol could be improved.  The real issue in this case was
> the library linking to static Chox11 and DeskLib.  It would make a lot
> more sense if the linker produced an error, rather than waiting until
> runtime, if that's at al possible.

It should be possible, after all, the linker does mark the library as 
having text relocations by way of a TEXTREL entry in the dynamic 
segment. If I can track that code down, then I can issue an error instead.


More information about the gcc mailing list