GNU bug report logs - #8557
libtool run against newly built libraries fails in setarch 'i686'

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: libtool; Reported by: jason.vas.dias@HIDDEN; dated Tue, 26 Apr 2011 10:38:01 UTC; Maintainer for libtool is bug-libtool@HIDDEN.

Message received at 8557 <at> debbugs.gnu.org:

Received: (at 8557) by debbugs.gnu.org; 28 Apr 2011 21:58:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 17:58:55 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 1QFZEc-0004FG-Rl
	for submit <at> debbugs.gnu.org; Thu, 28 Apr 2011 17:58:55 -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 1QFZEb-0004F2-Bw; Thu, 28 Apr 2011 17:58:53 -0400
Received: by bwz13 with SMTP id 13so2679304bwz.3
	for <multiple recipients>; Thu, 28 Apr 2011 14:58:47 -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=AHj3tgUMmwfSy9uHFh+MylXMhMrk+axXr8SIKmpx3lo=;
	b=U7pIuJ71l9+kC2zpvMe8FyhBraCX71RoZcuri8TkTk4um0Rxd1pk62T2NXE1IIyLVq
	T+bW3/LyPs7UD14Sjob/o1tbu+k4yd3bguR32QQ6ctZKbmdWKAP/XOqAyvVzmv5mlr1O
	ztdoOrt8FVbZQ4IOJxDj9Bk9LbSS/qvMTkDGk=
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=RkOpDb+ofbZcoaJsn4sf9ZNhOn0CbUeuQi/z/mnfxGCawIniYYRjh/ZcytVKue8rTe
	VrlRplSiZfX7UIv/S8Z+b4Q6P0UVxeWtfkLQmFz50S3Dfuq3uIQLWPLbchzW7xTsuIrQ
	PyRIZu89uDpsI8orIATQ/mQ8q996fA6uXw55Q=
Received: by 10.204.18.193 with SMTP id x1mr252056bka.79.1304027926143; Thu,
	28 Apr 2011 14:58:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.67.80 with HTTP; Thu, 28 Apr 2011 14:58:25 -0700 (PDT)
In-Reply-To: <201104282004.57289.jason.vas.dias@HIDDEN>
References: <201104261338.19261.jason.vas.dias@HIDDEN>
	<201104280055.37023.jason.vas.dias@HIDDEN>
	<BANLkTinbojVYEeoNy27LL0amPfRnffvQVw@HIDDEN>
	<201104282004.57289.jason.vas.dias@HIDDEN>
From: Mike Frysinger <vapier@HIDDEN>
Date: Thu, 28 Apr 2011 17:58:25 -0400
X-Google-Sender-Auth: nMeunZ3NeOzByhMqM8Y5RGYABYY
Message-ID: <BANLkTinGH-psOk_bYgJTw1sUnWMuvbtXEw@HIDDEN>
Subject: Re: libtool must not depend on existence of system '/usr/lib*/*.la'
	files
To: jason.vas.dias@HIDDEN
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -3.9 (---)
X-Debbugs-Envelope-To: 8557
Cc: 8537 <at> debbugs.gnu.org, 8557 <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.8 (---)

On Thu, Apr 28, 2011 at 15:04, Jason Vas Dias wrote:
> I'm developing a 100% GNU make(1) and bash(1) and coreutils dependant rep=
lacement for the "configure" step - NO other dependancies required -
> that will generate =A0'Makefile's and ./libtool with very simple commands=
 if it finds itself to be running on a "quick configure platform" , it will=
 skip configure
> and just generate simple autoconf generated files.

search the mailing list.  some people have already thrown together
similar things.
-mike

Information forwarded to owner <at> debbugs.gnu.org, bug-libtool@HIDDEN:
bug#8557; Package libtool. Full text available.

Message received at 8557 <at> debbugs.gnu.org:

Received: (at 8557) by debbugs.gnu.org; 28 Apr 2011 19:05:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 15:05:08 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 1QFWWR-0000QZ-GY
	for submit <at> debbugs.gnu.org; Thu, 28 Apr 2011 15:05:07 -0400
Received: from mail-wy0-f172.google.com ([74.125.82.172])
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <jason.vas.dias@HIDDEN>)
	id 1QFWWP-0000Q2-Kf; Thu, 28 Apr 2011 15:05:06 -0400
Received: by wyb29 with SMTP id 29so2466137wyb.3
	for <multiple recipients>; Thu, 28 Apr 2011 12:04:59 -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=yaihpO/1lIzUxZ7prMrdtNsLwsIGOlczWRQA2j8bVD0=;
	b=GeyufIL4G+VSRInP5uSJ9ZnMNyau+ZkBi2ZGgn7TxPde4iQRtH5RYnrvNoX4dPjkaR
	8USaLT/T/NXPbglT40y1wrrfN8kl361ip1HPDhtA6kqIjENkpayL1O4fiKWXPXMFH1EW
	ZfhpVqdGa0eXshBSi5x6Tl9pN2r14P3GJp3OQ=
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=Z6ulKv+bf9CcLs8PNIu2A2YhFDLU7oisPAlf3sqJvonBUGhZBmL5i9rcMQYJ8GAfG9
	3twN1DKbss7BMYD6V4JhTVfnXHfOZEkbLU76bEaH6APC2Q7AfH/RmaXbhDtAuPZA0x1a
	PUfBlU6HFxXBir7f6AUlMdeFpgc1K7OKDzhro=
Received: by 10.227.182.135 with SMTP id cc7mr303194wbb.91.1304017499527;
	Thu, 28 Apr 2011 12:04:59 -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 bd8sm1266270wbb.65.2011.04.28.12.04.57
	(version=SSLv3 cipher=OTHER); Thu, 28 Apr 2011 12:04:58 -0700 (PDT)
From: Jason Vas Dias <jason.vas.dias@HIDDEN>
To: Mike Frysinger <vapier@HIDDEN>
Subject: Re: libtool must not depend on existence of system '/usr/lib*/*.la'
	files
Date: Thu, 28 Apr 2011 20:04:56 +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: <201104261338.19261.jason.vas.dias@HIDDEN>
	<201104280055.37023.jason.vas.dias@HIDDEN>
	<BANLkTinbojVYEeoNy27LL0amPfRnffvQVw@HIDDEN>
In-Reply-To: <BANLkTinbojVYEeoNy27LL0amPfRnffvQVw@HIDDEN>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201104282004.57289.jason.vas.dias@HIDDEN>
X-Spam-Score: -4.3 (----)
X-Debbugs-Envelope-To: 8557
Cc: 8537 <at> debbugs.gnu.org, 8557 <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.3 (----)

On Thursday 28 April 2011 12:59:05 Mike Frysinger wrote:
> > And I'd still like an answer to the basic question "why is libtool doing so much on Linux
> > when gcc gets it right on its own" ?
> 
> your view of libtool is clouded by your very narrow focus on recent
> versions of gcc/Linux targets.  libtool scales to many many more
> targets, and its complex system is designed to handle severly
> deficient targets.  albeit at the cost of being more complex than
> necessary for some modern/sane targets.
> -mike

But I, as the end user and "distro maintainer" of my own distro, want to produce a compatible
version of libtool for linux for use on it that does not do anything too complicated unless it needs to .

I've always greatly admired autoconf, automake and libtool for their ability to build and install 
software on such a huge variety of platforms, but always hated trying to get them to build
and install software that is truly optimized for only one OS and toolchain .

With a "one size fits all" approach, it is too easy to make all software perform equally poorly on all platforms -
I'm not saying autoconf / automake / libtool does this, but it enforces alot of complicated configuration operations on platforms where
literally typing 'make c.o' where 'c.c' exists will do the job without anything else at all (no Makefile required even) .

