Subject: Re: pkgsrc gcc3 vs. sparc64?
To: Rafal Boni <>
From: Andrey Petrov <>
List: tech-toolchain
Date: 06/30/2003 23:06:22
On Mon, Jun 30, 2003 at 06:30:47PM -0400, Rafal Boni wrote:
> Folks:
>  	In hopes that I'd get past the line of ICEs building C++ stuff 
> 	with gcc 2.95.3 on sparc64, I installed the gcc3.3 package, but
> 	it appears to have other problems... 
> 	The problem is that libgcc_s (/usr/pkg/gcc-3.3/lib/
> 	appears to be not-fully-PIC ... it still contains relocs that 
> 	AFAIK shouldn't exist in a PIC/dynamic object.  
> 	Even the simple program below dies when built with gcc3's c++:
> #include <iostream>
> using namespace std;
> main()
> {
>     cout << "Hello, whirled!\n";
> }
> 	The error it gets is:
> /usr/pkg/gcc-3.3/lib/ Undefined symbol "" (symnum = 11)
> 	An objdump -R on the library reveals the following relocs which
> 	I believe should have either never been created (due to PIC-ness)
> 	or resolved much earlier in the process... I've trimmed the list
> 	of offensive-looking relocs, since there were quite a few of them:
> 	Examination of LD_DEBUG=1 traces from agrees with the above
> 	assesment -- the runtime linker dies trying to resolve a type 34
> 	reloc with no name.
> /usr/pkg/gcc-3.3/lib/     file format elf64-sparc
> OFFSET           TYPE              VALUE
> [...]
> 00000000000055b4 R_SPARC_HH22      .rodata
> 00000000000055c8 R_SPARC_HH22      .rodata
> 00000000000055cc R_SPARC_LM22      .rodata
> 00000000000055d0 R_SPARC_HM10      .rodata
> 00000000000055e8 R_SPARC_LO10      .rodata
> 00000000000056d4 R_SPARC_HH22      .rodata+0x0000000000000100
> 00000000000056d8 R_SPARC_LM22      .rodata+0x0000000000000100
> 00000000000056dc R_SPARC_HM10      .rodata+0x0000000000000100
> [..]
> 	Are other people using the gcc3 package succesfully on sparc64?
> 	Is this some sort of bootstrap issue?  Is my machine just being
> 	mean and producing bogus libraries to spite me? ;-)
> 	This is with gcc3-3.3nb1, on NetBSD/sparc64-1.6T with userland
> 	and kernel from the beginning of June (kernel from June 1st,
> 	userland from June 2nd) but IIRC both built from the same set
> 	of sources.  The gcc3 package did *not* install the binutils
> 	from pkgsrc, so I'm using the system binutils, which is version

I don't know how to fix it properly so workarounds:
	configure with --disable-shared so there will be no,
	set TARGET_LIBGCC2_CFLAGS to usual -fPIC -DPIC in gcc/Makefile (after configure),
	(there will be PIC penalty for libgcc_s.a).

I think ideally we should support multilib build and have both 32 and 64 bit
libraries, I looked there a little but put it off. And I also saw another issue
arisen from gcc33