Untitled Document

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>
_______________________________________

--
Untitled Document

Bob Atkins
President/CEO
Business Inter-net-working *The Cure for the Common ISP!*	Phone: (310) 577-9450 Fax: (310) 577-3360 eMail: bob@digilink.net