[00/10] nptl: Complete libpthread removal

  This series finally removes libpthread for Linux/NPTL.

The first patch supersedes “nptl: Introduce __nptl_deferred_init”.  I
think doing cancel initialization on pthread_cancel is not an
improvement because we would have to use another flag to avoid the extra
system calls.  The next two patches were posted previous; Adhemerval
already reviewed them.

One test had to be adjusted because it use libpthread as the canonical
NODELETE object.

We need to provide libpthread.so.0 stub object for use with
memusagestat, otherwise a system libpthread.so.0 might leak into the
link.  Not loading libpthread.so.0 is hacked directly into the dynamic
loader.

For some reason, pthread debugging still works even without libpthread
loaded.  I didn't have to add the fake libpthread.so.0 link map to
trigger loading of libthread_db in GDB.  Testing with systemtap and
dyninst will happen once we get this into Fedora rawhide.

I have built and tested various intermediate steps (i686-linux-gnu,
x86_64-linux-gnu, build-many-glibcs.py).  In particular, the placeholder
symbols in the code-less libpthread match the abilist files.

Thanks,
Florian

Florian Weimer (10):
  nptl: Perform signal initialization upon pthread_create
  nptl: Eliminate the __static_tls_size, __static_tls_align_m1 variables
  nptl: Move semi-public __pthread_get_minstack symbol into libc
  elf: Use custom NODELETE DSO for tst-dlopenfail, tst-dlopenfail-2
  nptl: Move pthread_create, thrd_create into libc
  nptl: Remove unused __libc_pthread_init function
  nptl: Remove remaining code from libpthread
  elf: Do not load libpthread for PTHREAD_IN_LIBC
  elf: Add facility to create stub DSOs in elf/stub-dsos
  nptl: Stop building libpthread

 Makeconfig                                    |  13 +-
 elf/Makefile                                  |  29 ++-
 elf/dl-load.c                                 |  19 +-
 elf/dl-tls.c                                  |   5 +-
 elf/dl-version.c                              |   9 +
 nptl/version.c => elf/lib-stub.S              |  31 +--
 elf/tst-dlopenfail-2.c                        |   5 +-
 elf/tst-dlopenfail.c                          |  44 ++---
 elf/tst-dlopenfailmod2.c                      |   6 +-
 .../tst-dlopenfailnodelmod.c                  |  24 +--
 include/libc-internal.h                       |   6 +-
 nptl/Makefile                                 |  77 +-------
 nptl/Versions                                 |  33 ++--
 nptl/allocatestack.c                          |  25 +--
 nptl/libpthread-compat.c                      | 112 -----------
 nptl/libpthread-stub.S                        |   1 +
 nptl/nptl-init.c                              | 180 ------------------
 nptl/nptl-stack.c                             |  17 ++
 nptl/nptl-stack.h                             |  11 +-
 nptl/pt-crti.S                                |  50 -----
 nptl/pt-interp.c                              |   1 -
 nptl/pthreadP.h                               |  18 +-
 nptl/pthread_cancel.c                         |  88 ++++++++-
 nptl/pthread_create.c                         |  60 +++++-
 nptl/pthread_getattr_default_np.c             |   6 +-
 nptl_db/Makefile                              |   2 +-
 nptl_db/structs.def                           |  10 +-
 sysdeps/arm/nptl-aeabi_unwind_cpp_pr1.c       |   1 -
 sysdeps/arm/nptl/Makefile                     |   3 -
 sysdeps/ia64/nptl/Makefile                    |   5 -
 sysdeps/mips/Makefile                         |   5 -
 sysdeps/mips/nptl/Makefile                    |   5 -
 sysdeps/mips/nptl/nptl-sysdep.S               |   2 -
 sysdeps/nptl/Makeconfig                       |   7 +-
 sysdeps/nptl/Makefile                         |   4 -
 sysdeps/nptl/pthread_early_init.h             |  28 +++
 sysdeps/nptl/thrd_create.c                    |   2 -
 sysdeps/pthread/Makefile                      |   3 +-
 sysdeps/pthread/thrd_create.c                 |  11 +-
 sysdeps/riscv/nptl/Makefile                   |   5 -
 sysdeps/riscv/nptl/nptl-sysdep.S              |   2 -
 sysdeps/s390/nptl/Makefile                    |   5 -
 sysdeps/sparc/Makefile                        |   4 -
 sysdeps/sparc/nptl/Makefile                   |   5 -
 sysdeps/unix/sysv/linux/aarch64/libc.abilist  |   4 +
 .../sysv/linux/aarch64/libpthread.abilist     |   6 -
 sysdeps/unix/sysv/linux/alpha/Makefile        |   6 -
 sysdeps/unix/sysv/linux/alpha/libc.abilist    |   5 +
 .../unix/sysv/linux/alpha/libpthread.abilist  |  18 --
 sysdeps/unix/sysv/linux/arc/libc.abilist      |   4 +
 .../unix/sysv/linux/arc/libpthread.abilist    |   3 -
 sysdeps/unix/sysv/linux/arm/Makefile          |   5 -
 sysdeps/unix/sysv/linux/arm/be/libc.abilist   |   4 +
 .../unix/sysv/linux/arm/be/libpthread.abilist |   9 -
 sysdeps/unix/sysv/linux/arm/le/libc.abilist   |   4 +
 .../unix/sysv/linux/arm/le/libpthread.abilist |   9 -
 sysdeps/unix/sysv/linux/csky/libc.abilist     |   4 +
 .../unix/sysv/linux/csky/libpthread.abilist   |   5 -
 sysdeps/unix/sysv/linux/hppa/libc.abilist     |   4 +
 .../unix/sysv/linux/hppa/libpthread.abilist   |  14 --
 sysdeps/unix/sysv/linux/i386/Makefile         |  11 --
 sysdeps/unix/sysv/linux/i386/libc.abilist     |   5 +
 .../unix/sysv/linux/i386/libpthread.abilist   |  18 --
 sysdeps/unix/sysv/linux/ia64/libc.abilist     |   4 +
 .../unix/sysv/linux/ia64/libpthread.abilist   |  14 --
 .../sysv/linux/m68k/coldfire/libc.abilist     |   4 +
 .../linux/m68k/coldfire/libpthread.abilist    |   9 -
 .../unix/sysv/linux/m68k/m680x0/libc.abilist  |   5 +
 .../sysv/linux/m68k/m680x0/libpthread.abilist |  18 --
 sysdeps/unix/sysv/linux/microblaze/Makefile   |   6 -
 .../sysv/linux/microblaze/be/libc.abilist     |   4 +
 .../linux/microblaze/be/libpthread.abilist    |   5 -
 .../sysv/linux/microblaze/le/libc.abilist     |   4 +
 .../linux/microblaze/le/libpthread.abilist    |   5 -
 .../sysv/linux/mips/mips32/fpu/libc.abilist   |   5 +
 .../sysv/linux/mips/mips32/libpthread.abilist |  15 --
 .../sysv/linux/mips/mips32/nofpu/libc.abilist |   5 +
 .../sysv/linux/mips/mips64/libpthread.abilist |  15 --
 .../sysv/linux/mips/mips64/n32/libc.abilist   |   5 +
 .../sysv/linux/mips/mips64/n64/libc.abilist   |   5 +
 sysdeps/unix/sysv/linux/nios2/libc.abilist    |   4 +
 .../unix/sysv/linux/nios2/libpthread.abilist  |   5 -
 sysdeps/unix/sysv/linux/powerpc/Makefile      |   5 -
 .../linux/powerpc/powerpc32/fpu/libc.abilist  |   5 +
 .../powerpc/powerpc32/libpthread.abilist      |  19 --
 .../powerpc/powerpc32/nofpu/libc.abilist      |   5 +
 .../linux/powerpc/powerpc64/be/libc.abilist   |   4 +
 .../powerpc/powerpc64/be/libpthread.abilist   |  13 --
 .../linux/powerpc/powerpc64/le/libc.abilist   |   4 +
 .../powerpc/powerpc64/le/libpthread.abilist   |   6 -
 .../unix/sysv/linux/riscv/rv32/libc.abilist   |   4 +
 .../sysv/linux/riscv/rv32/libpthread.abilist  |   3 -
 .../unix/sysv/linux/riscv/rv64/libc.abilist   |   4 +
 .../sysv/linux/riscv/rv64/libpthread.abilist  |   5 -
 .../unix/sysv/linux/s390/s390-32/libc.abilist |   5 +
 .../linux/s390/s390-32/libpthread.abilist     |  19 --
 .../unix/sysv/linux/s390/s390-64/libc.abilist |   4 +
 .../linux/s390/s390-64/libpthread.abilist     |  15 --
 sysdeps/unix/sysv/linux/sh/be/libc.abilist    |   4 +
 .../unix/sysv/linux/sh/be/libpthread.abilist  |  14 --
 sysdeps/unix/sysv/linux/sh/le/libc.abilist    |   4 +
 .../unix/sysv/linux/sh/le/libpthread.abilist  |  14 --
 sysdeps/unix/sysv/linux/sparc/Makefile        |   6 -
 .../sysv/linux/sparc/sparc32/libc.abilist     |   5 +
 .../linux/sparc/sparc32/libpthread.abilist    |  18 --
 .../sysv/linux/sparc/sparc64/libc.abilist     |   4 +
 .../linux/sparc/sparc64/libpthread.abilist    |  14 --
 .../unix/sysv/linux/x86_64/64/libc.abilist    |   4 +
 .../sysv/linux/x86_64/64/libpthread.abilist   |  13 --
 .../unix/sysv/linux/x86_64/x32/libc.abilist   |   4 +
 .../sysv/linux/x86_64/x32/libpthread.abilist  |   6 -
 111 files changed, 510 insertions(+), 974 deletions(-)
 rename nptl/version.c => elf/lib-stub.S (51%)
 rename nptl/libc_pthread_init.c => elf/tst-dlopenfailnodelmod.c (61%)
 delete mode 100644 nptl/libpthread-compat.c
 create mode 100644 nptl/libpthread-stub.S
 delete mode 100644 nptl/nptl-init.c
 delete mode 100644 nptl/pt-crti.S
 delete mode 100644 nptl/pt-interp.c
 delete mode 100644 sysdeps/arm/nptl-aeabi_unwind_cpp_pr1.c
 delete mode 100644 sysdeps/mips/nptl/nptl-sysdep.S
 delete mode 100644 sysdeps/nptl/thrd_create.c
 delete mode 100644 sysdeps/riscv/nptl/nptl-sysdep.S
 delete mode 100644 sysdeps/unix/sysv/linux/aarch64/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/alpha/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/arc/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/arm/be/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/arm/le/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/csky/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/hppa/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/i386/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/ia64/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/m68k/coldfire/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/m68k/m680x0/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/microblaze/be/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/microblaze/le/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/mips/mips32/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/mips/mips64/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/nios2/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/powerpc/powerpc32/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/powerpc/powerpc64/be/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/s390/s390-32/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/s390/s390-64/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/sh/be/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/sh/le/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/sparc/sparc32/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/sparc/sparc64/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/x86_64/64/libpthread.abilist
 delete mode 100644 sysdeps/unix/sysv/linux/x86_64/x32/libpthread.abilist
  