I'm developing a 100% GNU make(1) and bash(1) and coreutils dependant replacement for the "configure" step - NO other dependancies required -
that will generate  'Makefile's and ./libtool with very simple commands if it finds itself to be running on a "quick configure platform" , it will skip configure 
and just generate simple autoconf generated files.
I have a make library that can source and execute m4 configure macros,  and could make it construct a "configure" script and "libtool" script in make 
"define ... endef"s that can be dumped to files or sourced . Personally, I prefer programming in GNU make(1) and using macro processors such
as cpp or autotext or the shell to programming in m4 , and there is no reason why this shouldn't be permitted on platforms with a fully functional
GNU development tools and utilities toolchain .

I'll post the results to libtool-devel@HIDDEN or whatever it should be sent when this is complete and fully tested (for Linux at least).

All the best,
Jason

Information forwarded to owner <at> debbugs.gnu.org, bug-libtool@HIDDEN:
bug#8557; Package libtool. Full text available.

Message received at 8557 <at> debbugs.gnu.org:

Received: (at 8557) by debbugs.gnu.org; 28 Apr 2011 11:59:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 28 07:59:34 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 1QFPsc-0007Ql-1k
	for submit <at> debbugs.gnu.org; Thu, 28 Apr 2011 07:59:34 -0400
Received: from mail-ey0-f172.google.com ([209.85.215.172])
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <vapierfilter@HIDDEN>)
	id 1QFPsZ-0007QW-3B; Thu, 28 Apr 2011 07:59:32 -0400
Received: by eye13 with SMTP id 13so927857eye.3
	for <multiple recipients>; Thu, 28 Apr 2011 04:59:25 -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=ZG0/e4aVgRc4+HhZN40etWekLsUcdSJvK8TaT4bbKvk=;
	b=VKz4clpZz7iVqYzsP/BbUq08zjzmWrUIjFxuNiZ9FRCjgsBqf3/hyKcwzo63vNLopy
	cmLmyAwUb9ZIz+NkwReQm9pKp4Mb6te29y+70H4rbfgJnaVvb99s0aB6IUohWtSyORsI
	zz6+MRuYIwyYRHo8tPKaAOA5tURNjB4B8X3IQ=
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=c8wn+6QQD0CpooONED7G4bP0l6pbbUJ9vtywsmSrYpSAitxdZSo+7sBLju1h4qHoBJ
	eHlQ3QOOGoG9rKoGj0yJlqJOXHbwOe7OFXz7nzfocJ858aZWPTPfIGDyLgkGd5UDZtZ0
	J2CwXIETNLUW+7jdc4p4NdBzpNJ7LN1jjv3Fo=
Received: by 10.213.105.141 with SMTP id t13mr1583230ebo.8.1303991965152; Thu,
	28 Apr 2011 04:59:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.213.17.193 with HTTP; Thu, 28 Apr 2011 04:59:05 -0700 (PDT)
In-Reply-To: <201104280055.37023.jason.vas.dias@HIDDEN>
References: <201104261338.19261.jason.vas.dias@HIDDEN>
	<201104270048.24483.jason.vas.dias@HIDDEN>
	<BANLkTimKrNwD-p-rgX0yX6vy_hEB95YDHg@HIDDEN>
	<201104280055.37023.jason.vas.dias@HIDDEN>
From: Mike Frysinger <vapier@HIDDEN>
Date: Thu, 28 Apr 2011 07:59:05 -0400
X-Google-Sender-Auth: NF1n1Z-6UWFe0sUHccWwFOUu9Hk
Message-ID: <BANLkTinbojVYEeoNy27LL0amPfRnffvQVw@HIDDEN>
Subject: Re: libtool must not depend on existence of system '/usr/lib*/*.la'
	files
To: jason.vas.dias@HIDDEN
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -4.0 (----)
X-Debbugs-Envelope-To: 8557
Cc: 8537 <at> debbugs.gnu.org, 8557 <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.9 (---)

On Wed, Apr 27, 2011 at 19:55, Jason Vas Dias wrote:
> Then I looked at the /usr/bin/libtool to see what it was doing that could=
 shed light on these bugs;
> that's the only program that libtool installs from its source that one ca=
n test , and is mentioned
> in the documentation - many of the documentation examples would fail if t=
he $CFLAGS used in
> them selects a different $sys_lib_search_path , because the /usr/bin/libt=
ool program would use
> the wrong $sys_lib_search_path_spec setting .

yes, and that is currently expected behavior

> Perhaps a really nice new feature for libtool would be some option to mak=
e all libtool scripts
> not install any .la files in /{,lib,usr/lib}*/ and to ignore any .la file=
s found there ?

i dont think that'd be useful

> Or at least, when some .la is not found, to print which .la it was sourci=
ng that caused it to
> look for the missing .la ? ( Some ".la backtrace" feature ? )

if you run with --debug, you can grep for .la files in the output

although it's usually pretty easy to just look at the output and
guess.  if libtool is invoked with -lfoo and the verbose output from
libtool says /usr/lib/libfoo.so, it most likely hit an .la file for
it.

> And why if the $CFLAGS makes gcc look in /usr/lib32 first , and never loo=
k in /usr/lib64, should ANY
> libtool script be looking for a 32-bit .la or anything =A0in /usr/lib64/ =
?

hardcoding 64bit:/usr/lib64 and 32bit:/usr/lib32 doesnt make sense ...
these are arbitrary conventions picked by gcc specifically for
i686/x86_64 linux targets.  libtool has no concept of multilib today
which is why you have to configure libtool specifically for each
build.

> I thought perhaps it was because those compiled scripts somehow inherited=
 the
> sys_lib_search_path_spec setting behaviour from the /usr/bin/libtool scri=
pt . Why
> install /usr/bin/libtool if it is not meant to be used for anything but g=
cc ?

ultimately this decision is up to your distro provider, but installing
the default libtool is useful for building/linking with the
default/native target.  there are also (poorly written) packages that
invoke `libtool` from $PATH instead of bundling its own local version.

> And I'd still like an answer to the basic question "why is libtool doing =
so much on Linux
> when gcc gets it right on its own" ?

your view of libtool is clouded by your very narrow focus on recent
versions of gcc/Linux targets.  libtool scales to many many more
targets, and its complex system is designed to handle severly
deficient targets.  albeit at the cost of being more complex than
necessary for some modern/sane targets.
-mike

Information forwarded to owner <at> debbugs.gnu.org, bug-libtool@HIDDEN:
bug#8557; Package libtool. Full text available.

Message received at 8557 <at> debbugs.gnu.org:

Received: (at 8557) by debbugs.gnu.org; 27 Apr 2011 23:55:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 27 19:55:57 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 1QFEaJ-0005b2-JY
	for submit <at> debbugs.gnu.org; Wed, 27 Apr 2011 19:55:55 -0400
Received: from mail-wy0-f172.google.com ([74.125.82.172])
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <jason.vas.dias@HIDDEN>)
	id 1QFEaH-0005an-Br; Wed, 27 Apr 2011 19:55:54 -0400
