GNU bug report logs - #24916
Followup to AR=ar issues

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24916 in the body.
You can then email your comments to 24916 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Campbell <paul <at> taniwha.com>
To: bug-coreutils <at> gnu.org
Subject: Followup to AR=ar issues
Date: Thu, 10 Nov 2016 13:36:20 +1300

I'm an OpenWRT user - which builds just about everything as cross tools - lots 
of systems don't do AR and RANLIB paths correctly .... and it's not really 
been a problem until recently ....

I'm also an Ubuntu user and until I synced to their latest release OpenWRT 
builds worked great .... now a bunch of stuff fails  .... the underlying 
problem seems to be that now by default ar run on an Intel platform adds a 
SYM64 header to archives even if they only contain 32-bit objects (in my case 
ARM ones) - the older cross tools just throw their hands up and barf

I wonder if a stopgap solution might be to accept that AR is broken in the 
build environments and make ar smarter about what it generates, only adding 
that header if 64-bit objects are there

	Paul

Message #10 received at 24916-done <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Paul Campbell <paul <at> taniwha.com>, 24916-done <at> debbugs.gnu.org
Subject: Re: bug#24916: Followup to AR=ar issues
Date: Thu, 10 Nov 2016 09:26:42 +0100

tag 24916 notabug
thanks

On 11/10/2016 01:36 AM, Paul Campbell wrote:
> I'm an OpenWRT user - which builds just about everything as cross tools - lots 
> of systems don't do AR and RANLIB paths correctly .... and it's not really 
> been a problem until recently ....
> 
> I'm also an Ubuntu user and until I synced to their latest release OpenWRT 
> builds worked great .... now a bunch of stuff fails  .... the underlying 
> problem seems to be that now by default ar run on an Intel platform adds a 
> SYM64 header to archives even if they only contain 32-bit objects (in my case 
> ARM ones) - the older cross tools just throw their hands up and barf
> 
> I wonder if a stopgap solution might be to accept that AR is broken in the 
> build environments and make ar smarter about what it generates, only adding 
> that header if 64-bit objects are there

ar is not part of coreutils but from binutils.  Therefore, there's nothing
we can do here regarding this problem. Thus, I'm marking this as 'not a bug'
in our bug tracker.

Have a nice day,
Berny

Previous Next

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