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:
Firefox$LDENV : LD_WARN=1 LD_LIBRARY_PATH=/Firefox:
? 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).
Ok.
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 <[EMAIL PROTECTED]>
Peter Naulls <[EMAIL PROTECTED]> 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.
Lee.
_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
