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

fix problems with ctypes.util.find_library #49111

Closed
doko42 opened this issue Jan 6, 2009 · 6 comments
Closed

fix problems with ctypes.util.find_library #49111

doko42 opened this issue Jan 6, 2009 · 6 comments
Assignees
@doko42
Labels
topic-ctypes

Comments

@doko42
Copy link
Member

doko42 commented Jan 6, 2009

BPO 4861
Nosy @theller, @doko42, @vadmium
Files
  • ctypes-findlib.diff: proposed patch
  • ctypes-findlib.diff: updated patch
    		•

    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/doko42'
closed_at = <Date 2009-01-10.17:20:40.082>
created_at = <Date 2009-01-06.22:02:51.718>
labels = ['ctypes']
title = 'fix problems with ctypes.util.find_library'
updated_at = <Date 2016-05-10.08:38:42.242>
user = 'https://github.com/doko42'

    bugs.python.org fields:

    activity = <Date 2016-05-10.08:38:42.242>
actor = 'martin.panter'
assignee = 'doko'
closed = True
closed_date = <Date 2009-01-10.17:20:40.082>
closer = 'doko'
components = ['ctypes']
creation = <Date 2009-01-06.22:02:51.718>
creator = 'doko'
dependencies = []
files = ['12626', '12651']
hgrepos = []
issue_num = 4861
keywords = ['patch']
message_count = 6.0
messages = ['79294', '79317', '79412', '79414', '79556', '265230']
nosy_count = 4.0
nosy_names = ['theller', 'doko', 'exarkun', 'martin.panter']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue4861'
versions = ['Python 2.6', 'Python 2.5', 'Python 3.0', 'Python 3.1', 'Python 2.7']
    @doko42
    Copy link
    Member Author

    doko42 commented Jan 6, 2009

    there are some problems with ctypes.util.find_library(), which I would
    like to see fixed on active branches.

    • find_library is not robust, if either objdump or gcc are not
      installed. fixed by raising an exception if the tools are not
      found. Is OSError the correct type for this exception?

    • ldconfig -p already prints the shared object name. afaics there
      is no need to call objdump again.

    • the regexp to scan the ldconfig -p output is wrong for
      architectures where libraries of more than one abi type are
      installed, e.g. having ix86 libs on a x86_64 system. Having
      only the library installed which doesn't match the python
      executable lets find_library find the wrong library. Note that
      the patch is only correct under the assumption that the python
      executable is unstalled for the "main" abi.

    patch attached, ok to check in?

    @theller
    Copy link

    theller commented Jan 7, 2009

    Matthias Klose schrieb:

    there are some problems with ctypes.util.find_library(), which I would
    like to see fixed on active branches.

    • find_library is not robust, if either objdump or gcc are not
      installed. fixed by raising an exception if the tools are not
      found. Is OSError the correct type for this exception?

    Sure.

    • ldconfig -p already prints the shared object name. afaics there
      is no need to call objdump again.
    • the regexp to scan the ldconfig -p output is wrong for
      architectures where libraries of more than one abi type are
      installed, e.g. having ix86 libs on a x86_64 system. Having
      only the library installed which doesn't match the python
      executable lets find_library find the wrong library. Note that
      the patch is only correct under the assumption that the python
      executable is unstalled for the "main" abi.

    I have to trust you that this is the right approach since I don't have
    much experience on linux. Also I have not tested the patch.

    What I do not like too much in your patch is 'import platform'
    since that pulls in a lot of stuff. Would it be possible to
    replace 'platform.machine()' with 'os.uname()[4]' ?

    @doko42
    Copy link
    Member Author

    doko42 commented Jan 8, 2009

    new version of the patch using os instead of platform, and selecting the
    correct library for biarch platforms, tested on ia64, sparc, s390,
    amd64, ppc64. unsure if there's a better way to find out if the
    executable is 32 or 64bit.

    @exarkun
    Copy link
    Mannequin

    exarkun mannequin commented Jan 8, 2009

    This seems to be a partial duplicate of 3383. A suggestion on that
    ticket was to look for objdump in PATH and then try /usr/sbin.

    @doko42
    Copy link
    Member Author

    doko42 commented Jan 10, 2009

    now fixed in 2.6, 2.7, 3.0 and 3.1.

    objdump is never installed in /sbin. I don't think we should assume a
    specific path for objdump. we don't do this for gcc either.

    @doko42 doko42 closed this as completed Jan 10, 2009
    @doko42 doko42 assigned doko42 and unassigned theller Jan 10, 2009
    @vadmium
    Copy link
    Member

    vadmium commented May 10, 2016

    FYI the OSError exceptions added here were never triggered as intended, and they are proposed to be removed as part of bpo-25751.

    @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

    @doko42 doko42

    Labels
    topic-ctypes
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    3 participants
    @vadmium @theller @doko42