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.

classification
Title: 2.2.2 build on Solaris
Type: Stage:
Components: Build Versions:
process
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: Nosy List: gvanrossum, h1ghlander, loewis
Priority: normal Keywords:

Created on 2002-11-09 14:40 by gvanrossum, last changed 2022-04-10 16:05 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
msg.txt gvanrossum, 2002-11-09 14:40 Message from David LeVine
Messages (5)
msg13158 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-11-09 14:40
Attached is a message that concludes an exchange
between David LeVine and me. He built Python using the
gcc 3.2 from sunfreeware.com.

Running ./python, he got this error:

ld.so.1: ./python: fatal: libstdc++.so.5: open failed:
No such file or directory

I suggested adding a -R somewhere and he got it to work
by patching configure. Perhaps a real fix can be made
out of this?
msg13159 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-11-09 18:02
Logged In: YES 
user_id=21627

I'm not sure that this should be fixed in Python, there are
several complications:

1. It is not certain that python is linked with libstdc++.
If not, you 
    only need to worry about libgcc_s.so, if gcc is gcc 3.2.

2. It is not certain whether /usr/local is the right prefix; 
    gcc might be installed with a different prefix.

3. It is not certain whether libstdc++ is installed in
<gccprefix>/lib, gcc also supports installing it into
<gccprefix>/lib/gcc-lib/<arch>/<version>

4. Randomly adding -R options might shoot back, since python
may now pick up the wrong libraries, for libraries used in
extension modules.

We usually fix this in the gcc installation, not in all
affected applications, by adding proper -R options into the
installed specs file.

I would rather "fix" this by pointing out that gcc 3 users
will have to set LD_RUN_PATH on Solaris, to include the
directories containing libgcc_s.so.1, and possibly
libstdc++.so.xy
msg13160 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-11-14 23:23
Logged In: YES 
user_id=6380

Feel free to close it then. It seemed obscure to me at best.
Maybe a note can be added to README with the solution?
msg13161 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-11-15 07:28
Logged In: YES 
user_id=21627

Ok, added a note to README 1.136.4.13 and 1.158.
msg13162 - (view) Author: Ben Taylor (h1ghlander) Date: 2003-02-11 06:25
Logged In: YES 
user_id=709528

Since you can determine the location of libstdc++.so by invoking
g++ --print-file-name libstdc++.so, you can calculate what
the linker directory is, and therefore what the library path
flags.

Here's my patch:

--- tmp/Python-2.2.2/configure	2002-10-10 11:26:41.000000000
-0400
+++ work/Python-2.2.2/configure	2003-02-11
00:10:36.084484000 -0500
@@ -3310,6 +3310,14 @@
 		    if $CC -Xlinker --help 2>&1 | grep export-dynamic
>/dev/null 		    then
 			LINKFORSHARED="-Xlinker --export-dynamic"
+			LIBSTDCPLUSPLUSPATH=`c++ --print-file-name
libstdc++.so`			LIBSTDCPLUSPLUSDIR="`/usr/bin/dirname
$LIBSTDCPLUSPLUSPATH`"
+			STDCPLUSLIBPATH="`cd $LIBSTDPLUSPLUSDIR;pwd`"
+			LINKFORSHARED="$LINKFORSHARED -R$STDCPLUSLIBPATH
-L$STDCPLUSLIBPATH"
+		    else
+			LIBSTDCPLUSPLUSPATH=`c++ --print-file-name
libstdc++.so`			LIBSTDCPLUSPLUSDIR="`/usr/bin/dirname
$LIBSTDCPLUSPLUSPATH`"
+			STDCPLUSLIBPATH="`cd $LIBSTDCPLUSPLUSDIR;pwd`"
+			LINKFORSHARED="-R$STDCPLUSLIBPATH -L$STDCPLUSLIBPATH"
+
 		    fi;;
 		  esac;;
 	esac
History
Date User Action Args
2022-04-10 16:05:52adminsetgithub: 37445
2002-11-09 14:40:43gvanrossumcreate