Glenn Morris <rgm@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.
Received: (at 8542) by debbugs.gnu.org; 25 Apr 2011 18:03:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 25 14:03:29 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.69)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1QEQ88-0005al-Id
for submit <at> debbugs.gnu.org; Mon, 25 Apr 2011 14:03:29 -0400
Received: from nspiron-2.llnl.gov ([128.115.41.82])
by debbugs.gnu.org with esmtp (Exim 4.69)
(envelope-from <tgamblin@HIDDEN>) id 1QEPri-0005Cp-KY
for 8542 <at> debbugs.gnu.org; Mon, 25 Apr 2011 13:46:32 -0400
X-Attachments: None
Received: from vpnb-user-128-15-245-45.llnl.gov (HELO [128.15.245.45])
([128.15.245.45])
by nspiron-2.llnl.gov with ESMTP; 25 Apr 2011 10:46:22 -0700
Subject: Re: bug#8542: 2.4 : triggers libc "nlist > 1" assertion failure from
--link in 'setarch i686' environment
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Todd Gamblin <tgamblin@HIDDEN>
In-Reply-To: <201104251534.11279.jason.vas.dias@HIDDEN>
Date: Mon, 25 Apr 2011 10:46:22 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <B1DFD825-9BDC-4875-9FCE-E6CC6B11D6A7@HIDDEN>
References: <201104221736.44559.jason.vas.dias@HIDDEN>
<BANLkTikZdbj7mnhj8wznqteK2kyvy__Myw@HIDDEN>
<201104251534.11279.jason.vas.dias@HIDDEN>
To: "jason.vas.dias@HIDDEN" <jason.vas.dias@HIDDEN>
X-Mailer: Apple Mail (2.1081)
X-Spam-Score: -6.6 (------)
X-Debbugs-Envelope-To: 8542
X-Mailman-Approved-At: Mon, 25 Apr 2011 14:03:26 -0400
Cc: Gordon Matzigkeit <gord@HIDDEN>, Mike Frysinger <vapier@HIDDEN>,
"8542 <at> debbugs.gnu.org" <8542 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.6 (------)
Hey guys,
I'm not sure why I'm on this bug list, but in any case, could you take =
me off? I don't think I have anything to do with this.
Thanks!
-Todd
On Apr 25, 2011, at 7:34 AM, Jason Vas Dias wrote:
> On Monday 25 April 2011 06:10:21 Mike Frysinger wrote:
>> On Fri, Apr 22, 2011 at 12:36 PM, Jason Vas Dias wrote:
>>> $ make
>>> CXXLD libgoo.la
>>> Inconsistency detected by ld.so: dl-deps.c: 622: =
_dl_map_object_deps: Assertion `nlist > 1' failed!
>>=20
>> sounds like the glibc bug:
>> http://sources.redhat.com/bugzilla/show_bug.cgi?id=3D12454
>> -mike
>>=20
> Hi Mike - thanks for responding -=20
> but this was an inadvertent resend from my mailer of a "draft" , a =
copy of which I had sent by other means, to create bug :
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D8537
> this turned out to be nothing to do with glibc, but with why the =
libtool script says:
>=20
> /usr/bin/libtool @line 274 :
> # Compile-time system search path for libraries.
> sys_lib_search_path_spec=3D"/usr/lib64/gcc/x86_64-pc-linux-gnu/lib64 =
/usr/lib64 /lib64 /usr/x86_64-pc-linux-gnu/lib "
>=20
> # Run-time system search path for libraries.
> sys_lib_dlsearch_path_spec=3D"/lib /usr/lib /usr/lib64 /lib64 =
/usr/lib64/gcc/x86_64-pc-linux-gnu/lib64 =
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0 /usr/lib64/nspr /usr/lib64/nss =
/usr/qt/4.6/lib64 /usr/kde/4.3/lib64 /usr/java/lib64 /usr/lib32 /lib32 =
/usr/lib64/gcc/x86_64-pc-linux-gnu/lib32 =
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32 /usr/lib32/nspr =
/usr/lib32/nss /usr/java/lib32 "
>=20
> when I think it should be saying something like :
>=20
> # Compile-time system search path for libraries.
> sys_lib_search_path_spec=3D"$(${CC:-gcc} $CFLAGS -print-search-dirs =
|sed -n '/^libraries:/{s/^libraries[:=3D\ \ ]*//;s/:/ /g;p}')"
>=20
> # Run-time system search path for libraries.
> sys_lib_dlsearch_path_spec=3D"sed 's/^include/\#include/ < =
/etc/ld.so.conf | cpp - | egrep -v '^\#' | tr '\n' ' '"
>=20
>=20
> ie. how can libtool hope to get the multi-lib search path correct if =
it is NOT dynamic and dependant on $CFLAGS ?
> ie. my gcc-4.6.0 produces radically different library search values =
for 32-bit and 64-bit :
>=20
> $ gcc -print-search-dirs ; echo multi-os:; gcc =
-print-multi-os-directory
> install: /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/
> programs: =
=3D/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/libexec/gcc/x86_64-pc-=
linux-gnu/4.6.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib64/gcc/x86_=
64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/:/usr/lib64/gcc/=
x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/x86_64-pc-li=
nux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64=
-pc-linux-gnu/bin/
> libraries: =
=3D/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linu=
x-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.6.0/=
:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/=
lib/../lib64/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../x86_64-pc-=
linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib6=
4/:/lib/x86_64-pc-linux-gnu/4.6.0/:/lib/../lib64/:/usr/lib/x86_64-pc-linux=
-gnu/4.6.0/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/..=
/../../../x86_64-pc-linux-gnu/lib/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.=
0/../../../:/lib/:/usr/lib/
> multi-os:
> ../lib64
>=20
> $ gcc -m32 -print-search-dirs ; echo multi-os:; gcc -m32 =
-print-multi-os-directory
> install: /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/
> programs: =
=3D/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/libexec/gcc/x86_64-pc-=
linux-gnu/4.6.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib64/gcc/x86_=
64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/:/usr/lib64/gcc/=
x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/x86_64-pc-li=
nux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64=
-pc-linux-gnu/bin/
> libraries: =
=3D/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/:/usr/lib64/gcc/x86_64-pc-l=
inux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.6=
.0/32/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linu=
x-gnu/lib/../lib32/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../x86_=
64-pc-linux-gnu/4.6.0/32/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../.=
./../lib32/:/lib/x86_64-pc-linux-gnu/4.6.0/32/:/lib/../lib32/:/usr/lib/x86=
_64-pc-linux-gnu/4.6.0/32/:/usr/lib/../lib32/:/usr/lib64/gcc/x86_64-pc-lin=
ux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-=
pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux=
-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib64/gcc/x86_64-pc-l=
inux-gnu/4.6.0/../../../x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-p=
c-linux-gnu/4.6.0/../../../:/lib/x86_64-pc-linux-gnu/4.6.0/:/lib/:/usr/lib=
/x86_64-pc-linux-gnu/4.6.0/:/usr/lib/
> multi-os:
> ../lib32
>=20
> So why can't the installed libtool script invoke "$($CC $CFLAGS =
-print-search-dirs)" dynamically to determine the library search path ?
>=20
> If it did, it would function correctly for "naive" libtool users such =
as poppler which are totally unaware of any multi-lib / multi-arch
> environment, as well as for "sophisticated" libtool using libraries =
such as cairo, which DO build correctly for 32-bit - both my
> dynamic version and the installed hard-coded version - I can't quite =
understand why yet, but I think the cairo build scripts are
> just better honoring my $CFLAGS / $LDFLAGS settings, and if they were =
not set libtool would still fail for 32-bit sub-arch=20
> cairo build on x86_64 ; ie. with my "dynamic setting of =
sys_lib_search_path_spec", I would not need to set $LDFLAGS to such
> a complicated value and libtool would work correctly if I just set =
CFLAGS=3D-m32 .
>=20
> Also, why does libtool insist on supplying explicit paths to the "c =
runtime startup" (CRT) files : crti.o crtbeginS.o crtn.o crtendS.o -
> when GCC supplies these automatically and 100% correctly for its =
"-mXX" args ? To me, that is just another unecessary way
> that libtool can fail .
>=20
> I'd greatly appreciate it if you could take a look at bug #8537 - do =
you think a patch along the lines detailed therein would be
> considered for libtool ? (obviously the final patch would be against =
the script SOURCE, not the installed script, as it is currently).
>=20
> Thanks & Regards ,
> Jason Vas Dias
>=20
>=20
>=20
> _______________________________________________
> Bug-libtool mailing list
> Bug-libtool@HIDDEN
> https://lists.gnu.org/mailman/listinfo/bug-libtool
________________________________________________________________________
Todd Gamblin, tgamblin@HIDDEN, http://people.llnl.gov/gamblin2
CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA
owner <at> debbugs.gnu.org, bug-libtool@HIDDEN:bug#8542; Package libtool.
Full text available.
Received: (at 8542) by debbugs.gnu.org; 25 Apr 2011 14:34:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 25 10:34:25 2011
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.69)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1QEMrn-0008Rf-Ug
for submit <at> debbugs.gnu.org; Mon, 25 Apr 2011 10:34:24 -0400
Received: from mail-ww0-f42.google.com ([74.125.82.42])
by debbugs.gnu.org with esmtp (Exim 4.69)
(envelope-from <jason.vas.dias@HIDDEN>) id 1QEMrm-0008RT-8g
for 8542 <at> debbugs.gnu.org; Mon, 25 Apr 2011 10:34:23 -0400
Received: by wwk4 with SMTP id 4so1439934wwk.3
for <8542 <at> debbugs.gnu.org>; Mon, 25 Apr 2011 07:34:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:from:reply-to:to:subject:date:user-agent:cc
:references:in-reply-to:mime-version:content-type
:content-transfer-encoding:message-id;
bh=aQA9VBMk6eCi0n0l0qTDSUDQJFyCrFLmY/tj3j+xReg=;
b=e0cpvGYGyszFLAGvT0IBRlnwGbRsOT+JsEIDebTm6RAwmabqIHQ4gVKsqMKDNY08Mh
Z4uzgpqdWA2ALpn6NtHoyDMPgxDTld8fp4qoKKbs6sEfluvvi1dxGCOmajUNjvjfKCU8
6gv19XAiObMLe0QsqsbMwfquZSgCK/YWlqDvY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to
:mime-version:content-type:content-transfer-encoding:message-id;
b=UamENQ4e8VlCkUi4iTz0us2jFbj5szGRqDOwG+HB4x9OQTQtnDS+GePxfvhgUBwEYS
Phn1ym7Wkn/E6AzePzcF+Jm1+3L4JAm27kJDLMdzkB97fh2NWs4Rm7UouO6xtAxqgEzt
cxmENv45E9arYPQBZXC+sQUaDgDA8VmTgePz4=
Received: by 10.227.203.145 with SMTP id fi17mr3889399wbb.106.1303742056093;
Mon, 25 Apr 2011 07:34:16 -0700 (PDT)
Received: from jvdspc (86-45-160-146-dynamic.b-ras2.chf.cork.eircom.net
[86.45.160.146])
by mx.google.com with ESMTPS id w25sm3293857wbd.56.2011.04.25.07.34.13
(version=SSLv3 cipher=OTHER); Mon, 25 Apr 2011 07:34:13 -0700 (PDT)
From: Jason Vas Dias <jason.vas.dias@HIDDEN>
To: Mike Frysinger <vapier@HIDDEN>
Subject: Re: bug#8542: 2.4 : triggers libc "nlist > 1" assertion failure from
--link in 'setarch i686' environment
Date: Mon, 25 Apr 2011 15:34:09 +0100
User-Agent: KMail/1.12.4 (Linux/2.6.38.2-jvd; KDE/4.3.4; x86_64; svn-1073138;
2010-01-11)
References: <201104221736.44559.jason.vas.dias@HIDDEN>
<BANLkTikZdbj7mnhj8wznqteK2kyvy__Myw@HIDDEN>
In-Reply-To: <BANLkTikZdbj7mnhj8wznqteK2kyvy__Myw@HIDDEN>
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201104251534.11279.jason.vas.dias@HIDDEN>
X-Spam-Score: -4.8 (----)
X-Debbugs-Envelope-To: 8542
Cc: Gordon Matzigkeit <gord@HIDDEN>, 8542 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
Reply-To: jason.vas.dias@HIDDEN
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -4.4 (----)
On Monday 25 April 2011 06:10:21 Mike Frysinger wrote:
> On Fri, Apr 22, 2011 at 12:36 PM, Jason Vas Dias wrote:
> > $ make
> > CXXLD libgoo.la
> > Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion `nlist > 1' failed!
>
> sounds like the glibc bug:
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=12454
> -mike
>
Hi Mike - thanks for responding -
but this was an inadvertent resend from my mailer of a "draft" , a copy of which I had sent by other means, to create bug :
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8537
this turned out to be nothing to do with glibc, but with why the libtool script says:
/usr/bin/libtool @line 274 :
# Compile-time system search path for libraries.
sys_lib_search_path_spec="/usr/lib64/gcc/x86_64-pc-linux-gnu/lib64 /usr/lib64 /lib64 /usr/x86_64-pc-linux-gnu/lib "
# Run-time system search path for libraries.
sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/lib64 /lib64 /usr/lib64/gcc/x86_64-pc-linux-gnu/lib64 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0 /usr/lib64/nspr /usr/lib64/nss /usr/qt/4.6/lib64 /usr/kde/4.3/lib64 /usr/java/lib64 /usr/lib32 /lib32 /usr/lib64/gcc/x86_64-pc-linux-gnu/lib32 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32 /usr/lib32/nspr /usr/lib32/nss /usr/java/lib32 "
when I think it should be saying something like :
# Compile-time system search path for libraries.
sys_lib_search_path_spec="$(${CC:-gcc} $CFLAGS -print-search-dirs |sed -n '/^libraries:/{s/^libraries[:=\ \ ]*//;s/:/ /g;p}')"
# Run-time system search path for libraries.
sys_lib_dlsearch_path_spec="sed 's/^include/\#include/ < /etc/ld.so.conf | cpp - | egrep -v '^\#' | tr '\n' ' '"
ie. how can libtool hope to get the multi-lib search path correct if it is NOT dynamic and dependant on $CFLAGS ?
ie. my gcc-4.6.0 produces radically different library search values for 32-bit and 64-bit :
$ gcc -print-search-dirs ; echo multi-os:; gcc -print-multi-os-directory
install: /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/
programs: =/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/
libraries: =/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/../lib64/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/:/lib/x86_64-pc-linux-gnu/4.6.0/:/lib/../lib64/:/usr/lib/x86_64-pc-linux-gnu/4.6.0/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../:/lib/:/usr/lib/
multi-os:
../lib64
$ gcc -m32 -print-search-dirs ; echo multi-os:; gcc -m32 -print-multi-os-directory
install: /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/
programs: =/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/
libraries: =/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.6.0/32/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/../lib32/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../x86_64-pc-linux-gnu/4.6.0/32/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib32/:/lib/x86_64-pc-linux-gnu/4.6.0/32/:/lib/../lib32/:/usr/lib/x86_64-pc-linux-gnu/4.6.0/32/:/usr/lib/../lib32/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../:/lib/x86_64-pc-linux-gnu/4.6.0/:/lib/:/usr/lib/x86_64-pc-linux-gnu/4.6.0/:/usr/lib/
multi-os:
../lib32
So why can't the installed libtool script invoke "$($CC $CFLAGS -print-search-dirs)" dynamically to determine the library search path ?
If it did, it would function correctly for "naive" libtool users such as poppler which are totally unaware of any multi-lib / multi-arch
environment, as well as for "sophisticated" libtool using libraries such as cairo, which DO build correctly for 32-bit - both my
dynamic version and the installed hard-coded version - I can't quite understand why yet, but I think the cairo build scripts are
just better honoring my $CFLAGS / $LDFLAGS settings, and if they were not set libtool would still fail for 32-bit sub-arch
cairo build on x86_64 ; ie. with my "dynamic setting of sys_lib_search_path_spec", I would not need to set $LDFLAGS to such
a complicated value and libtool would work correctly if I just set CFLAGS=-m32 .
Also, why does libtool insist on supplying explicit paths to the "c runtime startup" (CRT) files : crti.o crtbeginS.o crtn.o crtendS.o -
when GCC supplies these automatically and 100% correctly for its "-mXX" args ? To me, that is just another unecessary way
that libtool can fail .
I'd greatly appreciate it if you could take a look at bug #8537 - do you think a patch along the lines detailed therein would be
considered for libtool ? (obviously the final patch would be against the script SOURCE, not the installed script, as it is currently).
Thanks & Regards ,
Jason Vas Dias
owner <at> debbugs.gnu.org, bug-libtool@HIDDEN:bug#8542; Package libtool.
Full text available.Received: (at 8542) by debbugs.gnu.org; 25 Apr 2011 05:10:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 25 01:10:50 2011 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1QEE4Q-0003d7-HO for submit <at> debbugs.gnu.org; Mon, 25 Apr 2011 01:10:50 -0400 Received: from mail-bw0-f44.google.com ([209.85.214.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <vapierfilter@HIDDEN>) id 1QEE4O-0003cx-9s for 8542 <at> debbugs.gnu.org; Mon, 25 Apr 2011 01:10:48 -0400 Received: by bwz13 with SMTP id 13so1455627bwz.3 for <8542 <at> debbugs.gnu.org>; Sun, 24 Apr 2011 22:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=+sNFH9lxuD57Un4+fLIqYsGJG3vhuOUWbYEFsdL23Rs=; b=kpdAndASUvFj59tWrio/03ul74FTWounQ958RIqV8QBsEtF+4mixUWuFe91nLhd727 5K7CNppbsTKXD4koxR0P1wBjqJn//NtLoBcgEnDoX0uoz6aBWTDYlrViUfYOLi5Wmpc0 EYUCs8QFwojcI2Hxov9Lb4hocnn4SWV8R49GE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=wsHLqR5M1tBiX+vUHMJcHMV1zWKdUrOI8d5Nx/HhDCZyq5CHjl/IdMk8YfAZTVbDLl Jl1sw/AbL79iQbHkCPOOBnb7FGAmu8O/n20cicdoLga53REMGWl8l2MnhL6ijDDaihLf Ih0czGdcHf55h9EKEMgTR8WVCVrs9CHe9mSMo= Received: by 10.204.23.71 with SMTP id q7mr3164847bkb.25.1303708241187; Sun, 24 Apr 2011 22:10:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.67.80 with HTTP; Sun, 24 Apr 2011 22:10:21 -0700 (PDT) In-Reply-To: <201104221736.44559.jason.vas.dias@HIDDEN> References: <201104221736.44559.jason.vas.dias@HIDDEN> From: Mike Frysinger <vapier@HIDDEN> Date: Mon, 25 Apr 2011 01:10:21 -0400 X-Google-Sender-Auth: 0gGXPrmEt7DVK6G83ljkYM9N7r0 Message-ID: <BANLkTikZdbj7mnhj8wznqteK2kyvy__Myw@HIDDEN> Subject: Re: bug#8542: 2.4 : triggers libc "nlist > 1" assertion failure from --link in 'setarch i686' environment To: jason.vas.dias@HIDDEN Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.6 (---) X-Debbugs-Envelope-To: 8542 Cc: Gordon Matzigkeit <gord@HIDDEN>, 8542 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -3.6 (---) On Fri, Apr 22, 2011 at 12:36 PM, Jason Vas Dias wrote: > $ make > =A0CXXLD =A0libgoo.la > Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Ass= ertion `nlist > 1' failed! sounds like the glibc bug: http://sources.redhat.com/bugzilla/show_bug.cgi?id=3D12454 -mike
owner <at> debbugs.gnu.org, bug-libtool@HIDDEN:bug#8542; Package libtool.
Full text available.Received: (at submit) by debbugs.gnu.org; 24 Apr 2011 17:43:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 24 13:43:49 2011 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1QE3LY-0000sG-WE for submit <at> debbugs.gnu.org; Sun, 24 Apr 2011 13:43:49 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <jason.vas.dias@HIDDEN>) id 1QE3LW-0000s3-Jp for submit <at> debbugs.gnu.org; Sun, 24 Apr 2011 13:43:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <jason.vas.dias@HIDDEN>) id 1QE3LQ-00069o-CB for submit <at> debbugs.gnu.org; Sun, 24 Apr 2011 13:43:41 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, RFC_ABUSE_POST, T_DKIM_INVALID, T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:52190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <jason.vas.dias@HIDDEN>) id 1QE3LQ-00069k-Aa for submit <at> debbugs.gnu.org; Sun, 24 Apr 2011 13:43:40 -0400 Received: from eggs.gnu.org ([140.186.70.92]:42694) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <jason.vas.dias@HIDDEN>) id 1QE3LP-0008BX-4Z for bug-libtool@HIDDEN; Sun, 24 Apr 2011 13:43:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <jason.vas.dias@HIDDEN>) id 1QE3LN-00069K-Ta for bug-libtool@HIDDEN; Sun, 24 Apr 2011 13:43:39 -0400 Received: from mail-ww0-f41.google.com ([74.125.82.41]:62541) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <jason.vas.dias@HIDDEN>) id 1QE3LN-00069E-KN for bug-libtool@HIDDEN; Sun, 24 Apr 2011 13:43:37 -0400 Received: by wwi18 with SMTP id 18so879110wwi.0 for <bug-libtool@HIDDEN>; Sun, 24 Apr 2011 10:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:reply-to:to:subject:date:user-agent:cc :mime-version:content-type:content-transfer-encoding:message-id; bh=hKlUfAuiZlC441Z/sVoDpkS1yy/krR8wXeKEgGZUmCM=; b=wuZhWqTxROKy8f0UQ+wL7ird6PBo++MLyzgSKJ1XHpYEg0nN8u3KBT+XiGxItyNVG1 EUYMh2IH4iqxM9du+T00iIH8jjIYB8dHN5y3mlxq9OqWsJLfpT5MXkcSvAq6Rh2vMpqf ban0C3Sdbr/iMatHEKppuAD/BQUNvTBMOm2Yo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:cc:mime-version :content-type:content-transfer-encoding:message-id; b=YLNZBHxd7uGTixtdCOS/GjcNJLunW+QJZm44JLvT9NjGLKP3SvrWK7Nh2a0s95X7Ui 70Dne56KBfE5yIjg/dQ8LPgVIyW2pTS1sHQe3wPvSK5viPHThoO/DHLfuKeBf3644Eva H0K3vIsJ9l5l4CO3Qe2gvxFU8Teib7vgisObk= Received: by 10.216.62.19 with SMTP id x19mr2749749wec.4.1303667015590; Sun, 24 Apr 2011 10:43:35 -0700 (PDT) Received: from jvdspc (86-45-160-146-dynamic.b-ras2.chf.cork.eircom.net [86.45.160.146]) by mx.google.com with ESMTPS id o23sm2850928wbc.61.2011.04.24.10.43.33 (version=SSLv3 cipher=OTHER); Sun, 24 Apr 2011 10:43:34 -0700 (PDT) From: Jason Vas Dias <jason.vas.dias@HIDDEN> To: bug-libtool@HIDDEN Subject: 2.4 : triggers libc "nlist > 1" assertion failure from --link in 'setarch i686' environment Date: Fri, 22 Apr 2011 17:36:42 +0100 User-Agent: KMail/1.12.4 (Linux/2.6.38.2-jvd; KDE/4.3.4; x86_64; svn-1073138; 2010-01-11) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201104221736.44559.jason.vas.dias@HIDDEN> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.9 (-----) X-Debbugs-Envelope-To: submit Cc: Gordon Matzigkeit <gord@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: jason.vas.dias@HIDDEN List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -5.9 (-----) Hi Gordon, bug-libtool members - this is my first post to this list, so please reply to : jason.vas.dias@HIDDEN I believe I may have found a libtool (or possibly a libtool-triggered glibc or binutils) bug : In a "setarch i686" environment on a linux-x86_64 host, where EVERYTHING (more or less) is at the latest available stable upstream version - especially : $ setarch i686 $ echo eval $(echo "307 export CC=/usr/bin/gcc' -m32' 308 export GCC=/usr/bin/gcc' -m32' 309 export CXX=/usr/bin/g++' -m32' 310 export LD=/usr/bin/ld' -melf_i386' 311 export AS=/usr/bin/as' -32' 313 export CFLAGS='-march=i686 -mtune=generic -g -O2 -fPIC -DPIC -Wa,--compress-debug-sections' 314 export LDFLAGS='-Wl,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/lib32,-L/usr/lib32,-L/lib32,-R/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/lib32:/usr/lib32:/lib32,--dynamic-linker,/lib32/ld-linux.so.2' " | sed 's/^[\ \ ]*[0-9]*[\ \ ]*//'); export PKG_CONFIG_PATH=/usr/lib32/pkgconfig/; export PATH=/bin/32:/usr/bin/32:/bin:/usr/bin:/sbin/32:/usr/sbin/32 eval export CC=/usr/bin/gcc' -m32' export GCC=/usr/bin/gcc' -m32' export CXX=/usr/bin/g++' -m32' export LD=/usr/bin/ld' -melf_i386' export AS=/usr/bin/as' -32' export CFLAGS='-march=i686 -mtune=generic -g -O2 -fPIC -DPIC -Wa,--compress-debug-sections' export LDFLAGS='-Wl,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/lib32,-L/usr/lib32,-L/lib32,-R/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/lib32:/usr/lib32:/lib32,--dynamic-linker,/lib32/ld-linux.so.2' $ ( $CC --version; $LD --version; $AS --version; ldconfig --version; libtool --version; autoconf --version; automake --version ) | egrep '[(]G' gcc (GCC) 4.6.0 GNU ld (GNU Binutils) 2.21.51.20110407 GNU assembler (GNU Binutils) 2.21.51.20110407 ldconfig (GNU libc) 2.13 libtool (GNU libtool) 2.4 autoconf (GNU Autoconf) 2.68 automake (GNU automake) 1.10.3 $ $(CC) --print-multi-os-directory ../lib32 I do for instance : $ /usr/src/poppler/configure --prefix=/usr --libdir=/usr/lib32 .... but make fails : $ make CXXLD libgoo.la Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion `nlist > 1' failed! make: *** [libgoo.la] Error 127 but I can do: $ cd goo/.libs $ /usr/bin/g++ -m32 -shared -Wall -Wno-write-strings -Woverloaded-virtual -Wnon-virtual-dtor -Wcast-align -fno-exceptions -fno-check-new -fno-common -g -O2 -ansi -Wl,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/lib32,-L/usr/lib32,-L/lib32,-R/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/lib32:/usr/lib32:/lib32,--dynamic-linker,/lib32/ld-linux.so.2 -o libgoo.so $(echo gfile.lo gmempp.lo GooHash.lo GooList.lo GooTimer.lo GooString.lo gmem.lo FixedPoint.lo PNGWriter.lo JpegWriter.lo TiffWriter.lo ImgWriter.lo gstrtod.lo | sed 's/\.l/./g') -ltiff -ljpeg -lpng $ ls -l libgoo.so ; file libgoo.so -rwxr-xr-x 1 root root 151006 Apr 22 17:23 libgoo.so libgoo.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped So what is libtool trying to do here that my command isn't ? Whatever it is, glibc-2.13 doesn't like it, or it caused binutils to produce a nasty object that glibc doesn't like. Any advice / suggestions would be much appreciated. Obviously, I'll have to 'strace -f -e trace=execve make' . If you'd be interested in the log, I'll post it. Incidentally, I had to : $ rm ./libtool after the poppler configure, else I got lots of errors : $ make -j2 make all-recursive make[1]: Entering directory `/tmp/poppler' Making all in goo make[2]: Entering directory `/tmp/poppler/goo' CXX gfile.lo CXX gmempp.lo ../libtool: line 42: -32: command not found ../libtool: line 42: -32: command not found CXX GooHash.lo ../libtool: line 42: -32: command not found CXX GooList.lo ../libtool: line 42: -32: command not found But if I remove what was generated during configure as ../libtool (from goo/) , no such messages appear.
jason.vas.dias@HIDDEN:bug-libtool@HIDDEN.
Full text available.owner <at> debbugs.gnu.org, bug-libtool@HIDDEN:bug#8542; Package libtool.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.