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]">&lt;[EMAIL PROTECTED]&gt;</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]">&lt;[EMAIL PROTECTED]&gt;</a>
<a class="moz-txt-link-rfc2396E" 
href="http://bugs.python.org/issue1628484";>&lt;http://bugs.python.org/issue1628484&gt;</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

Reply via email to