bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mixed prefix libraries ...


From: Michael Meeks
Subject: Re: mixed prefix libraries ...
Date: Fri, 16 Jul 2010 11:02:00 +0100

Hi Ralf,

On Sat, 2010-06-26 at 12:49 +0200, Ralf Wildenhues wrote: 
> thanks for the report.

        My pleasure; thanks for a great tool :-)

> >     These in turn cause $temp_rpath to have /usr/lib: prepended to the
> > LD_LIBRARY_PATH before /opt/hgnome/lib.
.. 
> There are three aspects to this issue:
> 
> First, an rpath or LD_LIBRARY_PATH entry to /usr/lib seems like a bug;
> is that directory not in sys_lib_dlsearch_path_spec, and if not, why?
> If it is, then no rpath should be added to point there.

        Well - so you might hope :-) unfortunately reading my libtool (2.2.6)
it has:

            # We need to hardcode the library path
            if test -n "$shlibpath_var" && test -z "$avoidtemprpath" ; then
              # Make sure the rpath contains only unique directories.
              case "$temp_rpath:" in
              *"$absdir:"*) ;;
              *) temp_rpath="$temp_rpath$absdir:" ;;
              esac
            fi
..
    # Add our own library path to $shlibpath_var
    $shlibpath_var=\"$temp_rpath\$$shlibpath_var\"

        While there is logic to purge $compile_rpath and $finalize_rpath of
system library paths, there is no attempt to clean $temp_rpath.

        Possibly therein lies the source of the problem ? :-)

> This idea definitely has some merit.  It has the potential to fix some
> cases (such as yours) on at least some systems.  One problem with it is
> that at least on some systems, libtool isn't always smart enough to
> really find all libraries the way the linker does; this could cause
> regressions.

        True; of course - as long as the immediate .libs/ directory we are
targetting with these symlinks is at the front of the path; if the
LD_LIBRARY_PATH remains as before, any omitted libraries will be picked
up as before: we can do no worse I suspect, and potentially rather
better.

> Another technical complication (but not a deal-breaker here) is that
> currently, libtool employs one of several different methods to get
> uninstalled programs linked against a mix of uninstalled and installed
> libraries: a wrapper script or executable for setting up $shlibpath_var,
> relinking of the uninstalled or the installed program to contain rpath
> entries for uninstalled libs, ...

        Sure; surely we're discussing that wrapper ? [ though perhaps not the
re-linking piece ].

> Well, the final aspect to this issue is: if your setup is so complex
> that a linear ordering of directories from which to pick libraries will
> not work for your complete library tree, then maybe later on you will
> run into problems anyway.  Yes, I know that GNU ld is smarter here with
> its handling of indirect dependencies than libtool, but it's easy enough
> to shoot yourself in the foot also on GNU/Linux there.

        Oh of course :-) 

        Thanks,

                Michael.

-- 
 address@hidden  <><, Pseudo Engineer, itinerant idiot







reply via email to

[Prev in Thread] Current Thread [Next in Thread]