Received: by wyb29 with SMTP id 29so1769115wyb.3
	for <multiple recipients>; Wed, 27 Apr 2011 16:55:47 -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
	:references:in-reply-to:cc:mime-version:content-type
	:content-transfer-encoding:message-id;
	bh=feIfYpU6d8yDOoObAJAeps941/Jnp40KzKSXyp02Z2g=;
	b=aTaAgbs2LK8q8gApy9YLDtM7lV9vsJ8mUZa5VCA5gWwQWzgU8RIegc9zlcMeaDxJqK
	KAEZ1KhgUNfMswzM2mthesS17rG6vSVxR8bIjQ4FBN98KAnCQtrjidvuzdTN1DACHM8I
	GxEm9ivTNDYR/vBq4LFfuHJdwKBIwEORNG1z0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=from:reply-to:to:subject:date:user-agent:references:in-reply-to:cc
	:mime-version:content-type:content-transfer-encoding:message-id;
	b=LYfFrC7PkxhaPnFC9pNUUPN5ZGT/p3uFEW3xiTPp7bEkrYR5qeeuauT1krWvQHZ/6T
	05XuQJD8xSUzxKCeue5S+K/XIAbONKLZ0Em/BmcZAYAHBUiryKBwVE3A16QYdeBLpejP
	rH6mji04uK4+BP9n7lhcEKfoTuo9Z+9mN8YjY=
Received: by 10.216.144.28 with SMTP id m28mr6436713wej.77.1303948547314;
	Wed, 27 Apr 2011 16:55:47 -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 s40sm609397weq.28.2011.04.27.16.55.45
	(version=SSLv3 cipher=OTHER); Wed, 27 Apr 2011 16:55:46 -0700 (PDT)
From: Jason Vas Dias <jason.vas.dias@HIDDEN>
To: Mike Frysinger <vapier@HIDDEN>
Subject: Re: libtool must not depend on existence of system '/usr/lib*/*.la'
	files
Date: Thu, 28 Apr 2011 00:55:33 +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: <201104261338.19261.jason.vas.dias@HIDDEN>
	<201104270048.24483.jason.vas.dias@HIDDEN>
	<BANLkTimKrNwD-p-rgX0yX6vy_hEB95YDHg@HIDDEN>
In-Reply-To: <BANLkTimKrNwD-p-rgX0yX6vy_hEB95YDHg@HIDDEN>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201104280055.37023.jason.vas.dias@HIDDEN>
X-Spam-Score: -4.4 (----)
X-Debbugs-Envelope-To: 8557
Cc: 8537 <at> debbugs.gnu.org, 8557 <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.3 (----)

On Wednesday 27 April 2011 04:14:21 you wrote:
> On Tue, Apr 26, 2011 at 19:48, Jason Vas Dias wrote:
> > And my major primary central questions to the whole libtool community raised in several bug reports (both inadvertently by replying to 'bug-libtool' and
> > intentionally by creating different bugs - sorry ! - there should be only two:  #8537 and #8557 ) is :
> >
> > WHY IS LIBTOOL NOT SETTING $sys_lib_search_path_spec DYNAMICALLY BASED ON $CFLAGS CONTAINING -m$ARCH FLAGS ?
> > WHY IS LIBTOOL SPECIFYING -nostdlibs  -nostdlib \$predep_objects AND SPECIFYING ALL THE "crt*.o" C-RUNTIME OBJECTS ON A GCC / Linux PLATFORM ?
> 
> drop the caps crap.
> 
> the libtool as found in $PATH targets the toolchain is was configured
> for.  this is why libtool is always packaged/generated with the build
> system in packages that use it ... when you configure/build the
> package for a specific target, the local ./libtool is compiled
> properly for that target.  attempting to use `libtool` for anything
> other than the native gcc really isnt its intended use.
> 
> perhaps in the future this might change as an enhancement, but today,
> it sounds like you're just using it wrong.
> -mike
> 
Hi Mike - thanks for responding ! Sorry, I didn't realize capitals were somehow offensive.

RE:  >  the libtool as found in $PATH targets the toolchain is was configured for

Yes,  I know this,  but perhaps I made insufficiently clear what led to me raising these
bugs was the errors / anomalies observed when just running ./libtool via
"configure" / "autogen.sh" and "make" .
Then I looked at the /usr/bin/libtool to see what it was doing that could shed light on these bugs; 
that's the only program that libtool installs from its source that one can test , and is mentioned
in the documentation - many of the documentation examples would fail if the $CFLAGS used in
them selects a different $sys_lib_search_path , because the /usr/bin/libtool program would use
the wrong $sys_lib_search_path_spec setting .

For bug 8537, this was a combination of poppler's libtool using '-nostdlibs' and triggering glibc bug #12454 ,
and for bug 8557, this was mainly because of that stdc++.la being referenced in some installed /usr/lib*/*.la file.

Perhaps a really nice new feature for libtool would be some option to make all libtool scripts not install any .la files in /{,lib,usr/lib}*/  
and to ignore any .la files found there ? Or at least, when some .la is not found, to print which .la it was sourcing that caused it to
look for the missing .la ? ( Some ".la backtrace" feature ? )

And why if the $CFLAGS makes gcc look in /usr/lib32 first , and never look in /usr/lib64, should ANY libtool script be looking for a 32-bit .la 
or anything  in /usr/lib64/ ?

I thought perhaps it was because those compiled scripts somehow inherited the sys_lib_search_path_spec setting behaviour from
the /usr/bin/libtool script . Why install /usr/bin/libtool if it is not meant to be used for anything but gcc ?

Anyway, installing libtool from the GIT head (requiring upgrade to automake-1.11a) seemed to fix the poppler build problem so I guess these
bugs can be closed if noone thinks there are any valid issues raised by them - sorry if this is the case.

I'd like to investigate further exactly why the poppler lib32 build specified -nostdlibs and triggered glibc bug 12454 with libtool-2.4.1 and automake 1.10.3 
but did not with libtool-2.4.1a and automake-1.11a  .

And I'd still like an answer to the basic question "why is libtool doing so much on Linux when gcc gets it right on its own" ?
I don't think libtool should be doing things like forcing a library search path and -nostdlibs and predep_objects and postdep_objects
on gcc when it doesn't actually need to - ie unless there are exceptional circumstances when it is actually required . But this seems to be libtool's default behavior.
I'm curious as to what the rational is in forcing -nostdlib builds that explicitly specify all the CRT objects when gcc generally does this fine,
except in very rare and exceptional circumstances.

But thanks for your help,
all the best,
Jason

Information forwarded to owner <at> debbugs.gnu.org, bug-libtool@HIDDEN:
bug#8557; Package libtool. Full text available.

Message received at 8557 <at> debbugs.gnu.org:

Received: (at 8557) by debbugs.gnu.org; 27 Apr 2011 00:23:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 26 20:23:10 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 1QEsX6-00069O-Uq
	for submit <at> debbugs.gnu.org; Tue, 26 Apr 2011 20:23:09 -0400
Received: from mail-wy0-f172.google.com ([74.125.82.172])
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <jason.vas.dias@HIDDEN>) id 1QEsX5-00068z-4M
	for 8557 <at> debbugs.gnu.org; Tue, 26 Apr 2011 20:23:07 -0400
Received: by wyb29 with SMTP id 29so930430wyb.3
	for <8557 <at> debbugs.gnu.org>; Tue, 26 Apr 2011 17:23:01 -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=Yjmhp0lz50AalTAx/XRxrPDNeX4xwyJB1jC67MLoYWg=;
	b=mZLeAErPtIrN6sklxAgs9bjAXJgs6rqHjj2PtjOc9r6sPPd9KU22nuwACpshe6V0QD
	0D7yE9KT4I7iGbGFTWC4b2N10ZzrtcX9Y5krc6ECnItOzTW8UlceCftF399AaBKH6mNO
	qfNOnw87qgO991krBOGy6Az6m1WXfn+G37Rt8=
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=jG0lrXq45Jt8AXYWHa0CNJOY+mtkkiJ/+Pd1huK+RdFg5H72GVChrDZgao2aDfNCmE
	fEG40a0PmXjBuLfbetuyuxX8poRyc4lyBv0eoLb108SOkH3YDNi49YvZbglOouVXmTtf
	3lQPMhQlMMbrnU26IF5UVmWPqbX45hD85SYOU=
