dependencies in .so files
Wed, 27 May 1998 22:10:18 +0100 (GMT+0100)
> Luke Tierney writes:
> firstname.lastname@example.org wrote:
> > So, I try:
> > 1) I modify src/unix/dynload.c changing the flag of dlopen
> > from RTLD_LAZY to (RTLD_LAZY | RTLD_GLOBAL)
> I'm not sure this is properly and reliably supported on all UNIX
> platforms. It doesn't seem to be in the standard Windows and Mac
> compilers. That is, MS VC++ and Borland C++ don't seem to let you
> creade DLL's with undefined symbols. Watcom does seem to allow it, but
> I'm not certain how reliable it is there.
If I understand, under Windows , you have to follow your strategy B (recursive
> Also you need to consider what happens at runtime if a function is
> called and finds an unresolved symbol. On some systems a signal might
> be sent that can be caught (HP-UX sends SIGABRT, but I'm not sure I
> would want to catch all those), but this will need to be checked out
> on every different system. Having any problems reported at load time
> seems like a safer solution -- I have gone the other way and switched
> to using RTLD_NOW for this reason (and because that seems the least
> common denominator accross UNIX/Win32/Mac).
I agree. This point is however indipendent from linking a
shared library which needs another shared library. This has
to do with the RTLD_LAZY flag not with the RTLD_GLOBAL one.
In the example I used the RTLD_LAZY flag only because the current version of
R uses it.
The use of RTLD_NOW will also make debugging easier.
An example was the missing routines
problem in the locfit package (a couple of messages a month ago).
I found out that the shared library misses a couple of routines
compiling the package under Windows. But, under Unix, no
errors in building the library.
But, if you try to use the R function which calls
a C function with an unresolved routine you get a segmentation fault
(or at least, I got it).
> The alternative is to use the OS's ld or equivalent to create a
> library that knows what it needs to call at link time by telling ld
> what other shared libraries it needs; in this case
> > a.so: a.o
> > gcc -shared -o a.so a.o
> > b.o: b.c
> > gcc -fPIC -c b.c
> > b.so: b.o
> > gcc -shared -o b.so b.o
> would change to
> b.so: b.o
> gcc -shared -o b.so b.o a.so
> Mutually recursive libraries can be handled this way on most UNIX
> systems I think; for Win32 there are some standard tricks involving
> .def and .lib files (that I can't remember in detail but I think I
> found them once on MS's web site) for making DLL's that are mutually
> recursive. I haven't looked into mutual recursion on the Mac.
Under Linux, the problem with this approach is that the dynamic
linker (ld.so) must find a.so at runtime. I have just tried
on the previous example but I can't load the so builded b.so in R.
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: email@example.com