[ python-Bugs-832799 ] Please link modules with shared lib
SourceForge.net
noreply at sourceforge.net
Sun Nov 23 15:44:06 EST 2003
Bugs item #832799, was opened at 2003-10-29 20:36
Message generated for change (Comment added) made by benson_basis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832799&group_id=5470
Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: benson margulies (benson_basis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Please link modules with shared lib
Initial Comment:
We've been working with libraries that are loaded with
dlopen (on Linux and Solaris, the land of ELF) and
which, in turn, use the embedded python interpreter.
Due to the behavior of the dynamic linker, this would
work much better if modules were, by default, linked
with -lpython2.3 instead of just left with hanging
undefined symbols. Here's why.
The main executable isn't linked with python, and none
of it's direct dependents are. So, the python symbols
aren't in the global namespace.
The dlopened library is linked with python. However,
when the dlopened library dlopens the modules, the
linux linker is not clever enough to allow the second-
order library to use symbols from its parent. (Solaris
has such a feature, but not linux). So, one has to
manually dlopen the python library with RTLD_GLOBAL
to make it work.
If each module had a NEED for the python lib (via -l at
linktime), all this would just work.
I've got some local patches to build_ext.py for this
purpose, but it would be nice to have official support.
----------------------------------------------------------------------
>Comment By: benson margulies (benson_basis)
Date: 2003-11-23 15:44
Message:
Logged In: YES
user_id=876734
I'm running into issues trying to come up with a clean version
of this. I'd like to know what you think of some of these
before I try to port what I've got into 2.4 and come up with
patches.
1) setup.py seems to have no way to be selective about
which modules to build. What if I don't want to try (and then
fail make install) to build, for example, ssl?
2) setup.py makes assumptions about pathnames. It always
puts /usr/local/lib into the build path. On a 64-bit solaris or HP
system, this can lead to a mess, if the 64 bit libraries are
somewhere else.
3) There is an existing provision to add additional libs to the
build in setup.py, but it's disabled if the prefix is /usr. Why?
I have this feeling that someone had a plan here that I'm too
obtuse to make out which would offer a shorter path to a
solution then I'm getting tangled up in, for managing the build
of these modules.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2003-10-31 08:42
Message:
Logged In: YES
user_id=21627
You can probably rely on libpythonxy.so ending up in
$(DESTDIR)$(LIBDIR)/$(INSTSONAME), whose values you can
retrieve from the installed Makefile (i.e. through
distutils.config).
----------------------------------------------------------------------
Comment By: benson margulies (benson_basis)
Date: 2003-10-31 07:22
Message:
Logged In: YES
user_id=876734
To turn my patches into things that anyone else would want,
I need to know what to put in the -L that will be required. At
the time we're building the main python distro, that's
straightforward. When a user builds an individual module, is
there a sensible path relative to PYTHONHOME I can use?
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2003-10-31 05:05
Message:
Logged In: YES
user_id=21627
Please do provide patches. Take into account that modules
may be built either with distutils, or through Modules/Setup.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832799&group_id=5470
More information about the Python-bugs-list
mailing list