Received: by 10.227.139.164 with SMTP id e36mr1406753wbu.94.1303863781151;
	Tue, 26 Apr 2011 17:23:01 -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 bd8sm132332wbb.31.2011.04.26.17.22.59
	(version=SSLv3 cipher=OTHER); Tue, 26 Apr 2011 17:23:00 -0700 (PDT)
From: Jason Vas Dias <jason.vas.dias@HIDDEN>
To: Mike Frysinger <vapier@HIDDEN>
Subject: Re: libtool must not depend on existence of system '/usr/lib*/*.la'
	files
Date: Wed, 27 Apr 2011 01:22:58 +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: <201104261338.19261.jason.vas.dias@HIDDEN>
	<BANLkTindVgbzU3gR16w76OKAzhUOeD5G9g@HIDDEN>
In-Reply-To: <BANLkTindVgbzU3gR16w76OKAzhUOeD5G9g@HIDDEN>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201104270122.59374.jason.vas.dias@HIDDEN>
X-Spam-Score: -4.5 (----)
X-Debbugs-Envelope-To: 8557
Cc: 8557 <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 Tuesday 26 April 2011 17:56:22 Mike Frysinger wrote:
> On Tue, Apr 26, 2011 at 08:38, Jason Vas Dias wrote:
> > My 32-bit C++ libtool builds were failing because libtool incorrectly accessed
> >   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libstdc++v3.la ,
> > which gcc installs for its 64-bit environment, NOT
> >   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/libstdc++v3.la ,
> > which gcc installs for its 64-bit environment.
> 
> you mean which gcc installs for its 32-bit env
> 
> > And I try to rebuild the 32-bit package from scratch, and it fails because libtool can
> > find no system 'libstdc++v3.la' file.
> 
> most likely not a bug in libtool.  something (probably a .la file) has
> encoded a reference to the libstdc++ .la file.  find that something
> and fix it.
> -mike
> 
> Hi Mike - thanks for responding ! 
> Actually , I can't find ANY references to 'stdc++*.la' under any /{,usr/}lib*/ directory :
> [ root@jvdspc:/ 00:23:51 1256:750 ]
> $ cd /;   find lib32/ lib64/ usr/lib32/ usr/lib64/ -name '*.la' -a -type f | while read f; do egrep -Hn 'stdc\+\+[^.]+\.la' $f; done

OOPS:  SORRY !                                                                                             this should be ^'stdc\+\+[^.]*\.la'

So yes, those stdc++*.la references were bogus, sorry !

But my questions remain :

> [ root@jvdspc:/ 00:24:24 1257:751 ]
> 
> But I see code in libtool that is looking translating a reference to  '-lstdc++'  into looking for (any dir in $sys_lib_search_path_spec)/stdc++.la  .
> 
> And my major primary central questions to the whole libtool community raised in several bug reports (both inadvertently by replying to 'bug-libtool' and
> intentionally by creating different bugs - sorry ! - there should be only two:  #8537 and #8557 ) is :
> 
>WHY IS LIBTOOL NOT SETTING $sys_lib_search_path_spec DYNAMICALLY BASED ON
> $CFLAGS CONTAINING -m$ARCH FLAGS ? WHY IS LIBTOOL SPECIFYING -nostdlibs 
> -nostdlib \$predep_objects AND SPECIFYING ALL THE "crt*.o" C-RUNTIME
> OBJECTS ON A GCC / Linux PLATFORM ?
>
>If I change this line of libtool (GNU libtool 1.3332 2011-04-10) 2.4.1a 's
> installed /usr/bin/libtool :
>
># 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 "
>
>TO:
># 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}')"
>
>and remove wherever it says "-nostdlibs \$predep_objects"  or
> "\$postdep_objects" from link command lines, then everything is hunky-dory
> !
>
>There is no bogus dependencies on any stdc++*.la generated either by the gtk
> build of bug #8557 either by that version, nor is there any glibc bug
> #12454 triggered by a poppler build as in bug #8537 .
>
>It seems to me that libtool is doing too much second-guessing of gcc's
> correct defaults on the Linux platform ; ie. specifying defaults for gcc
> (sometimes incorrectly!) that gcc would in any case get correct all on its
> own.

Please, Mike, why is libtool not using some form of dynamic setting of $sys_lib_search_path_spec from $CC and $CFLAGS ???

Information forwarded to owner <at> debbugs.gnu.org, bug-libtool@HIDDEN:
bug#8557; Package libtool. Full text available.

Message received at submit <at> debbugs.gnu.org:

Received: (at submit) by debbugs.gnu.org; 26 Apr 2011 19:39:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 26 15:39:54 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 1QEo70-00087N-B4
	for submit <at> debbugs.gnu.org; Tue, 26 Apr 2011 15:39:54 -0400
Received: from eggs.gnu.org ([140.186.70.92])
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <ingo@HIDDEN>) id 1QEo6x-000879-LO
	for submit <at> debbugs.gnu.org; Tue, 26 Apr 2011 15:39:52 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ingo@HIDDEN>) id 1QEo6r-0004OB-9r
	for submit <at> debbugs.gnu.org; Tue, 26 Apr 2011 15:39:46 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.1
Received: from lists.gnu.org ([140.186.70.17]:59772)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ingo@HIDDEN>) id 1QEo6r-0004O7-8H
	for submit <at> debbugs.gnu.org; Tue, 26 Apr 2011 15:39:45 -0400
Received: from eggs.gnu.org ([140.186.70.92]:42689)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ingo@HIDDEN>) id 1QEo6p-0006oE-Ux
	for bug-libtool@HIDDEN; Tue, 26 Apr 2011 15:39:45 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ingo@HIDDEN>) id 1QEo6o-0004Nj-P1
	for bug-libtool@HIDDEN; Tue, 26 Apr 2011 15:39:43 -0400
Received: from mail01do.versatel.de ([89.245.129.21]:62423)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ingo@HIDDEN>) id 1QEo6o-0004Nd-EO
	for bug-libtool@HIDDEN; Tue, 26 Apr 2011 15:39:42 -0400
Received: (qmail 13313 invoked from network); 26 Apr 2011 19:13:01 -0000
Received: from i577b923e.versanet.de (HELO alpha-toggo.eoa.de)
	(i-krabbe@HIDDEN@[87.123.146.62])
	(envelope-sender <ingo@HIDDEN>)
	by mail01do.versatel.de (qmail-ldap-1.03) with ESMTPA
	for <8557 <at> debbugs.gnu.org>; 26 Apr 2011 19:12:58 -0000
Received: by alpha-toggo.eoa.de (Postfix, from userid 1000)
	id 0E7802832FA; Tue, 26 Apr 2011 21:12:55 +0200 (CEST)
Date: Tue, 26 Apr 2011 21:12:55 +0200
From: Ingo Krabbe <ikrabbe.ask@HIDDEN>
To: Jason Vas Dias <jason.vas.dias@HIDDEN>
Subject: Re: bug#8557: libtool run against newly built libraries fails in
	setarch 'i686'
Message-ID: <20110426191255.GA22245@ask-sec>
References: <201104261137.12994.jason.vas.dias@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <201104261137.12994.jason.vas.dias@HIDDEN>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta)
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3)
X-Received-From: 140.186.70.17
X-Spam-Score: -4.6 (----)
X-Debbugs-Envelope-To: submit
Cc: bug-libtool@HIDDEN, 8557 <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: -5.3 (-----)

