The recommended way to build gcc-4.0.2 on Solaris 10 x86 is to use the binutils assembler and the solaris linker:
http://gcc.gnu.org/install/specific.html#ix86-x-solaris210 This works, as long as you suppress HAVE_GAS_COMDAT_GROUP ( see http://gcc.gnu.org/ml/gcc/2005-04/msg01332.html ) but the resulting compiler does not support -fvisibility in any useful way, because the solaris linker fails the configure check "checking linker for .hidden support". The solaris linker does support .hidden though, so I am looking into adding support for -fvisibility with solaris ld. I have run into a problem, and I have a few questions. If, for purposes of experimentation, I hack up configure so that it sets HAVE_GAS_HIDDEN unconditionally, then make bootstrap succeeds, and I can in fact use the visibility flags, pragmas, and attributes. The resulting binaries show that symbols are correctly marked as LOCL and GLOB in accordance with the visibility selections. So far, so good. The problems start when I specify an -march argument in 32 bit mode. If when compiling I pass -march=pentium, -march=pentium2, etc., I get errors when trying to link more than one object file: ld: fatal: symbol `__i686.get_pc_thunk.bx' is multiply-defined: (file thunk32.o type=FUNC; file visibility32.o type=FUNC); If I look at the assembly listings in thunk32.s and visibility32.s I see the same listing that defines __i686.get_pc_thunk.bx in both files: .section .gnu.linkonce.t.__i686.get_pc_thunk.bx,"ax",@progbits .globl __i686.get_pc_thunk.bx .hidden __i686.get_pc_thunk.bx .type __i686.get_pc_thunk.bx, @function __i686.get_pc_thunk.bx: movl (%esp), %ebx ret In these same object files, there are other .gnu.linkonce sections, but the symbol is always marked .weak: .weak _ZTV3Foo .section .gnu.linkonce.d._ZTV3Foo,"aw",@progbits .align 8 .type _ZTV3Foo, @object .size _ZTV3Foo, 16 _ZTV3Foo: .long 0 So unlike all of the other .gnu.linkonce sections, where the contained symbol is marked as .weak, __i686.get_pc_thunk.bx is marked .globl. To my mind, the linker is right to complain when linking two objects containing that definition. With COMDAT group support disabled, is it true that part of gcc's implementation of .gnu.linkonce semantics is to make the symbol in the .gnu.linkonce section weak? If so, should symbols like __i686.get_pc_thunk.* also be weak in this instance, instead of global? If not, would someone please explain why not? Would enabling COMDAT group support (the sun linker does support it) remove this problem? If so, can anyone see a way around the fact that the solaris linker considers relocations against discarded symbols a fatal error, and it is nearly inevitable that when using COMDAT groups there will be relocations in the .eh_frame or debug_info sections against .gnu.linkonce sections that will be discarded? Sorry for the length, or if this is all somehow way off base; I'm new to gcc internals... Thanks, Andrew
