Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 57280

Summary: ranlib in binutils on amd64 doesn't make 32bit .a
Product: Gentoo Linux Reporter: Jocelyn Mayer <l_indien>
Component: Current packagesAssignee: Gentoo Toolchain Maintainers <toolchain>
Status: VERIFIED WORKSFORME    
Severity: normal CC: amd64, david+gentoo.org, skandalfo
Priority: High    
Version: unspecified   
Hardware: AMD64   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Jocelyn Mayer 2004-07-16 04:34:34 UTC
Trying to emerge:
[ebuild     U ] sys-devel/gcc-3.3.4-r1 [3.3.3-r6] +X -bootstrap -build -debug -debug +f77 -gcj -hardened +multilib +nls +objc +pic -static -(uclibc)  0 kB
fails.
gcc compiles itself all right, but compiling new libiberty fails during configure,
claiming xgcc cannot create executables.
I extracted this from config.log:

configure:1593: /var/tmp/portage/gcc-3.3.4-r1/work/build/gcc/xgcc -B/var/tmp/por
tage/gcc-3.3.4-r1/work/build/gcc/ -B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-lin
ux-gnu/lib/ -isystem /usr/x86_64-linux-gnu/include  -m32 -o conftest -O2 -O2 -pi
pe   conftest.c  1>&5
/var/tmp/portage/gcc-3.3.4-r1/work/build/gcc/32/libgcc.a: could not read symbols
: Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status
configure: failed program was:
#line 1582 "configure"
#include "confdefs.h"
#include <ctype.h>
#define ISLOWER(c) ('a' <= (c) && (c) <= 'z')
#define TOUPPER(c) (ISLOWER(c) ? 'A' + ((c) - 'a') : (c))
#define XOR(e, f) (((e) && !(f)) || (!(e) && (f)))
int main () { int i; for (i = 0; i < 256; i++)
if (XOR (islower (i), ISLOWER (i)) || toupper (i) != TOUPPER (i)) exit(2);
exit (0); }

configure:1617: checking for uintptr_t
configure:1658: checking for pid_t
configure:2448: checking whether the C compiler (/var/tmp/portage/gcc-3.3.4-r1/w
ork/build/gcc/xgcc -B/var/tmp/portage/gcc-3.3.4-r1/work/build/gcc/ -B/usr/x86_64
-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ -isystem /usr/x86_64-linux-gnu/incl
ude  -m32 -O2 -O2 -pipe ) works
configure:2464: /var/tmp/portage/gcc-3.3.4-r1/work/build/gcc/xgcc -B/var/tmp/por
tage/gcc-3.3.4-r1/work/build/gcc/ -B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-lin
ux-gnu/lib/ -isystem /usr/x86_64-linux-gnu/include  -m32 -o conftest -O2 -O2 -pi
pe   conftest.c  1>&5
/var/tmp/portage/gcc-3.3.4-r1/work/build/gcc/32/libgcc.a: could not read symbols
: Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status
configure: failed program was:

#line 2459 "configure"
#include "confdefs.h"

main(){return(0);}



Reproducible: Always
Steps to Reproduce:
1. emerge -b --deep --update --verbose =sys-devel/gcc-3.3.4-r1 

Actual Results:  
compilation fails

Expected Results:  
emerge should succeed !
Comment 1 Martin Schlemmer (RETIRED) gentoo-dev 2004-07-17 14:27:40 UTC
No amd64 here to test - anybody else ?
Comment 2 maciek 2004-07-20 14:30:31 UTC
The compilation bombs in the same place on my box, however, the message in
config.log is somewhat different:

configure:1617: checking for uintptr_t
configure:1658: checking for pid_t
configure:2448: checking whether the C compiler (/var/tmp/portage/gcc-3.3.4-r1/work/build/gcc/xgcc -B/var/tmp/portage/gcc-3.3.4-r1/work/build/gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include  -m32 -O2 -m64 -O2 -pipe ) works
configure:2464: /var/tmp/portage/gcc-3.3.4-r1/work/build/gcc/xgcc -B/var/tmp/portage/gcc-3.3.4-r1/work/build/gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include  -m32 -o conftest -O2 -m64 -O2 -pipe   conftest.c  1>&5
{standard input}: Assembler messages:
{standard input}:33: Error: cannot represent relocation type BFD_RELOC_64
configure: failed program was:

#line 2459 "configure"
#include "confdefs.h"

main(){return(0);}
Comment 3 solar (RETIRED) gentoo-dev 2004-08-26 16:30:12 UTC
amd64 uses gcc-3.4.x and has had it marked stable for some time now. 
The toolchain team lacks amd64 hardware and the amd64 team never commented on this bug so I'm closing as WORKFORSOME.
Comment 4 Jocelyn Mayer 2004-09-03 00:52:06 UTC
I have the same problem trying to merge gcc 3.4.
Moreover gcc 3.4 is completelly buggy, but this is another bug (not specific to Gentoo nor specific to amd64).
Comment 5 Travis Tilley (RETIRED) gentoo-dev 2004-09-03 07:13:20 UTC
Jocelyn Mayer  - stop using mm-sources, love-sources, or whatever. you are hitting a bug that truncates the last 8k of a file.

maciek@linkline.com - my guess is you're not using the latest stable binutils?
Comment 6 Jocelyn Mayer 2004-09-03 16:24:48 UTC
I use current Gentoo sources, so don't blame me if they are buggy.
My kernel is 2.6.9-rc1 vanilla, not -mm or exotic patched one.
I add the same issue using 2.6.7 (perfectly stable, used it more than 2 monthes without any reboot).

My binutils are those marked as _stable_ for amd64:
> ld --version
GNU ld version 2.15.90.0.1.1 20040303
> qpkg -I -i sys-devel/binutils
sys-devel/binutils-2.15.90.0.1.1-r3

So, if the bug is a binutils one, that means Gentoo stable one is broken.
Not a gcc bug, that case, but still not my fault.
Comment 7 Jocelyn Mayer 2004-09-05 05:46:55 UTC
I checked more.
I first checked with objdump and hexedit and found that the .a libraries are valid (not truncated at all), which is a good point.
The problem is a ranlib bug: ranlib does nothing on 32 bits archives. Moreover, it removes the archive index if one is present.
I got a x86 chrooted Gentoo, so I did ranlib in that environment, then put the libraries back. This hack made gcc compilation go on.
I had to repeat this on every 32 bits .a library created then I reached the end of the compilation.

So, it's not a gcc ebuild bug, sorry. I'll check if it's a known binutils issue.
Comment 8 Blu3 2005-01-30 12:07:49 UTC
lv, or somebody.  can you get this fixed please?  having done research, i have found -several- bugs now on this subject and with the last comment about ranlib, things are falling into place.  this is pretty frustrating, jocelyn found the root cause of it back in september and the bugs are still unsolved :/
Comment 9 Jeremy Huddleston (RETIRED) gentoo-dev 2005-01-30 12:17:34 UTC
don't use 3.3 on amd64
Comment 10 Blu3 2005-01-30 12:26:16 UTC
3.3 actually has no relevance to this bug.  3.4 is exactly the same.  in the end it's a binutils issue.
Comment 11 Jeremy Huddleston (RETIRED) gentoo-dev 2005-01-30 15:53:34 UTC
did you USE=multitarget?  I noticed a problem with binutils USE=multitarget on amd64 a while back and haven't gotten around to figuring out the root of the problem.