Are the pthread "compatibility" copies of symbols in libc still necessary?

[Florian Weimer]

On 03/16/2018 03:30 PM, Zack Weinberg wrote:
> A number of source files that properly belong to libc.so are also
> compiled as part of libpthread, with a note that this is for
> "compatibility for old binaries".  The exact set varies based on
> architecture, but includes basic things like read, write, and fork - I
> _think_ there was a difference in semantics in the distant past,
> having something to do with thread cancellation.

They are still needed because versioned symbols also embed a DSO name, 
and the dynamic linker checks that if it has not been interposed.

I think it's this code in elf/dl-lookup.c:

       if (__glibc_unlikely (res < 0) && skip_map == NULL)
	{
	  /* Oh, oh.  The file named in the relocation entry does not
	     contain the needed symbol.  This code is never reached
	     for unversioned lookups.  */
	  assert (version != NULL);
	  const char *reference_name = undef_map ? undef_map->l_name : "";
	  struct dl_exception exception;
	  /* XXX We cannot translate the message.  */
	  _dl_exception_create_format
	    (&exception, DSO_FILENAME (reference_name),
	     "symbol %s version %s not defined in file %s"
	     " with link time reference%s",
	     undef_name, version->name, version->filename,
	     res == -2 ? " (no version symbols)" : "");
	  _dl_signal_cexception (0, &exception, N_("relocation error"));
	  _dl_exception_free (&exception);
	  *ref = NULL;
	  return 0;
	}

This is required by the GNU symbol versioning spec, but I don't know why.

Even new binaries use these symbols:

$ LD_DEBUG=bindings systemctl |& grep binding.*system.*libpthread.*[^_]fork
      11905:	binding file /usr/lib/systemd/libsystemd-shared-234.so [0] 
to /lib64/libpthread.so.0 [0]: normal symbol `fork' [GLIBC_2.2.5]
      11905:	binding file systemctl [0] to /lib64/libpthread.so.0 [0]: 
normal symbol `fork' [GLIBC_2.2.5]

This may be a linker bug because at least fork is a compat symbol.

Thanks,
Florian