Bug 17606 - -l:/absolute/path/to/lib.so broken
Summary: -l:/absolute/path/to/lib.so broken
Status: RESOLVED INVALID
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 17800 18172 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-11-16 21:49 UTC by mallet
Modified: 2015-03-28 05:51 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mallet 2014-11-16 21:49:25 UTC
It appears that commit d4ae5fb0b5d1ae4270b3343509e8bd2d529aa291
(here: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=d4ae5fb0b5d1ae4270b3343509e8bd2d529aa291 ) breaks the '-l:' command line option of ld when given an absolute file name.

Since -l:/absolute/path/to/lib.so is not a documented feature (ony -l:lib.so is documented), I was wondering if this issue could be considered as a bug, or was done on purpose?
Comment 1 Alan Modra 2014-11-20 03:08:54 UTC
It was a deliberate bug fix.

*** This bug has been marked as a duplicate of bug 17532 ***
Comment 2 mallet 2014-11-20 09:38:15 UTC
I understand bug 17532 is a deliberate fix. However, I was talking more precisely about using an absolute path name. Traditionaly, absolute paths are considered as such and do not require any "search path".

I noticed that using an explicit -L/ in front of a -l:/absolute/path.so make it work, which I find a bit weird. For instance, if there happen to be a /foo/absolute/path.so, using -L/foo -l:/absolute/path.so would not give the expected results.

I think that either -l:/absolute/path.so should raise an error, or be treated as such. What do you think?
Comment 3 Alan Modra 2014-11-28 00:07:30 UTC
I don't see -l:/... being much different to -l/...  For example, -L. -l/c will load ./lib/c.so or ./lib/c.a if such files exist.  I don't think ld should warn in either case.
Comment 4 Andreas Schwab 2015-01-05 22:05:23 UTC
*** Bug 17800 has been marked as a duplicate of this bug. ***
Comment 5 Andreas Schwab 2015-03-28 05:51:10 UTC
*** Bug 18172 has been marked as a duplicate of this bug. ***