https://sourceware.org/bugzilla/show_bug.cgi?id=25806
--- Comment #3 from Fangrui Song <i at maskray dot me> --- (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 > INPUT(libm.a.1) > INPUT(foo.o) > > % ld p/libm.a > > Is this expected to load p/foo.o ? > > Cheers > Nick 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. -- You are receiving this mail because: You are on the CC list for the bug.