On Mai 18 2021, Florian Weimer via Libc-alpha wrote:

> We need to provide libpthread.so.0 stub object for use with
> memusagestat, otherwise a system libpthread.so.0 might leak into the
> link.  Not loading libpthread.so.0 is hacked directly into the dynamic
> loader.

What would happen if the lpthread stub would be loaded?

Andreas.
  

* Andreas Schwab:

> On Mai 18 2021, Florian Weimer via Libc-alpha wrote:
>
>> We need to provide libpthread.so.0 stub object for use with
>> memusagestat, otherwise a system libpthread.so.0 might leak into the
>> link.  Not loading libpthread.so.0 is hacked directly into the dynamic
>> loader.
>
> What would happen if the lpthread stub would be loaded?

I made sure that it crashes:

	/* Produce an invalid init function, so that loading the stub
	   crashes.  */
	.section .init_array,"a",%init_array
	.dc.a 4096

I tried adding an undefined symbol, but that make the stub unusable as a
stub, too.

Neither binutils nor glibc currently support DF_1_STUB, so that's not an
option.

Thanks,
Florian
  

On Mai 18 2021, Florian Weimer wrote:

> * Andreas Schwab:
>
>> On Mai 18 2021, Florian Weimer via Libc-alpha wrote:
>>
>>> We need to provide libpthread.so.0 stub object for use with
>>> memusagestat, otherwise a system libpthread.so.0 might leak into the
>>> link.  Not loading libpthread.so.0 is hacked directly into the dynamic
>>> loader.
>>
>> What would happen if the lpthread stub would be loaded?
>
> I made sure that it crashes:

