Bug 82625 - lt_dlopen fails to open shared libraries
lt_dlopen fails to open shared libraries
Product: Red Hat Linux
Classification: Retired
Component: libtool (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Reed
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2003-01-23 22:38 EST by Andrew Trick
Modified: 2007-04-18 12:50 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-19 01:30:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Attempt to open a shared library. (416 bytes, text/plain)
2003-01-23 22:40 EST, Andrew Trick
no flags Details
proposed patch (742 bytes, patch)
2003-01-23 22:41 EST, Andrew Trick
no flags Details | Diff

  None (edit)
Description Andrew Trick 2003-01-23 22:38:23 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830

Description of problem:
lt_dlopen/lt_dlopenext report that a shared library cannot be located when the
filename has no path component but search path is correctly set.

See the attached sample code.

lt_dlopen calls access(const char *pathname, int mode) inside
find_handle_callback() and reverses the sense of the error code.

See the attached patch file.

Version-Release number of selected component (if applicable):

How reproducible:
Comment 1 Andrew Trick 2003-01-23 22:40:57 EST
Created attachment 89563 [details]
Attempt to open a shared library.
Comment 2 Andrew Trick 2003-01-23 22:41:47 EST
Created attachment 89564 [details]
proposed patch
Comment 3 Jens Petersen 2003-07-08 08:43:26 EDT
Does this still happen with libtool-1.5, which is in rawhide?
Comment 4 Daniel Reed 2004-08-19 01:30:07 EDT
Please reopen if this is still an issue. Thanks.

Note You need to log in before you can comment on or make changes to this bug.