This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Update LTO plugin interface


On Thu, Dec 2, 2010 at 4:04 PM, Cary Coutant <ccoutant@google.com> wrote:
>> This isn't quite what should happen, though. ?If the user does not
>> specify -lm on the link line, then we should not add -lm, even if LTO
>> somehow introduces a function that is defined in libm. ?Automatically
>> adding -lm would introduce a surprising dynamic dependency in some
>> cases. ?The user should be explicit about that.
>
> I wouldn't expect the compiler to introduce a call to anything in libm
> when -lm isn't already specified on the command line (that would break
> even without LTO).
>
> With what I'm suggesting, we'll only resolve libcalls to libraries
> that were originally specified on the command line.
>
>> That is, it really doesn't matter which library libcalls come from. ?All
>> we need to know is which libraries might satisfy new libcalls.
>>
>> This is what leads me in the direction of copying certain libraries
>> mentioned on the command line to follow the LTO objects, much as
>> -pass-through does. ?I think we just need to make that a little bit more
>> automatic.
>
> Another way to do this would be to put a marker in the command line
> that identifies where those libraries begin, and the linker could just
> go back and rescan those libraries if needed, before the final layout
> of the endcaps.
>

We also need to handle .a vs .so.  We shouldn't add libm,so when user
specifies libm.a at command line.


-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]