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/libgcc_s.so.1)
> 	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/libgcc_s.so.1: 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 ld.so 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/libgcc_s.so:     file format elf64-sparc
> 
> DYNAMIC RELOCATION RECORDS
> 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
> 	2.13.2.1.
> 

I don't know how to fix it properly so workarounds:
	configure with --disable-shared so there will be no libgcc_s.so,
or
	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 http://mail-index.netbsd.org/tech-kern/2003/02/12/0023.html

	Andrey