Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Please link modules with shared lib #39475

Closed
bensonbasis mannequin opened this issue Oct 30, 2003 · 10 comments
Closed

Please link modules with shared lib #39475

bensonbasis mannequin opened this issue Oct 30, 2003 · 10 comments
Assignees
@loewis
Labels
build The build process and cross-build

Comments

@bensonbasis
Copy link
Mannequin

bensonbasis mannequin commented Oct 30, 2003

BPO 832799
Nosy @loewis, @birkenfeld

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = 'https://github.com/loewis'
closed_at = <Date 2006-04-10.12:40:39.000>
created_at = <Date 2003-10-30.01:36:23.000>
labels = ['build']
title = 'Please link modules with shared lib'
updated_at = <Date 2006-04-10.12:40:39.000>
user = 'https://bugs.python.org/bensonbasis'

bugs.python.org fields:

activity = <Date 2006-04-10.12:40:39.000>
actor = 'loewis'
assignee = 'loewis'
closed = True
closed_date = None
closer = None
components = ['Build']
creation = <Date 2003-10-30.01:36:23.000>
creator = 'benson_basis'
dependencies = []
files = []
hgrepos = []
issue_num = 832799
keywords = []
message_count = 10.0
messages = ['18810', '18811', '18812', '18813', '18814', '18815', '18816', '18817', '18818', '18819']
nosy_count = 3.0
nosy_names = ['loewis', 'georg.brandl', 'benson_basis']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue832799'
versions = ['Python 2.3']
@bensonbasis
Copy link
Mannequin Author

bensonbasis mannequin commented Oct 30, 2003

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.

@bensonbasis bensonbasis mannequin closed this as completed Oct 30, 2003
@bensonbasis bensonbasis mannequin assigned loewis Oct 30, 2003
@bensonbasis bensonbasis mannequin added the build The build process and cross-build label Oct 30, 2003
@bensonbasis bensonbasis mannequin closed this as completed Oct 30, 2003
@bensonbasis bensonbasis mannequin assigned loewis Oct 30, 2003
@bensonbasis bensonbasis mannequin added the build The build process and cross-build label Oct 30, 2003
@loewis
Copy link
Mannequin

loewis mannequin commented Oct 31, 2003

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.

@bensonbasis
Copy link
Mannequin Author

bensonbasis mannequin commented Oct 31, 2003

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?

@loewis
Copy link
Mannequin

loewis mannequin commented Oct 31, 2003

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).

@bensonbasis
Copy link
Mannequin Author

bensonbasis mannequin commented Nov 23, 2003

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.

@loewis
Copy link
Mannequin

loewis mannequin commented Nov 24, 2003

Logged In: YES
user_id=21627

  1. Basically, you lose. If you don't want to build a module
    as a shared library, you can build it statically, through
    Modules/Setup. If you absolutely don't want to build a
    module at all, you edit setup.py, and modify
    disabled_module_list. If you don't want to edit
    disabled_module_list, you build the module, and delete it
    when done.

  2. Using /usr/local/lib could be replaced, but I would
    consider this out of scope of this change. Feel free to
    submit a separate patch. Make sure that the alternative
    patch manages to pick up shared libraries in all cases where
    it finds them today.

  3. 'cvs annotate' reveals that this was added in setup.py
    1.100. 'cvs log' reveals that this was added in response to
    python.org/sf/589427, where the Debian maintainer complains
    that /usr/include is added to the list of -I options, even
    though the compiler already has /usr/include in its search list.

@bensonbasis
Copy link
Mannequin Author

bensonbasis mannequin commented Nov 25, 2003

Logged In: YES
user_id=876734

I submitted a set of patches that work for the initial build. I
think I'll need more for the tools that are used later, I'm
moving on to that next.

@bensonbasis
Copy link
Mannequin Author

bensonbasis mannequin commented Nov 25, 2003

Logged In: YES
user_id=876734

I only see one possible issue with the patch.

I exploited the existing BLDLIBRARY macro. It says '-L.' on
linux. Which is fine for the initial 'make', but not too great
when the Makefile gets copied to the install dir.

The comments in the config dir leave me thinking that there
would be a Makefile.pre in there, but there isn't. Just a
Makefile.

The RUNSHARED macro ends up set back to where I built it,
not to where I installed it. If some process would fix
RUNSHARED, it could also fix BLDSHARED.

@birkenfeld
Copy link
Member

Logged In: YES
user_id=1188172

See patch bpo-1429775.

@loewis
Copy link
Mannequin

loewis mannequin commented Apr 10, 2006

Logged In: YES
user_id=21627

This was fixed with said patch in r45232.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@loewis loewis

Labels
build The build process and cross-build
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@birkenfeld