Re: [binutils] libctf: Remove undefined functions from ver. map

[Nicholas Vinson <nvinson234@gmail.com>]

On 3/1/24 12:46, Nick Alcock wrote:
> On 1 Mar 2024, Nicholas Vinson spake thusly:
> 
>>
>>
>> On 2/28/24 13:14, Nick Alcock wrote:
>>> On 28 Feb 2024, Nicholas Vinson told this:
>>>
>>>> On 2/27/24 10:05, Nick Alcock wrote:
>>>>> On 27 Feb 2024, Sam James said:
>>>>>
>>>>>> Nicholas Vinson <nvinson234@gmail.com> writes:
>>>>>>
>>>>>>> The functions ctf_label_set(), ctf_label_get(), ctf_arc_open(), ctf_fdopen(),
>>>>>>> ctf_open(), ctf_bfdopen(), and ctf_bfdopen_ctfsect() are not defined. Their
>>>>>>> inclusion in libctf/libctf.ver causes clang/llvm LTO optimizatiosn to fail with
>>>>>>> error messages similar to
>>>>> This is definitely not right. They *are* defined, but only for some
>>>>> libraries built from this version script. You can't just take them out.
>>>>
>>>> Could you point me to the definitions for ctf_label_set() and ctf_label_get() ?
>>> Those two are long dead and gone and should indeed be removed from the
>>> .ver script. (I wonder why Solaris's linker, which is just as picky
>>> about version scripts referencing only symbols that actually exist,
>>> never warned me about this.)
>>>
>>>> I do find definitions for the other so the other symbols, so I'll find
>>>> a different way to handle those symbols in the version file.
>>> Commenting them as /* libctf only. */ should be enough, I think. Only
>>> one symbol seems to be missing, ctf_arc_open. The others are already
>>> properly marked and should already be being excluded from the .ver
>>> script for libctf_nobfd.so.)
>>>
>>
>> I see what you're talking about in libctf/configure.ac. However, it's protected by a `test -n "$decommented_version_script"` check.
>> Because ld.lld does not understand `-B local`, that variable remains empty and the lines in the version file containing /* libctf
>> only.  */ are not removed.
> 
> Aha! GNU ld doesn't support that option either. This test was meant to
> detect Solaris ld, which supports version scripts with similar "no
> undefined symbols" limitations to what lld seems to here. I'd suggest
> that configure test needs augmenting to catch lld as well when this flag
> is provided (so specifying $LDFLAGS in whatever test you carry out).
> 
I'm considering this thread closed. I have a new patch that solves the 
problem. I'll post it soon.

Thanks,
Nicholas Vinson