Bug 82625 - lt_dlopen fails to open shared libraries
Summary: lt_dlopen fails to open shared libraries
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: libtool
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Reed
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-01-24 03:38 UTC by Andrew Trick
Modified: 2007-04-18 16:50 UTC (History)
0 users

(edit)
Clone Of:
(edit)
Last Closed: 2004-08-19 05:30:07 UTC


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

Description Andrew Trick 2003-01-24 03:38:23 UTC
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:
Always

Comment 1 Andrew Trick 2003-01-24 03:40:57 UTC
Created attachment 89563 [details]
Attempt to open a shared library.

Comment 2 Andrew Trick 2003-01-24 03:41:47 UTC
Created attachment 89564 [details]
proposed patch

Comment 3 Jens Petersen 2003-07-08 12:43:26 UTC
Does this still happen with libtool-1.5, which is in rawhide?

Comment 4 Daniel Reed 2004-08-19 05:30:07 UTC
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.