Python-2.2.1, Solaris7, make test fails...

Martin v. Löwis loewis at informatik.hu-berlin.de
Fri Apr 19 11:13:22 EDT 2002


Hugh Sasse Staff Elec Eng <hgs at dmu.ac.uk> writes:

> I remembered: I forgot to uncomment all the places where the Tk stuff
> lives.
[...]
> # *** Uncomment and edit to reflect where your Tcl/Tk libraries are:
> 	-L/usr/local/lib \
[...]
> ld.so.1: ./python: fatal: libtk8.3.so: open failed: No such file or directory

That is an old Solaris problem: the dynamic loader searches on /lib
and /usr/lib for shared libraries, no matter what directories where
given with -L to the compiler. You have the following options (again
all alternative):

1. Set LD_LIBRARY_PATH when running Python. This is most common, but
   also ugliest, since it requires every Python user to set
   LD_LIBRARY_PATH.
2. Pass -R/usr/local/lib when linking python; you can do that by adding
   this into Modules/Setup. Alternative spellings of this option are
   -Wl,-R/usr/local/lib, 
   -Xlinker -R/usr/local/lib
   -Wl,--rpath /usr/local/lib
   -Xlinker --rpath /usr/local/lib
3. Set LD_RUN_PATH when linking python; ld(1) will treat LD_RUN_PATH
   as implicitly specifying -R options.
4. Use crle(1) to extend the system-wide list of directories searched
   for shared libraries; you will need to do that on all systems where
   you run the python executable.
5. Recompile Tcl and Tk as static libraries (or explicitly request
   that the static versions - which you already have - are used in
   linking; you do that by giving the full .a file path, instead of
   using -l options)

Contrary to my earlier claims: dependence on a shared library *is* a
good reason to build an extension as a shared library also. Currently,
each start of python needs to locate libtk8.3.so. If _tkinter.so was a
shared module, then libtk8.3.so would be located only if _tkinter is
imported.

I'd personally go with option 2, and build _tkinter.so, or go with
option 5.

HTH,
Martin



More information about the Python-list mailing list