On Tue, Apr 26, 2011 at 11:37:11AM +0100, Jason Vas Dias wrote:
> Hi - when running in a 32-bit environment on a native x86_64 linux host,
> attempting to build gtk+-2.24.4 fails because libtool incorrectly links
> a newly built executable to /usr/lib32/ libgdk-x11-2.0.so.0, not to
> ../../gtk/.libs/libgdk-x11-2.0.so.0 :

Hi Jason,

I assume from what you tell us below

>=20
>  ENVIRONMENT:
>=20
> I source this file to setup an i686 build environment in a 'setarch i686'=
 shell instance :
>=20
>   $ cat ~/32.bit.env
> declare -x ARCH=3Di686
> declare -x AS=3D"/usr/bin/as -32"
> declare -x ASFLAGS=3D"-Wa,-32"
> declare -x CFLAGS=3D"-march=3Di686 -mtune=3Dgeneric -g -O2 -fPIC -DPIC -W=
a,--compress-debug-sections"
> declare -x LD=3D"/usr/bin/ld -melf_i386"
> declare -x LDFLAGS=3D"-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/lib6=
4/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"
> declare -x PATH=3D"/bin:/usr/bin:."
> declare -x PKG_CONFIG_PATH=3D"/usr/lib32/pkgconfig/"
>=20
>   $ setarch i686
>   $ . ~/32.bit.env
>=20
> And, trying to build gtk+2.0 (v 2.24.4 ) , it fails :
>=20
>=20
> libtool: link: ( cd ".libs" && rm -f "im-viqr.la" && ln -s "../im-viqr.la=
" "im-viqr.la" )                                                           =
                 =20
> libtool: link: /usr/bin/gcc -m32 -shared  -fPIC -DPIC  .libs/gtkimcontext=
xim.o .libs/imxim.o   -Wl,-rpath -Wl,/tmp/gtk+/gdk/.libs -Wl,-rpath -Wl,/tm=
p/gtk+/gtk/.libs -L/tmp/gtk+/gdk/.libs ../../gdk/.libs/libgdk-x11-2.0.so -L=
/usr/lib32 ../../gtk/.libs/libgtk-x11-2.0.so /tmp/gtk+/gdk/.libs/libgdk-x11=
-2.0.so /usr/lib32/libXinerama.so /usr/lib32/libXrandr.so -lXext /usr/lib32=
/libXcursor.so /usr/lib32/libpangocairo-1.0.so /usr/lib32/libXcomposite.so =
/usr/lib32/libXdamage.so /usr/lib32/libXfixes.so /usr/lib32/libatk-1.0.so /=
usr/lib32/libcairo.so /usr/lib32/libpixman-1.so -lEGL /usr/lib32/libpng15.s=
o /usr/lib32/libxcb-dri2.so -ludev /usr/lib32/libxcb-shm.so /usr/lib32/libX=
11-xcb.so /usr/lib32/libxcb-render.so /usr/lib32/libXrender.so /usr/lib32/l=
ibX11.so /usr/lib32/libxcb.so /usr/lib32/libXau.so /usr/lib32/libXdmcp.so -=
lGL -lOpenVG /usr/lib32/libgdk_pixbuf-2.0.so /usr/lib32/libgio-2.0.so -lres=
olv /usr/lib32/libpangoft2-1.0.so /usr/lib32/libpango-1.0.so -lm /usr/lib32=
/libfreetype.so -lz -lfontconfig /usr/lib32/libgobject-2.0.so /usr/lib32/li=
bgmodule-2.0.so -ldl /usr/lib32/libgthread-2.0.so -lpthread /usr/lib32/libg=
lib-2.0.so /usr/lib32/libiconv.so /usr/lib32/libpcre.so -lrt  -m32 -march=
=3Di686 -mtune=3Dgeneric -O2 -Wl,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0=
/32 -Wl,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/lib32 -Wl,-L/usr/lib32 -Wl,-L/=
lib32 -Wl,-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 -Wl,--dynamic-linker -Wl,/lib=
32/ld-linux.so.2 -pthread   -pthread -Wl,-soname -Wl,im-xim.so -o .libs/im-=
xim.so                                                                     =
                 =20
> libtool: link: ( cd ".libs" && rm -f "im-xim.la" && ln -s "../im-xim.la" =
"im-xim.la" )                                                              =
                 =20
> ../../gtk/gtk-query-immodules-2.0 im-am-et.la im-cedilla.la im-cyrillic-t=
ranslit.la  im-inuktitut.la im-ipa.la im-multipress.la im-thai.la im-ti-er.=
la im-ti-et.la im-viqr.la im-xim.la  > gtk.immodules                       =
                                                                           =
                                 =20

> Cannot load module /tmp/gtk+/modules/input/im-xim.la: /tmp/gtk+/modules/i=
nput/.libs/im-xim.so: undefined symbol: gtk_widget_is_toplevel             =
                 =20
> /tmp/gtk+/modules/input/im-xim.la does not export GTK+ IM module API: /tm=
p/gtk+/modules/input/.libs/im-xim.so: undefined symbol: gtk_widget_is_tople=
vel              =20
> make[3]: *** [gtk.immodules] Error 1                                     =
                                                                           =
                 =20
> make[3]: Leaving directory `/tmp/gtk+/modules/input'                     =
                                                                           =
                 =20

That the problem is not the link itself, but some flaw in the internal
compilation of the LD_LIBRARY_PATH for temporary executables within the
build tree: Here "../../gtk/gtk-query-immodules-2.0".

This problem affects all exectuables libtool links and the build process
uses them directly from the build tree, if some used libraries are a
modified part of the build process themselves and if these library
version are already installed with the same version: Here
"libgtk-x11-2.0.so", which is installed and a modified version exists
in "../../gtk/.libs", as I assume.

You will notice that ../../gtk/gtk-query-immodules-2.0 is a script with
an embedded LD_LIBRARY_PATH that points to /usr/lib32.

>=20
> Indeed, even this fails :
>=20
> $ LD_LIBRARY_PATH=3D../../gtk/.libs:../../gdk/.libs LD_PRELINK=3D../../gt=
k/.libs/libgtk-x11-2.0.so:../../gdk/.libs/libgdk-x11-2.0.so /tmp/gtk+/gtk/.=
libs/lt-gtk-query-immodules-2.0 im-am-et.la im-cedilla.la im-cyrillic-trans=
lit.la  im-inuktitut.la im-ipa.la im-multipress.la im-thai.la im-ti-er.la i=
m-ti-et.la im-viqr.la im-xim.la  > gtk.immodules
> Cannot load module /tmp/gtk+/modules/input/im-xim.la: /tmp/gtk+/modules/i=
nput/.libs/im-xim.so: undefined symbol: gtk_widget_is_toplevel
> /tmp/gtk+/modules/input/im-xim.la does not export GTK+ IM module API: /tm=
p/gtk+/modules/input/.libs/im-xim.so: undefined symbol: gtk_widget_is_tople=
vel

This should work though. At least LD_LIBRARY_PATH=3D../../gtk/.libs ldd
/tmp/gtk+/gtk/.libs/lt-gtk-query-immodules-2.0 should get you the
correct list of libraries.

Also try

export LD_LIBRARY_PATH=3D../../gtk/.libs
/tmp/gtk+/gtk/.libs/lt-gtk-query-immodules-2.0 im-am-et.la \
im-cedilla.la im-cyrillic-translit.la  im-inuktitut.la im-ipa.la \
im-multipress.la im-thai.la im-ti-er.la im-ti-et.la im-viqr.la \
im-xim.la=20

or tune the embedded LD_LIBRARY_PATH in=20
=2E./../gtk/gtk-query-immodules-2.0

>=20
> I think you need to be repeating the  '-Wl,-rpath,/tmp/gtk+/gdk/.libs:/tm=
p/gtk+/gtk/.libs' also as:  '-Wl,-rpath-link,/tmp/gtk+/gdk/.libs:/tmp/gtk+/=
gtk/.libs'  , because some link module is linked
> internally here to libgtk-x11-2.0.so , so the -rpath value is not used, j=
ust -rpath-link (unset) so /usr/lib32/libgtk-x11.2.0.so from the previous g=
tk+-2.0 version is picked up .
>=20
> This problem does not occur with a native x86_64 build, because I do not =
need to set -rpath for such builds.

I have posted some patch for this behaviour some time ago against libtool
git source, that reorders the compiled LD_LIBRARY_PATH for the temporary
executable scripts.

bye ingo

Information forwarded to owner <at> debbugs.gnu.org, bug-libtool@HIDDEN:
bug#8557; Package libtool. Full text available.

Message received at 8557 <at> debbugs.gnu.org:

Received: (at 8557) by debbugs.gnu.org; 26 Apr 2011 19:30:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 26 15:30:05 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 1QEnxP-0007tc-TM
	for submit <at> debbugs.gnu.org; Tue, 26 Apr 2011 15:30:05 -0400
Received: from mail01do.versatel.de ([89.245.129.21])
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <ingo@HIDDEN>) id 1QEnh5-0007WO-6i
	for 8557 <at> debbugs.gnu.org; Tue, 26 Apr 2011 15:13:08 -0400
Received: (qmail 13313 invoked from network); 26 Apr 2011 19:13:01 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	spamkill18do.versatel-west.de
X-Spam-Status: No, score=1.2
Received: from i577b923e.versanet.de (HELO alpha-toggo.eoa.de)
	(i-krabbe@HIDDEN@[87.123.146.62])
	(envelope-sender <ingo@HIDDEN>)
	by mail01do.versatel.de (qmail-ldap-1.03) with ESMTPA
	for <8557 <at> debbugs.gnu.org>; 26 Apr 2011 19:12:58 -0000
Received: by alpha-toggo.eoa.de (Postfix, from userid 1000)
	id 0E7802832FA; Tue, 26 Apr 2011 21:12:55 +0200 (CEST)
Date: Tue, 26 Apr 2011 21:12:55 +0200
From: Ingo Krabbe <ikrabbe.ask@HIDDEN>
To: Jason Vas Dias <jason.vas.dias@HIDDEN>
Subject: Re: bug#8557: libtool run against newly built libraries fails in
	setarch 'i686'
Message-ID: <20110426191255.GA22245@ask-sec>
References: <201104261137.12994.jason.vas.dias@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <201104261137.12994.jason.vas.dias@HIDDEN>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -2.6 (--)
X-Debbugs-Envelope-To: 8557
X-Mailman-Approved-At: Tue, 26 Apr 2011 15:29:59 -0400
Cc: bug-libtool@HIDDEN, 8557 <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: -2.6 (--)

On Tue, Apr 26, 2011 at 11:37:11AM +0100, Jason Vas Dias wrote:
> Hi - when running in a 32-bit environment on a native x86_64 linux host,
> attempting to build gtk+-2.24.4 fails because libtool incorrectly links
> a newly built executable to /usr/lib32/ libgdk-x11-2.0.so.0, not to
> ../../gtk/.libs/libgdk-x11-2.0.so.0 :

Hi Jason,

I assume from what you tell us below

>=20
>  ENVIRONMENT:
>=20
> I source this file to setup an i686 build environment in a 'setarch i686'=
 shell instance :
>=20
>   $ cat ~/32.bit.env
> declare -x ARCH=3Di686
> declare -x AS=3D"/usr/bin/as -32"
> declare -x ASFLAGS=3D"-Wa,-32"
> declare -x CFLAGS=3D"-march=3Di686 -mtune=3Dgeneric -g -O2 -fPIC -DPIC -W=
a,--compress-debug-sections"
> declare -x LD=3D"/usr/bin/ld -melf_i386"
> declare -x LDFLAGS=3D"-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/lib6=
4/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"
> declare -x PATH=3D"/bin:/usr/bin:."
> declare -x PKG_CONFIG_PATH=3D"/usr/lib32/pkgconfig/"
>=20
>   $ setarch i686
>   $ . ~/32.bit.env
>=20
> And, trying to build gtk+2.0 (v 2.24.4 ) , it fails :
>=20
>=20
> libtool: link: ( cd ".libs" && rm -f "im-viqr.la" && ln -s "../im-viqr.la=
" "im-viqr.la" )                                                           =
                 =20
> libtool: link: /usr/bin/gcc -m32 -shared  -fPIC -DPIC  .libs/gtkimcontext=
xim.o .libs/imxim.o   -Wl,-rpath -Wl,/tmp/gtk+/gdk/.libs -Wl,-rpath -Wl,/tm=
p/gtk+/gtk/.libs -L/tmp/gtk+/gdk/.libs ../../gdk/.libs/libgdk-x11-2.0.so -L=
/usr/lib32 ../../gtk/.libs/libgtk-x11-2.0.so /tmp/gtk+/gdk/.libs/libgdk-x11=
-2.0.so /usr/lib32/libXinerama.so /usr/lib32/libXrandr.so -lXext /usr/lib32=
/libXcursor.so /usr/lib32/libpangocairo-1.0.so /usr/lib32/libXcomposite.so =
/usr/lib32/libXdamage.so /usr/lib32/libXfixes.so /usr/lib32/libatk-1.0.so /=
usr/lib32/libcairo.so /usr/lib32/libpixman-1.so -lEGL /usr/lib32/libpng15.s=
o /usr/lib32/libxcb-dri2.so -ludev /usr/lib32/libxcb-shm.so /usr/lib32/libX=
11-xcb.so /usr/lib32/libxcb-render.so /usr/lib32/libXrender.so /usr/lib32/l=
ibX11.so /usr/lib32/libxcb.so /usr/lib32/libXau.so /usr/lib32/libXdmcp.so -=
lGL -lOpenVG /usr/lib32/libgdk_pixbuf-2.0.so /usr/lib32/libgio-2.0.so -lres=
olv /usr/lib32/libpangoft2-1.0.so /usr/lib32/libpango-1.0.so -lm /usr/lib32=
/libfreetype.so -lz -lfontconfig /usr/lib32/libgobject-2.0.so /usr/lib32/li=
bgmodule-2.0.so -ldl /usr/lib32/libgthread-2.0.so -lpthread /usr/lib32/libg=
lib-2.0.so /usr/lib32/libiconv.so /usr/lib32/libpcre.so -lrt  -m32 -march=
=3Di686 -mtune=3Dgeneric -O2 -Wl,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0=
/32 -Wl,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/lib32 -Wl,-L/usr/lib32 -Wl,-L/=
lib32 -Wl,-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 -Wl,--dynamic-linker -Wl,/lib=
32/ld-linux.so.2 -pthread   -pthread -Wl,-soname -Wl,im-xim.so -o .libs/im-=
xim.so                                                                     =
                 =20
> libtool: link: ( cd ".libs" && rm -f "im-xim.la" && ln -s "../im-xim.la" =
"im-xim.la" )                                                              =
                 =20
> ../../gtk/gtk-query-immodules-2.0 im-am-et.la im-cedilla.la im-cyrillic-t=
ranslit.la  im-inuktitut.la im-ipa.la im-multipress.la im-thai.la im-ti-er.=
la im-ti-et.la im-viqr.la im-xim.la  > gtk.immodules                       =
                                                                           =
                                 =20

> Cannot load module /tmp/gtk+/modules/input/im-xim.la: /tmp/gtk+/modules/i=
nput/.libs/im-xim.so: undefined symbol: gtk_widget_is_toplevel             =
                 =20
> /tmp/gtk+/modules/input/im-xim.la does not export GTK+ IM module API: /tm=
p/gtk+/modules/input/.libs/im-xim.so: undefined symbol: gtk_widget_is_tople=
vel              =20
> make[3]: *** [gtk.immodules] Error 1                                     =
                                                                           =
                 =20
> make[3]: Leaving directory `/tmp/gtk+/modules/input'                     =
                                                                           =
                 =20

That the problem is not the link itself, but some flaw in the internal
compilation of the LD_LIBRARY_PATH for temporary executables within the
build tree: Here "../../gtk/gtk-query-immodules-2.0".

This problem affects all exectuables libtool links and the build process
uses them directly from the build tree, if some used libraries are a
modified part of the build process themselves and if these library
version are already installed with the same version: Here
"libgtk-x11-2.0.so", which is installed and a modified version exists
in "../../gtk/.libs", as I assume.

You will notice that ../../gtk/gtk-query-immodules-2.0 is a script with
an embedded LD_LIBRARY_PATH that points to /usr/lib32.

>=20
> Indeed, even this fails :
>=20
> $ LD_LIBRARY_PATH=3D../../gtk/.libs:../../gdk/.libs LD_PRELINK=3D../../gt=
k/.libs/libgtk-x11-2.0.so:../../gdk/.libs/libgdk-x11-2.0.so /tmp/gtk+/gtk/.=
libs/lt-gtk-query-immodules-2.0 im-am-et.la im-cedilla.la im-cyrillic-trans=
lit.la  im-inuktitut.la im-ipa.la im-multipress.la im-thai.la im-ti-er.la i=
m-ti-et.la im-viqr.la im-xim.la  > gtk.immodules
> Cannot load module /tmp/gtk+/modules/input/im-xim.la: /tmp/gtk+/modules/i=
nput/.libs/im-xim.so: undefined symbol: gtk_widget_is_toplevel
> /tmp/gtk+/modules/input/im-xim.la does not export GTK+ IM module API: /tm=
p/gtk+/modules/input/.libs/im-xim.so: undefined symbol: gtk_widget_is_tople=
vel

This should work though. At least LD_LIBRARY_PATH=3D../../gtk/.libs ldd
/tmp/gtk+/gtk/.libs/lt-gtk-query-immodules-2.0 should get you the
correct list of libraries.

Also try

export LD_LIBRARY_PATH=3D../../gtk/.libs
/tmp/gtk+/gtk/.libs/lt-gtk-query-immodules-2.0 im-am-et.la \
im-cedilla.la im-cyrillic-translit.la  im-inuktitut.la im-ipa.la \
im-multipress.la im-thai.la im-ti-er.la im-ti-et.la im-viqr.la \
im-xim.la=20

or tune the embedded LD_LIBRARY_PATH in=20
=2E./../gtk/gtk-query-immodules-2.0

>=20
> I think you need to be repeating the  '-Wl,-rpath,/tmp/gtk+/gdk/.libs:/tm=
p/gtk+/gtk/.libs' also as:  '-Wl,-rpath-link,/tmp/gtk+/gdk/.libs:/tmp/gtk+/=
gtk/.libs'  , because some link module is linked
> internally here to libgtk-x11-2.0.so , so the -rpath value is not used, j=
ust -rpath-link (unset) so /usr/lib32/libgtk-x11.2.0.so from the previous g=
tk+-2.0 version is picked up .
>=20
> This problem does not occur with a native x86_64 build, because I do not =
need to set -rpath for such builds.

I have posted some patch for this behaviour some time ago against libtool
git source, that reorders the compiled LD_LIBRARY_PATH for the temporary
executable scripts.

bye ingo

Information forwarded to owner <at> debbugs.gnu.org, bug-libtool@HIDDEN:
bug#8557; Package libtool. Full text available.

Message received at submit <at> debbugs.gnu.org:

Received: (at submit) by debbugs.gnu.org; 26 Apr 2011 10:37:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 26 06:37:39 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 1QEfeE-0002OV-A5
	for submit <at> debbugs.gnu.org; Tue, 26 Apr 2011 06:37:39 -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 1QEfeB-0002OD-Ff
	for submit <at> debbugs.gnu.org; Tue, 26 Apr 2011 06:37:36 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jason.vas.dias@HIDDEN>) id 1QEfe5-0002hs-55
	for submit <at> debbugs.gnu.org; Tue, 26 Apr 2011 06:37:30 -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]:33043)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jason.vas.dias@HIDDEN>) id 1QEfe5-0002hi-2S
	for submit <at> debbugs.gnu.org; Tue, 26 Apr 2011 06:37:29 -0400
