[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