What's wrong with providing an empty libpthread.so.0, and a no-op
libpthread.{so,a}?

Andreas.
  

* Andreas Schwab:

> On Mai 18 2021, Florian Weimer wrote:
>
>> * Andreas Schwab:
>>
>>> On Mai 18 2021, Florian Weimer via Libc-alpha wrote:
>>>
>>>> We need to provide libpthread.so.0 stub object for use with
>>>> memusagestat, otherwise a system libpthread.so.0 might leak into the
>>>> link.  Not loading libpthread.so.0 is hacked directly into the dynamic
>>>> loader.
>>>
>>> What would happen if the lpthread stub would be loaded?
>>
>> I made sure that it crashes:
>
> What's wrong with providing an empty libpthread.so.0, and a no-op
> libpthread.{so,a}?

I'm already adding a no-op libpthread.a, so that -lpthread keeps
working.  As far as I can tell, a libpthread.so.0 is not needed because
it's not an error for ld if it is missing despite a DT_NEEDED reference.
(The stub is not installed, it's only needed because non-cross builds
pick up libpng et al. from the system environment.)

Thanks,
Florian
  

On Mai 18 2021, Florian Weimer wrote:

> I'm already adding a no-op libpthread.a, so that -lpthread keeps
> working.  As far as I can tell, a libpthread.so.0 is not needed because
> it's not an error for ld if it is missing despite a DT_NEEDED reference.

