[PATCH v2] Detect ld.so and libc.so version inconsistency during startup

Florian Weimer fweimer@redhat.com
Tue Aug 23 21:36:41 GMT 2022


* Carlos O'Donell:

> I can't see this causes serious problems crossing container, chroot or
> namespace boundaries because we load libc.so.6 early before doing any
> kind of transition.  Where it might have impact is in the developer
> workflow and we can adjust as required.

dlmopen after chroot may now fail due to ABI mismatch, but I think this
is correct.
>> -  [Add new features here]
>> +* The dynamic loader now prints an error message, "ld.so/libc.so
>> +  mismatch detected (upgrade in progress?)" if it detects that the
>> +  version of libc.so it loaded comes from a different build of glibc.
>> +  The new configure option --with-extra-version-id can be used to
>> +  specify an arbitrary string that affects the comptuation of the
>
> s/comptuation/computation/g

>> +  /* Detect a libc.so loaded into this namespace.  The
>> +     __libc_early_init lookup below means that we have to do this
>> +     after parsing the version data.  */
>> +  if (GL(dl_ns)[map->l_ns].libc_map == NULL
>> +      && map->l_info[DT_SONAME] != NULL
>> +      && strcmp (((const char *) D_PTR (map, l_info[DT_STRTAB])
>> +		  + map->l_info[DT_SONAME]->d_un.d_val), LIBC_SO) == 0)
>> +    {
>> +      /* Look up this symbol error to trigger a mismatch error before
>
> s/error//g

Both fixed and reposted.  In the second case, I meant to type “early”.

Thanks,
Florian



More information about the Libc-alpha mailing list