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

ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH #47185

Closed
janssen mannequin opened this issue May 21, 2008 · 10 comments
Closed

ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH #47185

janssen mannequin opened this issue May 21, 2008 · 10 comments
Assignees
@theller
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@janssen
Copy link
Mannequin

janssen mannequin commented May 21, 2008

BPO 2936
Nosy @theller, @jcea, @nh2
Files
  • unnamed
  • unnamed
  • unnamed
    		•

    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/theller'
closed_at = <Date 2008-06-02.18:43:35.143>
created_at = <Date 2008-05-21.19:35:19.492>
labels = ['invalid', 'type-bug', 'library']
title = "ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH"
updated_at = <Date 2017-05-13.14:58:04.078>
user = 'https://bugs.python.org/janssen'

    bugs.python.org fields:

    activity = <Date 2017-05-13.14:58:04.078>
actor = 'nh2'
assignee = 'theller'
closed = True
closed_date = <Date 2008-06-02.18:43:35.143>
closer = 'theller'
components = ['Library (Lib)']
creation = <Date 2008-05-21.19:35:19.492>
creator = 'janssen'
dependencies = []
files = ['10476', '10487', '10489']
hgrepos = []
issue_num = 2936
keywords = []
message_count = 10.0
messages = ['67170', '67492', '67500', '67501', '67505', '67516', '67555', '67584', '67586', '293614']
nosy_count = 5.0
nosy_names = ['theller', 'jcea', 'janssen', 'schmir', 'nh2']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue2936'
versions = ['Python 2.6', 'Python 2.5', 'Python 3.0']
    @janssen
    Copy link
    Mannequin Author

    janssen mannequin commented May 21, 2008

    The "find_library()" function in ctypes.util doesn't look in
    LD_LIBRARY_PATH on Solaris or Linux or most other UNIX variants that use
    that convention. This means that find_library() doesn't find libraries
    that dlopen() would, and makes development with ctypes much harder than
    it should be.

    @janssen janssen mannequin added stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels May 21, 2008
    @jcea
    Copy link
    Member

    jcea commented May 29, 2008

    Would be useful, too, to add an optional parameter to the call with a
    list of directories where to search?.

    @janssen
    Copy link
    Mannequin Author

    janssen mannequin commented May 29, 2008

    You could do that, I can see how that would be useful, but I think it
    might be less confusing to just use the platform's way of doing that.
    For instance, on OS X, you can set DYLD_LIBRARY_PATH environment
    variable to put directories in front of the normal search path, and
    DYLD_FALLBACK_LIBRARY_PATH to put directories in back of the normal
    search path.

    @jcea
    Copy link
    Member

    jcea commented May 29, 2008

    Sometimes the program knows better :). Supporting LD_LIBRARY_PATH and
    friends, the incremental cost of supporting an additional parameter
    seems trivial.

    @theller
    Copy link

    theller commented May 29, 2008

    To be honest, I do not understand this request and the discussion.
    ctypes.util.find_library(), as dcumented, is supposed to simulate what
    the linker does: find the name of a shared library. For example,
    it returns 'libc.so.6' when called as ctypes.util.find_library('c').
    AFAIK (and I don't know very much about posix shared libs or linkers)
    the linker does not pay attention to (DY)LD_LIBRARY_PATH env var.

    dlopen(shared-lib-name) does use this env vars, but this behaviour is
    already built into dlopen.

    @theller theller self-assigned this May 29, 2008
    @janssen
    Copy link
    Mannequin Author

    janssen mannequin commented May 30, 2008

    The question is, which linker? I think it should be ld.so, which links "on
    demand", and does pay attention to LD_LIBRARY_PATH. I'm not sure what the
    point of find_library() is, otherwise.

    Bill

    On Thu, May 29, 2008 at 11:24 AM, Thomas Heller <report@bugs.python.org>
    wrote:

    Thomas Heller <theller@ctypes.org> added the comment:

    To be honest, I do not understand this request and the discussion.
    ctypes.util.find_library(), as dcumented, is supposed to simulate what
    the linker does: find the name of a shared library. For example,
    it returns 'libc.so.6' when called as ctypes.util.find_library('c').
    AFAIK (and I don't know very much about posix shared libs or linkers)
    the linker does not pay attention to (DY)LD_LIBRARY_PATH env var.

    dlopen(shared-lib-name) does use this env vars, but this behaviour is
    already built into dlopen.

    ----------
    assignee: -> theller
    nosy: +theller

    Python tracker <report@bugs.python.org>
    <http://bugs.python.org/issue2936\>

    @theller
    Copy link

    theller commented May 30, 2008

    The question is, which linker? I think it should be ld.so, which links "on
    demand", and does pay attention to LD_LIBRARY_PATH. I'm not sure what the
    point of find_library() is, otherwise.

    The best explanation is in the python docs:
    http://docs.python.org/lib/ctypes-finding-shared-libraries.html

    @janssen
    Copy link
    Mannequin Author

    janssen mannequin commented May 31, 2008

    Yes, I've read that explanation, but I still don't see what the point of
    find_library() is. Are you trying to resolve a possibly ambiguous reference
    to a shared library to the one which is used by the Python interpreter? If
    that's the case (and that's what the code seems to do), how about calling it
    "find_library_used_by_python", and have another function, perhaps called
    "find_library", which, given a partial name like "foo", searches the
    LD_LIBRARY_PATH (or, on Darwin, the DYLD_LIBRARY_PATH), if set, then the
    standard system locations, the, on Darwin, the DYLD_FALLBACK_LIBRARY_PATH,
    to find a library called "libfoo.so.N" (or, on Darwin, "libfoo.N.dylib")?
    That would be very useful. Right now, I don't see the use case for
    find_library().

    Bill

    On Fri, May 30, 2008 at 1:58 PM, Thomas Heller <report@bugs.python.org>
    wrote:

    Thomas Heller <theller@ctypes.org> added the comment:

    > The question is, which linker? I think it should be ld.so, which links
    "on
    > demand", and does pay attention to LD_LIBRARY_PATH. I'm not sure what
    the
    > point of find_library() is, otherwise.

    The best explanation is in the python docs:
    http://docs.python.org/lib/ctypes-finding-shared-libraries.html

    Python tracker <report@bugs.python.org>
    <http://bugs.python.org/issue2936\>

    @janssen
    Copy link
    Mannequin Author

    janssen mannequin commented May 31, 2008

    OK, I went back and read the code. What I should be using is
    "ctypes.cdll.LoadLibrary("libgoodstuff.1.dylib")". Thanks -- I think you
    can close this issue.

    Bill

    On Fri, May 30, 2008 at 1:58 PM, Thomas Heller <report@bugs.python.org>
    wrote:

    Thomas Heller <theller@ctypes.org> added the comment:

    > The question is, which linker? I think it should be ld.so, which links
    "on
    > demand", and does pay attention to LD_LIBRARY_PATH. I'm not sure what
    the
    > point of find_library() is, otherwise.

    The best explanation is in the python docs:
    http://docs.python.org/lib/ctypes-finding-shared-libraries.html

    Python tracker <report@bugs.python.org>
    <http://bugs.python.org/issue2936\>

    @theller theller closed this as completed Jun 2, 2008
    @theller theller added the invalid label Jun 2, 2008
    @nh2
    Copy link
    Mannequin

    nh2 mannequin commented May 13, 2017

    For people who pass by, this issue has been taken on again in:

    https://bugs.python.org/issue9998

    @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

    @theller theller

    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
    2 participants
    @jcea @theller