On Mon, Nov 21, 2011 at 16:31, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote: > On Mon, 21 Nov 2011, Bert Wesarg wrote: >> >> Christian and I independently solved this with the following fix: >> >> diff --git i/libltdl/config/ltmain.m4sh w/libltdl/config/ltmain.m4sh >> index ca67c8a..f79ab5b 100644 libltdl/config/ltmain.m4sh >> --- i/libltdl/config/ltmain.m4sh >> +++ w/libltdl/config/ltmain.m4sh >> @@ -6391,8 +6391,7 @@ func_mode_link () >> # Pragmatically, this seems to cause very few problems in >> # practice: >> case $deplib in >> - -L*) new_libs="$deplib $new_libs" ;; >> - -R*) ;; >> + -L*|-R*) new_libs="$deplib $new_libs" ;; >> *) >> # And here is the reason: when a library appears more >> # than once as an explicit dependence of a library, or >> >> With this patch, the -R flag inside the dependency_libs list is honored >> and appropriately added to the link command. >> >> Is there anything wrong with this approach. If not we propose this patch >> for inclusion. A proper ChangeLog and Signed-of-by line will follow than. I >> will also try to transform Christians example into an test than. > > Yes, I think that there is something wrong with this approach. The -R > option should not be used to find libraries at link time. Libraries present > in the run-time linker search path at link time are not necessarily the > correct ones to be used for linking. Run-time linker search path and > link-time linker search path are totally different things.
The -R option is not used by libtool to find libraries at link-time, it tells libtool to add this path to the targets run-time linker search path. I.e. it passes -Wl,-rpath -Wl,<path> to the linker. Thus, this patch does what the documentation says: https://www.gnu.org/software/libtool/manual/libtool.html#Link-mode Bert > > Bob _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
