I rest my case - you found /_*one*_/ of the problems which you are 
blaming on gcc but in fact is not gcc's fault. You /_*must*_/ specify 
the correct -L and -R paths to the various alternate 64 bit libs. Don't 
expect the compiler to figure it out. Of course you can also fix the 
problem by changing the defaults to the system link/loader and I'm sure 
other non-standard methods.

The bottom line is that I just don't know how to describe daylight to a 
blind man....

FYI, we are using gcc 4.1.1 - same problem and we aren't using or 
relying on just the /usr/sfw tree sine much of what comes with Solaris 
isn't 64 bit we have had to build our own libs which are kept in /opt/lib

---
Bob

Martin v. Löwis wrote:
> Martin v. Löwis <martin@v.loewis.de> added the comment:
>
> Just to demonstrate there is really a problem with the gcc installation
> (gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)), here is the
> linker line:
>
> gcc -m64 -shared
> build/temp.solaris-2.10-sun4u-2.5/net/tb0/home/loewis/25/Modules/_struct.o
> -L/usr/local/lib -o build/lib.solaris-2.10-sun4u-2.5/_struct.so
>
> and here is what gcc actually invokes (printed with -v):
>
> /usr/sfw/libexec/gcc/sparc-sun-solaris2.10/3.4.3/collect2 -V -G -dy -z
> text -Y P,/usr/lib/sparcv9 -Qy -o
> build/lib.solaris-2.10-sun4u-2.5/_struct.so
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crti.o
> /usr/ccs/lib/sparcv9/values-Xa.o
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtbegin.o
> -L/usr/local/lib -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9
> -L/usr/ccs/lib/sparcv9
> -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../sparcv9
> -L/lib/sparcv9 -L/usr/lib/sparcv9
> build/temp.solaris-2.10-sun4u-2.5/net/tb0/home/loewis/25/Modules/_struct.o
> -R/usr/sfw/lib -lgcc_s_sparcv9 -R/usr/sfw/lib -lgcc_s_sparcv9
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtend.o
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/sparcv9/crtn.o
>
> As you can see, it's picking up -lgcc_s_sparcv9 (from
> /usr/sfw/lib/sparcv9/libgcc_s_sparcv9.so), so it does link with the
> 64-bit libgcc_s.so.1. However, when then trying to import the module, it
> complains 
>
> ImportError: ld.so.1: python: fatal: /usr/sfw/lib/libgcc_s.so.1: wrong
> ELF class: ELFCLASS32
>
> This is due to the option -R/usr/sfw/lib, which should have been
> -R/usr/sfw/lib/sparcv9. Fixing the specs file to change the -R option
> actually fixes that problem.
>
> So please don't claim that I did something wrong when there is really a
> bug in sfw version of gcc.
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1628484>
> _______________________________________
>
>
>