Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

[Tim Mooney]

In regard to: Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS, Gary V....:

>> And if libltdl_cv_sys_dlopen_deplibs=yes is true for a platform but
>> the platform loader does not honor RPATH in shared libraries and a
>> shared library being dlopen'ed has a dependency on another library
>> whose path is not in the application RPATH, should
>> libltdl_cv_sys_dlopen_deplibs still be "yes" for this platform?
>
>No, on reflection, I don't think it should.  This is a subtlety that is worth
>documenting for future porters, so I will find somewhere to add it to the
>distribution presently.

Below is the patch I mentioned on the main libtool mailing list.

Tim
-- 
Tim Mooney                              address@hidden
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


--- libtool-1.4b.orig/ChangeLog Mon Jul  9 17:02:09 2001
+++ libtool-1.4b/ChangeLog      Mon Jul 16 18:08:59 2001
@@ -0,0 +1,6 @@
+2001-07-16  Tim Mooney <address@hidden>
+
+       * doc/libtool.texi: Add a note about the dlopen deplibs issue,
+       including the issue with whether or not any RPATH is used by the
+       loader to find deplibs.  Several additional minor cleanups.
+
--- libtool-1.4b.orig/doc/libtool.texi  Mon Jun 25 19:37:08 2001
+++ libtool-1.4b/doc/libtool.texi       Mon Jul 16 18:10:20 2001
@@ -201,8 +201,9 @@

 * References::                  Finding more information.
 * Compilers::                   Creating object files from source files.
+* Dynamic loading::             Using @code{dlopen()} or its logical 
equivalent.
 * Reloadable objects::          Binding object files together.
-* Multiple dependencies::      Removing duplicate dependant libraries.
+* Multiple dependencies::       Removing duplicate dependant libraries.
 * Archivers::                   Programs that create static archives.

 @end detailmenu
@@ -2897,6 +2898,15 @@
 on platforms which don't support dlopening.  If the module depends on any
 other libraries, make sure you specify them either when you link the module
 or when you link programs that dlopen it.
+
+Some platforms automatically load any shared libraries that your
address@hidden module depends on.  Some do not.  Also, even if the runtime
+loader does automatically try to load dependent libraries for you, it
+may not honor any @code{RPATH} or @code{DT_RPATH}, so it may not be
+very successfull.  See @pxref{Dynamic loading}) for more information.
+Assuming that libltdl knows the behavior of your platform, dependent
+libraries will automatically be loaded for you.
+
 If you want to disable @pxref{Versioning} for a specific module
 you should link it with the @samp{-avoid-version} switch.
 Note that libtool modules don't need to have a "lib" prefix.
@@ -3939,7 +3949,7 @@
 the information to them.

 To do the port yourself, you'll definitely need to modify the
address@hidden macros in order to make platform-specific changes to
address@hidden macros in order to make platform-specific changes to
 the configuration process.  You should search that file for the
 @code{PORTME} keyword, which will give you some hints on what you'll
 need to change.  In general, all that is involved is modifying the
@@ -3949,8 +3959,8 @@
 yours, and make your changes based on that.  In some cases, however,
 your system will differ significantly from every other supported system,
 and it may be necessary to add new configuration variables, and modify
-the @code{ltmain.in} script accordingly.  Be sure to write to the
-mailing list before you make changes to @code{ltmain.in}, since they may
+the @file{ltmain.in} script accordingly.  Be sure to write to the
+mailing list before you make changes to @file{ltmain.in}, since they may
 have advice on the most effective way of accomplishing what you want.

 @node Porting inter-library dependencies
@@ -3994,7 +4004,7 @@
 will pass everything without any checking.  This may work on platforms
 in which code is position-independent by default and inter-library
 dependencies are properly supported by the dynamic linker, for example,
-on DEC OSF/1 3 and 4.
+on DEC OSF/1 3 and later on the Alpha.

 @item none
 @vindex none
@@ -4010,7 +4020,7 @@
 improve it.
 @end table

-Then in @file{ltmain.in} we have the real workhorse: a little
+Then in @file{ltmain.sh.in} we have the real workhorse: a little
 initialization and postprocessing (to setup/release variables for use
 with eval echo libname_spec etc.) and a case statement that decides
 which method is being used.  This is the real code... I wish I could
@@ -4038,7 +4048,7 @@
 Note: The vendor-distributed NCR MP-RAS @code{cc} programs emits
 copyright on standard error that confuse tests on size of
 @file{conftest.err}.  The workaround is to specify @code{CC}
-when run @code{configure} with @kbd{CC='cc -Hnocopyr'}.
+when running @file{configure} with @kbd{CC='cc -Hnocopyr'}.

 @node Platform quirks
 @section Platform quirks
@@ -4056,8 +4066,9 @@
 @menu
 * References::                  Finding more information.
 * Compilers::                   Creating object files from source files.
+* Dynamic loading::             Using @code{dlopen()} or its logical 
equivalent.
 * Reloadable objects::          Binding object files together.
-* Multiple dependencies::      Removing duplicate dependant libraries.
+* Multiple dependencies::       Removing duplicate dependant libraries.
 * Archivers::                   Programs that create static archives.
 @end menu

@@ -4136,8 +4147,8 @@
 @item hpux10*
 Use @samp{+Z} to generate PIC.

address@hidden osf3*
-Digital/UNIX 3.x does not have PIC flags, at least not on the PowerPC
address@hidden osf[345]*
+Digital/Tru64 UNIX does not have or need PIC flags, at least not on the Alpha
 platform.

 @item solaris2*
@@ -4146,6 +4157,22 @@
 @item sunos4*
 Use @samp{-PIC} to generate PIC.
 @end table
+
address@hidden Dynamic loading
address@hidden Dynamic loading
+
+Be advised that when doing dynamic loading of a
+shared object or module, some platforms will also automatically load any
+shared libraries that the @code{dlopen}ed module depends on.  Some do not.
+Many platforms have a loader that will use any @code{RPATH} or
address@hidden embedded in the module in the search for needed libraries.
+One platform where this is @strong{not} the case is Digital/Tru64 UNIX
+versions 4.x or earlier.
+
+This is primarily an issue for people that need to port libltdl to a
+completely new platform, or one where the behavior of the loader in this
+situation is not yet known.  Examine the @code{AC_LDTL_SYS_DLOPEN_DEPLIBS}
+macro in @file{ltdl.m4} for more information.

 @node Reloadable objects
 @subsection Reloadable objects