Bob Atkins <[EMAIL PROTECTED]> added the comment: 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1628484> > _______________________________________ > > > Added file: http://bugs.python.org/file10526/unnamed Added file: http://bugs.python.org/file10527/DigiLink_esig_logo.jpg _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1628484> _______________________________________
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <br> I rest my case - you found <i><u><b>one</b></u></i> of the problems which you are blaming on gcc but in fact is not gcc's fault. You <i><u><b>must</b></u></i> 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.<br> <br> The bottom line is that I just don't know how to describe daylight to a blind man....<br> <br> 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<br> <br> ---<br> Bob<br> <br> Martin v. Löwis wrote: <blockquote cite="mid:[EMAIL PROTECTED]" type="cite"> <pre wrap="">Martin v. Löwis <a class="moz-txt-link-rfc2396E" href="mailto:[EMAIL PROTECTED]"><[EMAIL PROTECTED]></a> 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 <a class="moz-txt-link-rfc2396E" href="mailto:[EMAIL PROTECTED]"><[EMAIL PROTECTED]></a> <a class="moz-txt-link-rfc2396E" href="http://bugs.python.org/issue1628484";><http://bugs.python.org/issue1628484></a> _______________________________________ </pre> </blockquote> <br> <div class="moz-signature">-- <br> <title>Untitled Document</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <table border="0" cellpadding="2" cellspacing="0" width="569"> <tbody> <tr bgcolor="#000099" valign="middle"> <td colspan="2"><font color="#ffffff" face="Verdana, Arial, Helvetica, sans-serif" size="2"><strong>Bob Atkins </strong></font><font color="#ffffff"> </font></td> </tr> <tr valign="middle"> <td colspan="2"><font face="Verdana, Arial, Helvetica, sans-serif" size="1"><em>President/CEO</em></font></td> </tr> <tr valign="middle"> <td width="233"> <p align="center"><font face="Verdana, Arial, Helvetica, sans-serif" size="1"><b><font color="#000080"><span style="font-weight: bold; font-family: Trebuchet MS;"><a href="http://www.digilink.net";><img src="cid:part1.03020905.07070403@digilink.net" alt="DigiLink, Inc." style="border: 0px solid ; width: 216px; height: 48px;"></a></span></font></b><br> <font color="#006600">Business Inter-net-working</font><br> <font color="#000099"><strong><em>The Cure for the Common ISP!</em></strong></font></font></p> </td> <td width="328"> <p align="right"><font color="#666666" face="Verdana, Arial, Helvetica, sans-serif" size="1">Phone: </font><font face="Verdana, Arial, Helvetica, sans-serif" size="1">(310) 577-9450<br> </font><font color="#666666" face="Verdana, Arial, Helvetica, sans-serif" size="1">Fax: </font><font face="Verdana, Arial, Helvetica, sans-serif" size="1">(310) 577-3360</font><font face="Verdana, Arial, Helvetica, sans-serif" size="1"><br> <font color="#666666">eMail:</font> <a class="moz-txt-link-abbreviated" href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</a><br> </font></p> </td> </tr> </tbody> </table> <p> </p> </div> </body> </html>
<<attachment: DigiLink_esig_logo.jpg>>
_______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
