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

Previous Next

Package: coreutils;

Reported by: Paul Campbell <paul <at> taniwha.com>

Date: Thu, 10 Nov 2016 01:06:02 UTC

Severity: normal

Done: Bernhard Voelker <mail <at> bernhard-voelker.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Campbell <paul <at> taniwha.com>
Subject: bug#24916: closed (Re: bug#24916: Followup to AR=ar issues)
Date: Thu, 10 Nov 2016 08:27:02 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#24916: Followup to AR=ar issues

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 24916 <at> debbugs.gnu.org.

-- 
24916: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24916
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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


[Message part 3 (message/rfc822, inline)]
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




This bug report was last modified 8 years and 196 days ago.

Previous Next


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