libtool-patches
[Top][All Lists]
Advanced

[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?





reply via email to

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