https://sourceware.org/bugzilla/show_bug.cgi?id=17532
maillist-gdb at barfooze dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--- Comment #2 from maillist-gdb at barfooze dot de ---
(In reply to Alan Modra from comment #1)
> Not a bug. -l searches in the library path, ie. directories given by -L and
> some default directories, typically /lib and /usr/lib. None of these
> directories contain a file ./lib/readline/libreadline.a
-l != -l: (note the colon)
the "l:" mechanism exists specifically to supply a full path that's detached
from the usual -L directory mechanisms (or at least it could be used in the
past that way, which was a very handy feature).
in my case its needed to inject the path to the "in-tree" version of
libreadline.a because of priority issues in -L paths passed to the build.
(a crosscompiler is used, but the libdir is outside the crosscompiler prefix,
so we pass "foo-gcc -L/rootfs/lib" as CC, and as there's no -isystem equivalent
for libraries, our -L path always takes precedence over the ones added by
bash's buildsystem as ours comes first on the command line, which in this
specific case ends up linking an incompatible version of libreadline.a from
/rootfs/lib)
it also does not work anymore when using an absolute path, but it worked in all
combinations with 2.24.
note that ld complains about -l:./lib/readline/libreadline.a rather than
./lib/readline/libreadline.a
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
