Fwd: MIPSEL GLIBC sem_init() not shared

[Alessandro Carminati <alessandro.carminati@gmail.com>]

On Fri, Mar 12, 2021 at 11:49 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Alessandro Carminati via Libc-help:
>
> > But looking at the liba.so dependencies, I've been surprised by the
> > fact that the library depends only on the main libc library
> > (libc.so.6) and has no dependency on libpthread.so.0 where the actual
> > sem_* symbols are implemented.
> >
> > $ /lib/ld-2.31.so --list /usr/lib/liba.so
> >         linux-vdso.so.1 (0x7ffaa000)
> >         libc.so.6 => /lib/libc.so.6 (0x77ddc000)
> >         /lib/ld-2.31.so (0x77f8a000)
> >
> > I guess this might be related to my problem, but I have no clue how to
> > link these two facts. How the liba.so could be compiled and linked
> > using symbols its dependencies do not provide?
>
> This is called underlinking.  It produces invalid objects.
>
> > How to force the GNU linker to link against sem_init@@GLIBC_2.2
> > instead of sem_init@GLIBC_2.0?
>
> Just link with -lpthread, it will add the symbol version and call the
> right function.
>
> We are working on changes to glibc that makes it much less likely that
> such underlink can happen, so hopefully such difficult-to-debug problems
> will become a non-issue at some point in the future.
>
> Thanks,
> Florian
>
Yes, it was just as you said. Underlinking. My fault. I knew it was
related, but I put the -lptread in the wrong place.
Thanks for the answer, it resolved the main issue.

If I can, I'd like to ask you a couple of questions about the same scenario.
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?

I understand that because the libpthread is a dependency of the
executable that also depends on liba.so, at runtime, the dynamic
linker has been able to resolve the sem_init call.
My question is, why it resolved the call picking the
sem_init@GLIBC_2.0 instead of sem_init@@GLIBC_2.2?