Though you will get an annoying warning.

Andreas.
  

* Andreas Schwab:

> On Mai 18 2021, Florian Weimer wrote:
>
>> I'm already adding a no-op libpthread.a, so that -lpthread keeps
>> working.  As far as I can tell, a libpthread.so.0 is not needed because
>> it's not an error for ld if it is missing despite a DT_NEEDED reference.
>
> Though you will get an annoying warning.

I don't think we can do anything about that.  The libpthread.so linker
script won't suppress it because it's not loaded implicitly, and as soon
we load libpthread.so.0 explicitly during the link, we also end up with
a DT_NEEDED reference, which I don't think we want.

Thanks,
Florian
  

On Mai 18 2021, Florian Weimer wrote:

> I don't think we can do anything about that.  The libpthread.so linker
> script won't suppress it because it's not loaded implicitly, and as soon
> we load libpthread.so.0 explicitly during the link, we also end up with
> a DT_NEEDED reference, which I don't think we want.

I don't think that would be such a bad thing.  It will vanish over time
when libraries are relinked.

Andreas.
  

The 05/18/2021 16:24, Florian Weimer via Libc-alpha wrote:
> This series finally removes libpthread for Linux/NPTL.

sorry i don't know when this started but in libc.a
now i see

cnd_wait.o:
0000000000000000 T __cnd_wait
0000000000000000 W cnd_wait
                 U __pthread_cond_wait

and __pthread_cond_wait is not defined anywhere.
(only a 3 _ prefix version)

(in cnd_wait.os i see
                 U __GI___pthread_cond_wait
which is a hidden symbol in libc.so now)

so now static linking code with cnd_wait fails.
  

* Szabolcs Nagy:

> The 05/18/2021 16:24, Florian Weimer via Libc-alpha wrote:
>> This series finally removes libpthread for Linux/NPTL.
>
> sorry i don't know when this started but in libc.a
> now i see
>
> cnd_wait.o:
> 0000000000000000 T __cnd_wait
> 0000000000000000 W cnd_wait
>                  U __pthread_cond_wait
>
> and __pthread_cond_wait is not defined anywhere.
> (only a 3 _ prefix version)
>
> (in cnd_wait.os i see
>                  U __GI___pthread_cond_wait
> which is a hidden symbol in libc.so now)
>
> so now static linking code with cnd_wait fails.

