Fwd: MIPSEL GLIBC sem_init() not shared

[Alessandro Carminati]

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