Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS

[Robert Boehne]

Tim:

I've got two minor nits about this patch.  First, I think
the following change may be confusing:
> -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
In the context, I think  we should go with either ltmain.sh OR
ltmain.in,
this snippet could suggest that there is a file ltmain.sh.in.

Second, from the discussion on dlopen'ing dependent libraries,
this line should be changed from:
> +One platform where this is @strong{not} the case is Digital/Tru64 UNIX
> +versions 4.x or earlier.
to read "versions 5.1 or earlier.", or 5.0, depending on how you
interpret
the existence of the patch referred to in the discussion on this issue.
I'll commit this after I hear your comments on these two chagnes.
And as always, thanks for the patch!

Rob

Tim Mooney wrote:
> 
> 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
> 
> _______________________________________________
> Libtool-patches mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/libtool-patches

-- 
Robert Boehne             Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  address@hidden