This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author bobatkins
Recipients bobatkins, loewis, sergiodj, spacey
Date 2008-06-05.20:25:35
SpamBayes Score 4.36501e-05
Marked as misclassified No
Message-id <48484BB3.2010303@digilink.net>
In-reply-to <1212695914.98.0.172437701188.issue1628484@psf.upfronthosting.co.za>
Content
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>
> _______________________________________
>
>
>
Files
File name Uploaded
DigiLink_esig_logo.jpg bobatkins, 2008-06-05.20:25:35
unnamed bobatkins, 2008-06-05.20:25:31
History
Date User Action Args
2008-06-05 20:25:37bobatkinssetspambayes_score: 4.36501e-05 -> 4.36501e-05
recipients: + bobatkins, loewis, sergiodj, spacey
2008-06-05 20:25:36bobatkinslinkissue1628484 messages
2008-06-05 20:25:36bobatkinscreate