bug-libtool
[Top][All Lists]
Advanced

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

Re: mixed prefix libraries ...


From: Ralf Wildenhues
Subject: Re: mixed prefix libraries ...
Date: Mon, 19 Jul 2010 21:51:29 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

Hello Michael,

* 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: 
> > >   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 ? :-)

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.

Thanks,
Ralf


: ${LIBTOOL=libtool}
: ${CC=gcc}
sysusr=`pwd`/usr
syslib=$sysusr/lib
inst=`pwd`/inst
libdir=$inst/lib


mkdir $sysusr $syslib $inst $libdir

cat >a.c <<\EOF
/* bad old liba */
int a () { return -1; }
EOF

$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c a.c
$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba.la a.lo \
  -version-info 1:0:0 -rpath $syslib
$LIBTOOL --mode=install cp liba.la $syslib/liba.la
$LIBTOOL --mode=clean rm -f liba.la

cat >a.c <<\EOF
/* good liba */
int a () { return 0; }
EOF

$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c a.c
$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba.la a.lo \
  -version-info 1:0:0 -rpath $libdir
$LIBTOOL --mode=install cp liba.la $libdir/liba.la
$LIBTOOL --mode=clean rm -f liba.la

cat >b.c <<\EOF
extern int a ();
int b () { return a (); }
EOF

# ...



reply via email to

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