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