From: Alessandro Carminati <alessandro.carminati@gmail.com>
To: libc-help@sourceware.org
Subject: Re: Fwd: MIPSEL GLIBC sem_init() not shared
Date: Fri, 12 Mar 2021 14:41:15 +0100 [thread overview]
Message-ID: <CAPp5cGREJe02DmO5WastxPWEMjZf698usVPatgLpen1H3FTm9A@mail.gmail.com> (raw)
In-Reply-To: <87sg505zy0.fsf@oldenburg.str.redhat.com>
On Fri, Mar 12, 2021 at 1:17 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Alessandro Carminati via Libc-help:
>
> > This time was the port on MIPSEL, but before this port, I compiled
> > successfully (without -lpthread) on two other architectures: ARM32 and
> > x64. Which is the mechanism why in other architecture, the libpthread
> > was included and in MIPS it didn't?
>
> 32-bit Arm starts at GLIBC_2.4, x86-64 starts at GLIBC_2.2.5. The old
> versions aren't there, so an underlinked library cannot bind against
> them.
I noticed this fact, and I wondered if I could change anything in the
configuration of the glibc to remove the __old_sem_init.
Obviously, I now have a better solution, so I'll stick with that.
I also checked the DT_NEEDED in the liba.so in these two architectures.
They have libpthread even if I compiled them without -lpthread
I must assume this as a specificity of their version of the GCC.
>
> > My question is, why it resolved the call picking the
> > sem_init@GLIBC_2.0 instead of sem_init@@GLIBC_2.2?
>
> glibc originally did not have symbol versioning, so for backwards
> compatibility, unversioned binaries need to pick the oldest available
> version. In theory, we could provide better diagnostics. But we're
> working on moving all libpthread symbols in to libc.so.6, so that their
> versions are always visible to the link editor (unless you link with
> -nostdblib, but then you are on your own anyway). That's why the
> diagnostics do not seem to be particularly useful in the medium term.
What you say makes sense. And explains the behavior I observed in my code.
But "unversioned binaries need to pick the oldest available version"
is in contrast with what you can read on the internet about the same
argument.
I must admit that before stepping into this issue, I ignored the
symbol versioning even exists.
By the way, here's what I found on the internet:
http://peeterjoot.com/2019/09/20/an-example-of-linux-glibc-symbol-versioning/
"The @@ one means that it applies to new code, whereas the
@MYSTUFF_1.1 is a load only function, and no new code can use that
symbol."
https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility/
"The @@ tells the dynamic linker that this version is the default
version."
https://web.archive.org/web/20100430151127/http://www.trevorpounds.com/blog/?33
"The double @@ can only be defined once for a given symbol since it
denotes the default version to use."
Al the sources I have found seems to agree on the fact that if a
symbol is unversioned, like in my case, the symbol the dynamic linker
should use is the one that carries the "@@"
In my scenario, the symbol which carries the double @@ is the
sem_init@@GLIBC_2_2.
If the dynamic linker would have picked it, as it should, if I
correctly interpret what I read, I wouldn't be here asking.
Could you add a comment on that?
Thank you
Alessandro
next prev parent reply other threads:[~2021-03-12 13:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-12 9:31 Alessandro Carminati
2021-03-12 10:49 ` Florian Weimer
[not found] ` <CAPp5cGTfu38orQNtDRXrxenPDKYbJgEmFHjcw8QspURmCkZL0Q@mail.gmail.com>
2021-03-12 11:37 ` Fwd: " Alessandro Carminati
2021-03-12 12:17 ` Florian Weimer
2021-03-12 13:41 ` Alessandro Carminati [this message]
2021-03-12 16:04 ` Florian Weimer
2021-03-13 6:53 ` Alessandro Carminati
2021-03-13 7:05 ` Florian Weimer
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=CAPp5cGREJe02DmO5WastxPWEMjZf698usVPatgLpen1H3FTm9A@mail.gmail.com \
--to=alessandro.carminati@gmail.com \
--cc=libc-help@sourceware.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).