glibc-2.33.9000-4.fc35 and __libc_start_main@GLIBC_2.34
by Florian Weimer
I've built glibc-2.33.9000-4.fc35 in a side tag (f35-build-side-40742),
but do not plan to merge it yet. Annobin has been disabled on armhfp
due to bug 1951492.
I plan to stabilize the ABI further upstream, working towards isolation
of libpthread from the _rtld_global and _rtld_global_ro layout, and also
address the weak symbol consistency issue. I should have patches for
both by the end of tomorrow. Once these patches are integrated
upstream, we can consider putting a current 2.34 snapshot into rawhide
even before pthread_create itself is moved.
There's currently an issue around __libc_start_main(a)GLIBC_2.34. Arjun's
last sync (which is also part of glibc-2.33.9000-4.fc35) brings in that
symbol version, but I also need that GLIBC_2.34 version to tell old and
new binaries apart. The problem is that if we start building bison et
al. against glibc-2.33.9000-4.fc35, the resulting binaries will pick up
__libc_start_main(a)GLIBC_2.34, making them new binaries, while in fact
the old (pre-2.34) ABI is still used. The new ABI elements only come in
with later upstream commits. So if we integrate glibc-2.33.9000-4.fc35
today, we'd have to do quite a bit of cleanup work later.
In short, glibc is building again, but we shouldn't update it.
Thanks,
Florian
2 years, 11 months
- 1
- 0
- ← Newer
- 1
- Older →