Ugh, I thought the linknamespace tests would cover that.

This is a generic issue related to how libc_hidden_ver is defined: It
does not create an alias as one might expect for the static libc, but
actually expands to nothing.  I hacked around this with an explicit
strong_alias in some places, but it looks like I missed a few cases.

Should we try to change the definition of libc_hidden_ver, or add more
strong_alias directives?

Thanks,
Florian
  

The 05/19/2021 14:35, Florian Weimer wrote:
> * Szabolcs Nagy:
> > The 05/18/2021 16:24, Florian Weimer via Libc-alpha wrote:
> >> This series finally removes libpthread for Linux/NPTL.
> >
> > sorry i don't know when this started but in libc.a
> > now i see
> >
> > cnd_wait.o:
> > 0000000000000000 T __cnd_wait
> > 0000000000000000 W cnd_wait
> >                  U __pthread_cond_wait
> >
> > and __pthread_cond_wait is not defined anywhere.
> > (only a 3 _ prefix version)
> >
> > (in cnd_wait.os i see
> >                  U __GI___pthread_cond_wait
> > which is a hidden symbol in libc.so now)
> >
> > so now static linking code with cnd_wait fails.
> 
> Ugh, I thought the linknamespace tests would cover that.
> 
> This is a generic issue related to how libc_hidden_ver is defined: It
> does not create an alias as one might expect for the static libc, but
> actually expands to nothing.  I hacked around this with an explicit
> strong_alias in some places, but it looks like I missed a few cases.
> 
> Should we try to change the definition of libc_hidden_ver, or add more
> strong_alias directives?

there are quite a few libc_hidden_ver uses and i assume
now exists many

  some_alias (foo, bar)
  libc_hidden_ver (foo, bar)

even in target specific code, which has to be changed
and tested if libc_hidden_ver is changed.

but if we always want libc_hidden_ver to create an alias
for static linking then it would be nice to fix at some
point.
  

* Andreas Schwab:

> On Mai 18 2021, Florian Weimer wrote:
>
>> I don't think we can do anything about that.  The libpthread.so linker
>> script won't suppress it because it's not loaded implicitly, and as soon
>> we load libpthread.so.0 explicitly during the link, we also end up with
>> a DT_NEEDED reference, which I don't think we want.
>
> I don't think that would be such a bad thing.  It will vanish over time
> when libraries are relinked.

Coming back to this, should we stop loading libpthread at all?  That is,
keep libpthread.so.0 around indefinitely (with the placeholder symbols
and symbol versions), and just wait until more and more binaries are
linked with the empty libpthread.a and no longer have a DT_NEEDED
dependency on libpthread.so.0?

Thanks,
Florian
  

On Mai 20 2021, Florian Weimer wrote:

> That is, keep libpthread.so.0 around indefinitely (with the
> placeholder symbols and symbol versions), and just wait until more and
> more binaries are linked with the empty libpthread.a and no longer
> have a DT_NEEDED dependency on libpthread.so.0?

I don't see any downsides with this approach.

Andreas.
  

* Andreas Schwab:

> On Mai 20 2021, Florian Weimer wrote:
>
>> That is, keep libpthread.so.0 around indefinitely (with the
>> placeholder symbols and symbol versions), and just wait until more and
>> more binaries are linked with the empty libpthread.a and no longer
>> have a DT_NEEDED dependency on libpthread.so.0?
>
> I don't see any downsides with this approach.

There's a slight additional run-time overhead due to the loaded object.
But I don't feel strongly about this.

Do you think it's okay if we ship libpthread.a only, or should we
install a no-op libpthread.so as well?  -lpthread will use the .a file
for static and dynamic links, so I think that's sufficient.

Thanks,
Florian
  

On Mai 20 2021, Florian Weimer wrote:

> Do you think it's okay if we ship libpthread.a only, or should we
> install a no-op libpthread.so as well?

I don't see any need for libpthread.so.