Received: from eggs.gnu.org ([140.186.70.92]:59739)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jason.vas.dias@HIDDEN>) id 1QEfe3-0005lC-Nc
	for bug-libtool@HIDDEN; Tue, 26 Apr 2011 06:37:29 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jason.vas.dias@HIDDEN>) id 1QEfds-0002gt-AW
	for bug-libtool@HIDDEN; Tue, 26 Apr 2011 06:37:27 -0400
Received: from mail-wy0-f169.google.com ([74.125.82.169]:47987)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jason.vas.dias@HIDDEN>) id 1QEfds-0002gl-2I
	for bug-libtool@HIDDEN; Tue, 26 Apr 2011 06:37:16 -0400
Received: by wyf19 with SMTP id 19so406954wyf.0
	for <bug-libtool@HIDDEN>; Tue, 26 Apr 2011 03:37:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:to:subject:from:reply-to:date:mime-version
	:content-type:content-transfer-encoding:message-id;
	bh=iIokVxBjxoTsqKpxTnhsT/Dekz1BX1rOqvtXEsjJ3Gs=;
	b=G58P0I4FQxYGvmrqQuwTupwSjfo6wdHaQSOy5sDiostUu5OvTQ6WpiW7SS7MMu67ep
	5WMLb3U3N1925p0aoWcOHK6hN68xPZMHI9Maa2xOwd21q+/c5ctOSlOhdGta1CLMs/xy
	Xw+W9LGnDr7EQYwezXqI0tejW1ZhQdkmvmDzU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=to:subject:from:reply-to:date:mime-version:content-type
	:content-transfer-encoding:message-id;
	b=DTK/Q4H5461L6sAu5uRTg+5C+yOLDaldJY8VVCoH54Gymc3+/9AGMPf86Pu/BH1Y26
	CUVL16ULo5SCi4e/iBl/X3xcHVllnIhvd0GxPD4q1pJQrX9tUyDrGEI2ulHn6GGxaaUO
	nzi6ez5P8NpHiA+SNt+bVpix71TTTZjAzfs8Y=
