This is a feature request.
commit 51dee2fec3afad5e6fc9f78b8c1d8486ebf3a334 added the feature for gold.
gold a.o p/libm.a
gold can find p/libm.a.1 even if -L p is not specified. gold names the directory `extra_search_path` and prefers it over -L:
// If the filename is not absolute, we assume it is in the current
// directory *except* when:
// A) input_argument_->is_lib() is true; or
// B) input_argument_->extra_search_path() is not empty.
// In both cases, we look in extra_search_path + library_path to find
// the file location, rather than the current directory.
In theory, if we had this feature many years ago. For glibc libm.a
% cat /usr/lib/x86_64-linux-gnu/libm.a
/* GNU ld script
GROUP ( /usr/lib/x86_64-linux-gnu/libm-2.29.a /usr/lib/x86_64-linux-gnu/libmvec.a )
We can simplify the script to:
I made some investigations.
Notation: CWD => current working directory
For a relative pathname (not absolute path or -l) in INPUT() or GROUP():
* GNU ld searches in CWD then in -L
* gold searches in the parent directory of the current linker script then in -L.
It does not fall back to CWD.
I am going to change the search order of lld
* the parent directory of the current linker script
* next in CWD
* then in -L.
libstdc++.a currently includes object files from libsupc++. It could use a linker script as an alternative if GNU ld had this feature... Though there is probably no point to do this
For libc++.a, it probably makes more sense because several C++ ABI libraries can be plugged in.
> gold a.o p/libm.a
> gold can find p/libm.a.1 even if -L p is not specified.
A couple of questions:
1. Does the extra search path persist beyond the end of the linker
script ? For example, using your sample script:
% ld p/libm.a foo.o
Should the linker load p/foo.o ? (If it exists, of course).
2. Is this feature restricted to libraries, or should it also affect
object files ? For example:
% cat p/libm.a
% ld p/libm.a
Is this expected to load p/foo.o ?
(In reply to Nick Clifton from comment #2)
> Hi Fangrui,
> > gold a.o p/libm.a
> > gold can find p/libm.a.1 even if -L p is not specified.
> A couple of questions:
> 1. Does the extra search path persist beyond the end of the linker
> script ? For example, using your sample script:
> % ld p/libm.a foo.o
> Should the linker load p/foo.o ? (If it exists, of course).
No. I think we should make the intuitive choice: the extra search path is local to the linker script.
> 2. Is this feature restricted to libraries, or should it also affect
> object files ? For example:
> % cat p/libm.a
> % ld p/libm.a
> Is this expected to load p/foo.o ?
p/foo.o will be loaded. The extra search rule should apply to any relative pathname (my observation of the gold behavior). They can be: libm.a.1 , foo.o , foo.so , relative/foo.so , etc
The -l form does not apply.
I hope the rules above are all intuitive and likely what users expect... For me, I did feel strange when I first noticed that INPUT() and GROUP() do not search for the "local files" but I did not think hard about the rule.
Proposed patch: https://sourceware.org/pipermail/binutils/2020-April/110743.html
The master branch has been updated by Nick Clifton <firstname.lastname@example.org>:
Author: Fangrui Song <email@example.com>
Date: Wed Apr 22 16:20:02 2020 +0100
For relative paths in INPUT() and GROUP(), search the directory of the current linker script before searching other paths.
* ldlang.h (struct lang_input_statement_struct): Add extra_search_path.
* ldlang.c (current_input_file): New.
(new_afile): Add from_filename parameter. Set extra_search_path.
(lang_add_input_file): Pass current_input_file to new_afile.
(load_symbols): Set current_input_file.
Note - testsuite patch may follow.