dependencies in .so files

[guido@sirio.stat.unipd.it]

 > Luke Tierney writes:
 > 
 > guido@sirio.stat.unipd.it 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 
 shared libraries). 
 
 > 
 > 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.
 guido m.


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._