Received: by 10.216.254.142 with SMTP id h14mr607418wes.31.1303814235039;
	Tue, 26 Apr 2011 03:37:15 -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 t5sm2938578wes.9.2011.04.26.03.37.13
	(version=SSLv3 cipher=OTHER); Tue, 26 Apr 2011 03:37:14 -0700 (PDT)
To: bug-libtool@HIDDEN
Subject: libtool run against newly built libraries fails in setarch 'i686'
From: Jason Vas Dias <jason.vas.dias@HIDDEN>
Date: Tue, 26 Apr 2011 11:37:11 +0100
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201104261137.12994.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.5 (-----)
X-Debbugs-Envelope-To: submit
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.6 (-----)

Hi - when running in a 32-bit environment on a native x86_64 linux host,
attempting to build gtk+-2.24.4 fails because libtool incorrectly links
a newly built executable to /usr/lib32/ libgdk-x11-2.0.so.0, not to
=2E./../gtk/.libs/libgdk-x11-2.0.so.0 :

 ENVIRONMENT:

I source this file to setup an i686 build environment in a 'setarch i686' s=
hell instance :

  $ cat ~/32.bit.env
declare -x ARCH=3Di686
declare -x AS=3D"/usr/bin/as -32"
declare -x ASFLAGS=3D"-Wa,-32"
declare -x CFLAGS=3D"-march=3Di686 -mtune=3Dgeneric -g -O2 -fPIC -DPIC -Wa,=
=2D-compress-debug-sections"
declare -x LD=3D"/usr/bin/ld -melf_i386"
declare -x LDFLAGS=3D"-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/l=
ib32:/usr/lib32:/lib32,--dynamic-linker,/lib32/ld-linux.so.2"
declare -x PATH=3D"/bin:/usr/bin:."
declare -x PKG_CONFIG_PATH=3D"/usr/lib32/pkgconfig/"

  $ setarch i686
  $ . ~/32.bit.env

