[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: libtool update - the "duplicate _init and _fini" problem
From: |
Boehne, Robert |
Subject: |
RE: libtool update - the "duplicate _init and _fini" problem |
Date: |
Wed, 25 Jun 2003 18:21:35 -0500 |
OK with me, too bad all patches aren't explained this well!
Thanks,
Robert Boehne
-----Original Message-----
From: Alexandre Oliva [mailto:address@hidden
Sent: Wednesday, June 25, 2003 3:55 PM
To: Fernando Nasser; address@hidden; address@hidden
Cc: address@hidden; Joe Orton
Subject: Re: libtool update - the "duplicate _init and _fini" problem
On Jun 25, 2003, Fernando Nasser <address@hidden> wrote:
> This version of libtool includes the (host) crti.o file which usually
> lives in /usr/lib (or /usr/lib64 on 64 bit machines).
> But cross compilers use the target machine crt file, which lives in
> the multilib directory inside the gcc installation itself, like:
> /usr/lib/gcc-lib/x86_64-redhat-linux/3.3/crtbeginS.o
The problem is caused by an occurrence of "$LD" in libtool.m4, in teh
macro AC_PROG_LD_GNU. The patchlet that fixes it is:
[AC_REQUIRE([AC_PROG_EGREP])dnl
AC_CACHE_CHECK([if the linker ($LD) is GNU ld], lt_cv_prog_gnu_ld,
[# I'd rather use --version here, but apparently some GNU ld's only accept -v.
-case `"$LD" -v 2>&1 </dev/null` in
+case `$LD -v 2>&1 </dev/null` in
*GNU* | *'with BFD'*)
lt_cv_prog_gnu_ld=yes
;;
The reason for this problem is that, on AMD64, LD is set to the
pathname of LD followed by -m elf_x86_64, and "/usr/bin/ld -m
elf_x86_64" does not exist as a filename, so libtool's configure
machinery concludes the linker used by g++ is not GNU ld, so, instead
of using:
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o
$lib'
it ends up using the generic link command:
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $predep_objects $libobjs
$deplibs $postdep_objects $compiler_flags -o $lib'
Note the absence of -nostdlib. This is likely another bug, that can
be fixed in libtool.m4 with the following patchlet:
# linker, instead of GNU ld. If possible, this setting should
# overridden to take advantage of the native linker features on
# the platform it is being used on.
- _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $predep_objects $libobjs
$deplibs $postdep_objects $compiler_flags -o $lib'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags -o $lib'
fi
# Commands to make compiler produce verbose output that lists
I'd like to thank Tim Waugh for having gone through this with me. It
was a painful debugging session.
While at that, I also fixed some incorrect uses of the term `path',
per RMS's request.
Ok to install in the libtool CVS tree?