From guido@sirio.stat.unipd.it  Thu May 28 11:34:56 1998
From: guido@sirio.stat.unipd.it (guido@sirio.stat.unipd.it)
Date: Thu, 28 May 1998 11:34:56 +0100 (GMT+0100)
Subject: dependencies in .so files
In-Reply-To: <199805280827.KAA07151@sophie.ethz.ch> from "Martin Maechler" at May 28, 98 10:27:50 am
Message-ID: <19980528103456.3200.qmail@sirio.stat.unipd.it>

Martin Maechler writes:
> 
> >>>>> "Guido" == Guido Masarotto <guido@sirio.stat.unipd.it> writes:
> 
>     >> From the dlopen man page:
>     Guido> void *dlopen (const char *filename, int flag);
>     Guido> ................................................
>     Guido> RTLD_GLOBAL may be or'ed with flag
>     Guido> in which case the external symbols defined in the library will be
>     Guido> made available to subsequently loaded libraries.
>  
>     Guido> So, I try: 
>     Guido> 1) I modify src/unix/dynload.c changing the flag of dlopen
>     Guido> from RTLD_LAZY to (RTLD_LAZY | RTLD_GLOBAL)
> 
> R-core: 
> 	Shall we do this, for 0.62?  -- or even try to have "configure" find out
> 	if  RTLD_GLOBAL  is supported on the given system?
If I can give suggestions:
1) Independently from the RTLD_GLOBAL flag, I will change RTLD_LAZY to
   RTLD_NOW. As Luke T. summarized yesterday in this way a shared library
   which cannot resolve all its symbols (in R.binary or in other libraries)
   cannot be load. This give three   advantages:
   a) At least under Linux, if I call a dynamic linked routine which
      cannot resolve its dependencies, I get a segmentation fault and
      R exit. Of course, we can try to intercept this problem but
      as also Luke noted, it is difficult to be sure that all the systems 
      will trigs an  appropriate signal; in addition
   b) debugging of a shared library becomes simple; at least, we are
      sure that all the functions in the library can be called.
   c) This correspond to the standard for not Unix machine; I am
      sure for Windows but, if I remember, Luke said also for the Mac.
   Perhaps, if a library cannot be loaded, the corresponding dlerror()
   string should be used for giving to the user some information
   on why.
2) Coming to RTDL_GLOBAL; here the question is the one raised by
   Luke: portability. I suppose that the solution suggested by
   Luke (use "recursive" shared libraries)  is more portable than mine. 
   After a first failure, I was   able to run my "silly" example setting 
   the LD_LIBRARY_PATH shell variable,i.e., instructing ld.so about where 
   to search.
   

> Guido:  Have you ever looked at 0.62  (and porting it to Win32) ?
> 	(get it from <CRAN>/src/devel/R-snapshot.tar.gz)
I had no time. I downloaded a snapshot next week but I didn't make
any trial. Is the unix/system.c changed a lot? I have just looked
to it now and it seems quite similar to the 0.61.x one.

To all the R people: have a nice day.
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


dependencies in .so files
guido@sirio.stat.unipd.it