Re: Fixing *other* libtool problem?
At 10:08 -0700 1998-07-27, Rob Browning wrote:
>Lintian pointed out that plotutils produces shared libs without
>dependency information which requires linking the lib with "-lc". The
>package uses libtool, and I applied the recommended patch to fix the
>-rpath problem, but I haven't figured out a satisfactory way to make
>libtool use "-lc" at the right point. Suggestions?
My diff for ltconfig (this is against binutils 2.9.1 which uses libtool 1.2):
--- ltconfig.orig Tue Jul 28 08:28:24 1998
+++ ltconfig Tue Jul 28 08:29:30 1998
@@ -716,15 +716,15 @@ if test "$with_gnu_ld" = yes && test "$g
# See if GNU ld supports shared libraries.
if $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; then
- archive_cmds='$CC -shared ${wl}-soname $wl$soname -o $lib$libobjs'
- runpath_var=LD_RUN_PATH
+ archive_cmds='$CC -shared ${wl}-soname $wl$soname -o $lib$libobjs
$deplibs'
+ runpath_var=LD_RUN_PATH_DISABLED
ld_shlibs=yes
else
ld_shlibs=no
fi
if test "$ld_shlibs" = yes; then
- hardcode_libdir_flag_spec='${wl}--rpath ${wl}$libdir'
+ hardcode_libdir_flag_spec=''
export_dynamic_flag_spec='${wl}--export-dynamic'
fi
else
Patching ltconfig is the best solution, because changes to it propogate to
all generated libtools, thus it will work for any package that uses libtool.
I don't like having the LD_RUN_PATH_DISABLED (LD_RUN_PATH is treated by ld
like a -rpath argument) there, but ltconfig decides it can't build shared
libraries if runpath_var isn't defined.
--
Joel "Espy" Klecker Debian GNU/Linux Developer <mailto:jk@espy.org>
<http://www.espy.org/> <ftp://ftp.espy.org/pub/>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: