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