Andreas.
  

On Thu, May 20, 2021 at 8:06 AM Florian Weimer via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> * Andreas Schwab:
>
> > On Mai 20 2021, Florian Weimer wrote:
> >
> >> That is, keep libpthread.so.0 around indefinitely (with the
> >> placeholder symbols and symbol versions), and just wait until more and
> >> more binaries are linked with the empty libpthread.a and no longer
> >> have a DT_NEEDED dependency on libpthread.so.0?
> >
> > I don't see any downsides with this approach.
>
> There's a slight additional run-time overhead due to the loaded object.
> But I don't feel strongly about this.
>
> Do you think it's okay if we ship libpthread.a only, or should we
> install a no-op libpthread.so as well?  -lpthread will use the .a file
> for static and dynamic links, so I think that's sufficient.

Can we ship a dummy linker script for libpthread.so to just
satisfy -lpthread at link-time?
  

* H. J. Lu:

> On Thu, May 20, 2021 at 8:06 AM Florian Weimer via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>>
>> * Andreas Schwab:
>>
>> > On Mai 20 2021, Florian Weimer wrote:
>> >
>> >> That is, keep libpthread.so.0 around indefinitely (with the
>> >> placeholder symbols and symbol versions), and just wait until more and
>> >> more binaries are linked with the empty libpthread.a and no longer
>> >> have a DT_NEEDED dependency on libpthread.so.0?
>> >
>> > I don't see any downsides with this approach.
>>
>> There's a slight additional run-time overhead due to the loaded object.
>> But I don't feel strongly about this.
>>
>> Do you think it's okay if we ship libpthread.a only, or should we
>> install a no-op libpthread.so as well?  -lpthread will use the .a file
>> for static and dynamic links, so I think that's sufficient.
>
> Can we ship a dummy linker script for libpthread.so to just
> satisfy -lpthread at link-time?

An empty libpthread.a already does that.

Thanks,
Florian
  

On Mai 20 2021, H.J. Lu wrote:

> Can we ship a dummy linker script for libpthread.so to just
> satisfy -lpthread at link-time?

-lpthread will be satisfied by libpthread.a.

Andreas.
  

On Thu, May 20, 2021 at 8:17 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> On Mai 20 2021, H.J. Lu wrote:
>
> > Can we ship a dummy linker script for libpthread.so to just
> > satisfy -lpthread at link-time?
>
> -lpthread will be satisfied by libpthread.a.
>
> Andreas.
>

What is the problem then?  We have to keep libpthread.so.0 for existing
binaries.  We just don't link against it for new binaries.
  

* H. J. Lu:

> On Thu, May 20, 2021 at 8:17 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
>>
>> On Mai 20 2021, H.J. Lu wrote:
>>
>> > Can we ship a dummy linker script for libpthread.so to just
>> > satisfy -lpthread at link-time?
>>
>> -lpthread will be satisfied by libpthread.a.
>>
>> Andreas.
>>
>
> What is the problem then?  We have to keep libpthread.so.0 for existing
> binaries.  We just don't link against it for new binaries.

I was a bit creative and patched the dynamic loader not to load
libpthread.so.0 ever (treating it as a reference to libc.so.6).  If we
don't want to do that (and the consensus is moving in that direction),
then we need to keep the DSO around as an actual file.

Thanks,
Florian
  

On Thu, May 20, 2021 at 8:39 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > On Thu, May 20, 2021 at 8:17 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
> >>
> >> On Mai 20 2021, H.J. Lu wrote:
> >>
> >> > Can we ship a dummy linker script for libpthread.so to just
> >> > satisfy -lpthread at link-time?
> >>
> >> -lpthread will be satisfied by libpthread.a.
> >>
> >> Andreas.
> >>
> >
> > What is the problem then?  We have to keep libpthread.so.0 for existing
> > binaries.  We just don't link against it for new binaries.
>
> I was a bit creative and patched the dynamic loader not to load
> libpthread.so.0 ever (treating it as a reference to libc.so.6).  If we
> don't want to do that (and the consensus is moving in that direction),
> then we need to keep the DSO around as an actual file.

I think we should keep it as an actual DSO.