Re: mixed prefix libraries ...

[Ralf Wildenhues]

[ http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7440/focus=7446 ]

Hello Michael,

* Ralf Wildenhues wrote on Mon, Jul 19, 2010 at 09:51:29PM CEST:
> * Michael Meeks wrote on Fri, Jul 16, 2010 at 12:02:00PM CEST:
> > On Sat, 2010-06-26 at 12:49 +0200, Ralf Wildenhues wrote: 
> > > 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 ? :-)
> 
> Ahh.  Hmm.  Either uninstalled paths should be ordered before others, or
> default-searched paths should be pruned (or not added in the first
> place), or both.  That means we should have a couple of test cases that
> make it clear which of the two methods are needed.
> 
> Can you describe the breaking setup or post a small reproducer for your
> issue?  Thanks.  Ideally, just continue the scriptlet at the end of this
> mail.
> 
> Alternatively, provide the following details for the case you are
> seeing: 'libtool --debug --mode=execute' command and all output for the
> uninstalled program you're seeing fail, 'objdump -p' output for the
> uninstalled binary of that program (the actual program might be below
> .libs and might have an 'lt-' prefix or not).  In an up to date build
> tree of your package, remove the uninstalled program and all uninstalled
> libraries it links against, then rerun 'make' and post all of its
> output.  We might need more information later, so please keep this build
> tree around for now.
[...]

Is this the thread you were talking about?

Because if yes, then I'm afraid I still need help from you in order to
be able to reproduce the problem, as mentioned in my reply (which also
code to set up such a test).  Alternatively, some 'libtool --debug'
output for the --mode=link and --mode=execute stages is usually
sufficient to reverse-engineer the bug.

That would make it a lot less work for us to analyze the issue.

Thanks,
Ralf