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.

Sign up for GitHub

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

building a shared python library #35835

Closed
doko42 opened this issue Dec 27, 2001 · 5 comments
Closed

building a shared python library #35835

doko42 opened this issue Dec 27, 2001 · 5 comments
Labels
build The build process and cross-build

Comments

@doko42
Copy link
Member

doko42 commented Dec 27, 2001

BPO 497102
Nosy @loewis, @doko42
Files
  • deb-build.dpatch: patch for building shared library
    		•

    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 = None
closed_at = <Date 2002-06-04.17:21:21.000>
created_at = <Date 2001-12-27.18:51:39.000>
labels = ['build']
title = 'building a shared python library'
updated_at = <Date 2002-06-04.17:21:21.000>
user = 'https://github.com/doko42'

    bugs.python.org fields:

    activity = <Date 2002-06-04.17:21:21.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Build']
creation = <Date 2001-12-27.18:51:39.000>
creator = 'doko'
dependencies = []
files = ['3879']
hgrepos = []
issue_num = 497102
keywords = ['patch']
message_count = 5.0
messages = ['38588', '38589', '38590', '38591', '38592']
nosy_count = 3.0
nosy_names = ['nobody', 'loewis', 'doko']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue497102'
versions = []
    @doko42
    Copy link
    Member Author

    doko42 commented Dec 27, 2001

    This patch allows builing of libpython.so in addition
    to build libpython.a. The patch currently is used for
    building the python package on Debian GNU/Linux, so it
    needs to be cleaned up for other architectures.
    However python already has support for building shared
    libs, so this should not be a major problem. Feedback
    for a cleanup of the patch is appreciated.

    @doko42 doko42 closed this as completed Dec 27, 2001
    @doko42 doko42 added the build The build process and cross-build label Dec 27, 2001
    @doko42 doko42 closed this as completed Dec 27, 2001
    @doko42 doko42 added the build The build process and cross-build label Dec 27, 2001
    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Dec 28, 2001

    Logged In: YES
    user_id=21627

    The patch looks good (it is the third or so of its kind, but
    I'm optimistic that it can be integrated this time).

    Would you like to take another round of cleanup? Specifically:

    • Building libpython as a shared library MUST be a
      configuration-time option, this is not negotiable. On many
      systems, building libpython as a shared library will cause
      problems, since the directory containing libpython won't be
      in the standard search path of the dynamic linker (e.g. in
      /usr/local/lib on Solaris). Adding -R options helps, but not
      much, since the binaries won't be relocatable with such
      options. The options should default to "off" (static
      linking); this is negotiable.

    • It seems that the patch has a few unrelated changes. What
      system is GNU* (I assume the Hurd?) Those should come in a
      separate patch.

    • Library versioning needs discussion. It seems that this
      patch will give the library a name of libpython2.2.so.0.0.
      Under which conditions should the SONAME be changed? If
      2.2.1 comes along, how should the SOVERSION change? To 0.1?
      Or to 1.0? I'd prefer to start with 1.0, anyway - procedures
      to bump the SOVERSION still need to be discussed (I assume
      bumping the minor version for Python micro releases should
      be ok).

    • If the option for building as a shared library is
      activated, assume, by default, that the procedure on all
      systems is identical, i.e. don't try to write Linux-specific
      code. We can test it on many systems, and on others, users
      simply can't activate the option. Please put assignments to
      LDLIBRARY all in one place (there is already a section that
      does so for dgux/beos/cygwin).

    • What is the value of building both PIC and non-PIC
      objects? If libpython is a shared library, I'd suggest to
      put PIC objects into libpython.a, anyway. That would allow
      to get rid of the pic_o objects. If some Debian policy says
      a .a library must not contain PIC objects, I could live with
      two compilations per source file.

    • Put the computation of system-dependent options all in
      configure.in. In particular, passing -soname should be done
      in configure.in; that should probably be the same on all
      systems building a shared libpython using GCC.

    • Please don't use LD_PRELOAD. Using LD_LIBRARY_PATH seems
      more sensible, IMO.

    @nobody
    Copy link
    Mannequin

    nobody mannequin commented Jan 19, 2002

    Logged In: NO

    It would be really helpful to have this patch applied.
    Certain uses of python are impossible without a python
    shared library (usually involving a combination of extension
    modules and embedding python).

    The PyXPCOM bindings are one such example. It looks like we
    might run into a similar problem when writing bindings for
    gnome-vfs.

    In the gnome-vfs case, it allows loadable modules that
    implement file systems. One such module might be a wrapper
    that passes on all gnome-vfs requests to python code. It
    would be a shared library, embedding a python interpreter,
    and running python code. This module would then be loaded
    by any gnome-vfs using application when certain paths are
    requested. As there is no libpython.so, this vfs module
    would be staticly linked to libpython, so it contains a copy
    of the interpreter.

    Now the gnome-vfs library would also be useful in python
    applications (especially gnome ones, so that it uses the
    same filesystem space as other apps). This support would be
    implemented as an extension for python.

    Things get interesting when a python application uses
    gnome-vfs to access a file handled by the python vfs module.
    There is one copy of the interpreter in the the main python
    executable, and another in the vfs module. This means
    different bits of code may end up using different copies of
    the interpreter (and we get two global interpreter locks,
    etc, etc). This leads to all kinds of problems.

    With a shared libpython, both the vfs module and python
    executable will be using the same interpreter, and all these
    problems disapear.

    Getting this patch into python distribution would be _very_
    useful.

    James Henstridge <james at daa dot com dot au>

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jan 19, 2002

    Logged In: YES
    user_id=21627

    In the current form, the patch is simply unacceptable. There
    is no doubt that this feature has its applications; and
    there is no need to lobby for it. Instead, fixing the
    problems in the implementation of the feature would make a
    difference.

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jun 4, 2002

    Logged In: YES
    user_id=21627

    This has been fixed with a similar patch in CVS.

    @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
    No one assigned
    Labels
    build The build process and cross-build
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    1 participant
    @doko42