public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nicholas Vinson <nvinson234@gmail.com>
To: Nick Alcock <nick.alcock@oracle.com>
Cc: Sam James <sam@gentoo.org>, binutils <binutils@sourceware.org>
Subject: Re: [binutils] libctf: Remove undefined functions from ver. map
Date: Thu, 29 Feb 2024 20:49:12 -0500	[thread overview]
Message-ID: <78f71dff-4190-41ba-bdfc-162e417ab638@gmail.com> (raw)
In-Reply-To: <87v868qwvd.fsf@esperi.org.uk>



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.

Thanks,
Nicholas Vinson

  reply	other threads:[~2024-03-01  1:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-28 19:10 Nicholas Vinson
     [not found] ` <87bk828z6q.fsf@gentoo.org>
2024-02-27 15:05   ` Nick Alcock
2024-02-28  0:32     ` Nicholas Vinson
2024-02-28 18:14       ` Nick Alcock
2024-03-01  1:49         ` Nicholas Vinson [this message]
2024-03-01 17:46           ` Nick Alcock
2024-03-02  3:36             ` Nicholas Vinson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=78f71dff-4190-41ba-bdfc-162e417ab638@gmail.com \
    --to=nvinson234@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=nick.alcock@oracle.com \
    --cc=sam@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).