bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/25806] [ld] Search for input files relative to the current linke


From: i at maskray dot me
Subject: [Bug ld/25806] [ld] Search for input files relative to the current linker script
Date: Thu, 09 Apr 2020 16:46:31 +0000

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]