And, trying to build gtk+2.0 (v 2.24.4 ) , it fails :


libtool: link: ( cd ".libs" && rm -f "im-viqr.la" && ln -s "../im-viqr.la" =
"im-viqr.la" )                                                             =
               =20
libtool: link: /usr/bin/gcc -m32 -shared  -fPIC -DPIC  .libs/gtkimcontextxi=
m.o .libs/imxim.o   -Wl,-rpath -Wl,/tmp/gtk+/gdk/.libs -Wl,-rpath -Wl,/tmp/=
gtk+/gtk/.libs -L/tmp/gtk+/gdk/.libs ../../gdk/.libs/libgdk-x11-2.0.so -L/u=
sr/lib32 ../../gtk/.libs/libgtk-x11-2.0.so /tmp/gtk+/gdk/.libs/libgdk-x11-2=
=2E0.so /usr/lib32/libXinerama.so /usr/lib32/libXrandr.so -lXext /usr/lib32=
/libXcursor.so /usr/lib32/libpangocairo-1.0.so /usr/lib32/libXcomposite.so =
/usr/lib32/libXdamage.so /usr/lib32/libXfixes.so /usr/lib32/libatk-1.0.so /=
usr/lib32/libcairo.so /usr/lib32/libpixman-1.so -lEGL /usr/lib32/libpng15.s=
o /usr/lib32/libxcb-dri2.so -ludev /usr/lib32/libxcb-shm.so /usr/lib32/libX=
11-xcb.so /usr/lib32/libxcb-render.so /usr/lib32/libXrender.so /usr/lib32/l=
ibX11.so /usr/lib32/libxcb.so /usr/lib32/libXau.so /usr/lib32/libXdmcp.so -=
lGL -lOpenVG /usr/lib32/libgdk_pixbuf-2.0.so /usr/lib32/libgio-2.0.so -lres=
olv /usr/lib32/libpangoft2-1.0.so /usr/lib32/libpango-1.0.so -lm /usr/lib32=
/libfreetype.so -lz -lfontconfig /usr/lib32/libgobject-2.0.so /usr/lib32/li=
bgmodule-2.0.so -ldl /usr/lib32/libgthread-2.0.so -lpthread /usr/lib32/libg=
lib-2.0.so /usr/lib32/libiconv.so /usr/lib32/libpcre.so -lrt  -m32 -march=
=3Di686 -mtune=3Dgeneric -O2 -Wl,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0=
/32 -Wl,-L/usr/lib64/gcc/x86_64-pc-linux-gnu/lib32 -Wl,-L/usr/lib32 -Wl,-L/=
lib32 -Wl,-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 -Wl,--dynamic-linker -Wl,/lib=
32/ld-linux.so.2 -pthread   -pthread -Wl,-soname -Wl,im-xim.so -o .libs/im-=
xim.so                                                                     =
                 =20
libtool: link: ( cd ".libs" && rm -f "im-xim.la" && ln -s "../im-xim.la" "i=
m-xim.la" )                                                                =
               =20
=2E./../gtk/gtk-query-immodules-2.0 im-am-et.la im-cedilla.la im-cyrillic-t=
ranslit.la  im-inuktitut.la im-ipa.la im-multipress.la im-thai.la im-ti-er.=
la im-ti-et.la im-viqr.la im-xim.la  > gtk.immodules                       =
                                                                           =
                                 =20
Cannot load module /tmp/gtk+/modules/input/im-xim.la: /tmp/gtk+/modules/inp=
ut/.libs/im-xim.so: undefined symbol: gtk_widget_is_toplevel               =
               =20
/tmp/gtk+/modules/input/im-xim.la does not export GTK+ IM module API: /tmp/=
gtk+/modules/input/.libs/im-xim.so: undefined symbol: gtk_widget_is_topleve=
l              =20
make[3]: *** [gtk.immodules] Error 1                                       =
                                                                           =
               =20
make[3]: Leaving directory `/tmp/gtk+/modules/input'                       =
                                                                           =
               =20

Indeed, even this fails :

$ LD_LIBRARY_PATH=3D../../gtk/.libs:../../gdk/.libs LD_PRELINK=3D../../gtk/=
=2Elibs/libgtk-x11-2.0.so:../../gdk/.libs/libgdk-x11-2.0.so /tmp/gtk+/gtk/.=
libs/lt-gtk-query-immodules-2.0 im-am-et.la im-cedilla.la im-cyrillic-trans=
lit.la  im-inuktitut.la im-ipa.la im-multipress.la im-thai.la im-ti-er.la i=
m-ti-et.la im-viqr.la im-xim.la  > gtk.immodules
Cannot load module /tmp/gtk+/modules/input/im-xim.la: /tmp/gtk+/modules/inp=
ut/.libs/im-xim.so: undefined symbol: gtk_widget_is_toplevel
/tmp/gtk+/modules/input/im-xim.la does not export GTK+ IM module API: /tmp/=
gtk+/modules/input/.libs/im-xim.so: undefined symbol: gtk_widget_is_toplevel

I think you need to be repeating the  '-Wl,-rpath,/tmp/gtk+/gdk/.libs:/tmp/=
gtk+/gtk/.libs' also as:  '-Wl,-rpath-link,/tmp/gtk+/gdk/.libs:/tmp/gtk+/gt=
k/.libs'  , because some link module is linked
internally here to libgtk-x11-2.0.so , so the -rpath value is not used, jus=
t -rpath-link (unset) so /usr/lib32/libgtk-x11.2.0.so from the previous gtk=
+-2.0 version is picked up .

This problem does not occur with a native x86_64 build, because I do not ne=
ed to set -rpath for such builds.

This is with toolchain :

$ eval {gcc,ld,/sbin/ldconfig,libtool,autoconf,automake}' --version; ' | gr=
ep '[(]G'
gcc (GCC) 4.6.0
GNU ld (GNU Binutils) 2.21.51.20110407
ldconfig (GNU libc) 2.13
libtool (GNU libtool 1.3332 2011-04-10) 2.4.1a
autoconf (GNU Autoconf) 2.68
automake (GNU automake) 1.11a

with all installed files unmodified from original installation .

NOTE :  I think this bug is related to (but different from) bug #8537  :
 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D8537

While I've been using your excellent libtool script for years without probi=
ng to far into its implementation ,=20
I have noticed issues such as these crop up from time to time,  and am fina=
lly resolved to do something about it -
I'll continue investigating and submit a patch to fix this if I find one .

All the best,
Jason

Acknowledgement sent to jason.vas.dias@HIDDEN:
New bug report received and forwarded. Copy sent to bug-libtool@HIDDEN. Full text available.

Report forwarded to owner <at> debbugs.gnu.org, bug-libtool@HIDDEN:
bug#8557; Package libtool. Full text available.

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.