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

Letting "build_ext --libraries" take more than one lib #42479

Closed
slanger mannequin opened this issue Oct 13, 2005 · 18 comments
Closed

Letting "build_ext --libraries" take more than one lib #42479

slanger mannequin opened this issue Oct 13, 2005 · 18 comments
Assignees
@merwok
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@slanger
Copy link
Mannequin

slanger mannequin commented Oct 13, 2005

BPO 1326113
Nosy @pitrou, @tiran, @tarekziade, @merwok, @ericsnowcurrently
Files
  • build_ext.diff: patch for build_ext.py
    		•

    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/merwok'
closed_at = <Date 2012-02-15.16:41:29.387>
created_at = <Date 2005-10-13.19:07:43.000>
labels = ['type-bug', 'library']
title = 'Letting "build_ext --libraries" take more than one lib'
updated_at = <Date 2012-04-22.05:58:51.552>
user = 'https://bugs.python.org/slanger'

    bugs.python.org fields:

    activity = <Date 2012-04-22.05:58:51.552>
actor = 'eric.araujo'
assignee = 'eric.araujo'
closed = True
closed_date = <Date 2012-02-15.16:41:29.387>
closer = 'eric.araujo'
components = ['Distutils', 'Distutils2']
creation = <Date 2005-10-13.19:07:43.000>
creator = 'slanger'
dependencies = []
files = ['6820']
hgrepos = []
issue_num = 1326113
keywords = ['patch']
message_count = 18.0
messages = ['48863', '59315', '121221', '121223', '121225', '121236', '121260', '121262', '153367', '153408', '153409', '153411', '153412', '153413', '153418', '153419', '153420', '158949']
nosy_count = 8.0
nosy_names = ['slanger', 'pitrou', 'christian.heimes', 'tarek', 'eric.araujo', 'palm.kevin', 'python-dev', 'eric.snow']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue1326113'
versions = ['3rd party', 'Python 2.7', 'Python 3.2', 'Python 3.3']
    @slanger
    Copy link
    Mannequin Author

    slanger mannequin commented Oct 13, 2005

    It's impossible to specify more than one external library to link using
    build_ext --libraries. Bug 716634 says that the problem is fixed, but it isn't.
    Assuming that the desired format is --libraries="lib1 lib2 etc", then there's a
    simple one line fix which I've attached.

    The problem exists in python 2.3.5, 2.4.1, 2.4.2 and in cvs HEAD.

    @slanger slanger mannequin added the stdlib Python modules in the Lib dir label Oct 13, 2005
    @tiran
    Copy link
    Member

    tiran commented Jan 5, 2008

    Another bug day task

    @akitada akitada mannequin added type-feature A feature request or enhancement labels Feb 8, 2009
    @tarekziade tarekziade mannequin assigned tarekziade Feb 8, 2009
    @palmkevin
    Copy link
    Mannequin

    palmkevin mannequin commented Nov 15, 2010

    This one is really annoying. Could you please consider fixing this one for the next release? (=lightweight change)

    @tarekziade
    Copy link
    Mannequin

    tarekziade mannequin commented Nov 15, 2010

    Distutils is frozen and we fix only bugs. This case is a little bit at the edge.

    Can you show us an example of a call you are trying to make, and the gcc command line output that fails ?

    I want to see if we can find a workaround. If so, this will be changed only in Distutils2. If not I'll change this to a bug and we'll fix it in distutils too.

    @palmkevin
    Copy link
    Mannequin

    palmkevin mannequin commented Nov 15, 2010

    I applied the patch proposed by slanger. This one is working.
    Now, I'm executing this instruction to build my extension:
    "%pythonRoot%\python.exe" setup.py build_ext --include-dirs "C:\MyApp\include" --library-dir "C:\MyApp\lib" --libraries "myLib1 myLib2"
    If I don't use the patch, then the error I get is 'unresolved external symbol _xxx referenced in function _abc'. Which is quite normal since I can only point to one library...

    @pitrou
    Copy link
    Member

    pitrou commented Nov 15, 2010

    Since "--libraries" is plural, and since the help text says:

    --libraries (-l) external C libraries to link with

    it should IMO be considered a bug.

    (Standard UNIX linkers have a different convention: you can specify -l several times in order to link against several libraries; however, distutils seems to ignore all but the last -l option)

    @merwok
    Copy link
    Member

    merwok commented Nov 16, 2010

    I agree this is a bug: it’s a broken feature, not a new one, even if it can be argued that fixing a long-standing behavior enables new usages, and is thus comparable to a new feature.

    I found no mention of --libraries in the docs, so I looked at the file history, and it’s clear that the intent of the code does not match its behavior. The fix is simple:

    •    if isinstance(self.libraries, str):

    •        self.libraries = [self.libraries]

    + self.ensure_string_list('libraries')

    I guess Greg forgot to change that line of code when he invented the ensure_* methods. No test is broken by this change. Do we need a regression test for this? It’s not strictly required IMO.

    FTR, in distutils2, I want to make the types and formats clear for everything. For example, build_ext.swig_opts is defined as “a list” in the current docs, this time with an example that shows it’s space-separated (“--swig-opts="-modern -I../include"”). The code does not use ensure_string_list, and hence does not support comma-separated. IMO, any value described as list should accept space-separated and comma-separated. This is probably out of scope for distutils, but something I definitely want to improve in distutils2. Supporting multiple options (-lm -lfoo) is IMO feasible too.

    @merwok merwok assigned merwok and unassigned tarekziade Nov 16, 2010
    @merwok merwok added type-bug An unexpected behavior, bug, or error and removed type-feature A feature request or enhancement labels Nov 16, 2010
    @merwok merwok assigned merwok and unassigned tarekziade Nov 16, 2010
    @merwok merwok added type-bug An unexpected behavior, bug, or error and removed type-feature A feature request or enhancement labels Nov 16, 2010
    @merwok
    Copy link
    Member

    merwok commented Nov 16, 2010

    I’ve reviewed other modules for the same error and found two candidates: config.libraries, the same thing as build_ext.libraries, and install.extra_path, for which I’m not sure.

    (More distutils2 thoughts: A number of options are split on os.pathsep, a new ensure_dirs_list method looks in order. Regarding the type system, an angry comment in build_py confirmed the need :)

    @ericsnowcurrently
    Copy link
    Member

    Ran into this bug today in 2.7 (building python-sybase with freetds). The fix in msg121260 took care of it (didn't try the patch). Thanks, Éric.

    Is this something that could get patched in the upcoming micro releases? It's not so important for me at this point, and I'm not sure how often it will come up, but it's also a very simple fix.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Feb 15, 2012

    New changeset 53df93a9c002 by Éric Araujo in branch '3.2':
    Fix parsing of build_ext --libraries option (bpo-1326113)
    http://hg.python.org/cpython/rev/53df93a9c002

    New changeset f7163afecb97 by Éric Araujo in branch 'default':
    Merge fixes for bpo-1326113 and bpo-12297 from 3.2
    http://hg.python.org/cpython/rev/f7163afecb97

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Feb 15, 2012

    New changeset 96f5718bf005 by Éric Araujo in branch '2.7':
    Fix parsing of build_ext --libraries option (bpo-1326113)
    http://hg.python.org/cpython/rev/96f5718bf005

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Feb 15, 2012

    New changeset 4ba43318e56b by Éric Araujo in branch 'default':
    Fix parsing of packaging’s build_ext --libraries option (bpo-1326113)
    http://hg.python.org/cpython/rev/4ba43318e56b

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Feb 15, 2012

    New changeset 60dd0041c9bc by Éric Araujo in branch 'default':
    Fix parsing of build_ext --libraries option (bpo-1326113)
    http://hg.python.org/distutils2/rev/60dd0041c9bc

    New changeset 158697fd8fa1 by Éric Araujo in branch 'python3':
    Merge bpo-1326113 fix from default
    http://hg.python.org/distutils2/rev/158697fd8fa1

    @merwok
    Copy link
    Member

    merwok commented Feb 15, 2012

    Here you are! Thanks for the testing.

    @merwok merwok closed this as completed Feb 15, 2012
    @merwok merwok closed this as completed Feb 15, 2012
    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Feb 15, 2012

    New changeset 77ac369fbbf1 by Éric Araujo in branch '3.2':
    Fix test failure for shared builds caused by bpo-1326113 fix
    http://hg.python.org/cpython/rev/77ac369fbbf1

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Feb 15, 2012

    New changeset 98fb1c0fc7a0 by Éric Araujo in branch 'default':
    Fix for packaging test failure on shared builds (bpo-1326113)
    http://hg.python.org/cpython/rev/98fb1c0fc7a0

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Feb 15, 2012

    New changeset db1c52aa4d2a by Éric Araujo in branch '2.7':
    Fix test failure for shared builds caused by bpo-1326113 fix
    http://hg.python.org/cpython/rev/db1c52aa4d2a

    @merwok
    Copy link
    Member

    merwok commented Apr 22, 2012

    Another instance of this is bpo-1703178.

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

    @merwok merwok

    Labels
    stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    4 participants
    @tiran @merwok @ericsnowcurrently @pitrou