Glibc 2.28 Released With Unicode 11.0 Support, Statx & Intel Improvements

[rene]

Again, if you are seeing issues with a potentially regression on glibc please either report it on libc-alpha or open a bug report on sourceware.org.

Your reply seems like just ranting and it does not provide any information whether it is related to glibc. Disclaimer, I am a glibc maintainer and I do want to help you out if you are indeed seeing a regression.

What is ranting in specifically pointing out each and every glibc related gnulib build error? Btw. the massive segfaults just started again, now I realised it starts when rebuilding glibc a second time natively after initial cross compilation. This did not happen the last 10 years up until 2.27

PS: yes this is still not an in depth analyses, as I also have other things to do and can not spend the whole day looking into this, ..!

[ZatrazZ]

So I created patch sub-sets for findutils, m4, gzip to patch in the gnulib changes to their respective last stable release tarball, to sort this out and get a full new build boot strapped. Changes in #t2sde/svn:HEAD from the first glance it looks like the really many segfaults I got re-building a whole system with glibc-2.17 are gone, ..! ¡Yay!

Again, if you are seeing issues with a potentially regression on glibc please either report it on libc-alpha or open a bug report on sourceware.org.

Your reply seems like just ranting and it does not provide any information whether it is related to glibc. Disclaimer, I am a glibc maintainer and I do want to help you out if you are indeed seeing a regression.

[ZatrazZ]

yeah, but gnulib being GNU and used by various GNU core project, it would have been a prime example to have more standard compliant code as well as could have been fixed long before the glibc change broken building all the other core packages, … :-/

I agree with you, but this issues specific is not really related with glibc ou gnulib but with the projects themselves that decided to use gnulib compatibility wrapper instead of rolling their own. Gnulib is developed and distributed in way to embed its sources directly in the project and this requires the project to keep in sync with gnulib changes and fixes. All the issue you noted are already fixed upstream in gnulib and in some projects (coreutils for instance).

[rene]

So I created patch sub-sets for findutils, m4, gzip to patch in the gnulib changes to their respective last stable release tarball, to sort this out and get a full new build boot strapped. Changes in #t2sde/svn:HEAD from the first glance it looks like the really many segfaults I got re-building a whole system with glibc-2.17 are gone, ..! ¡Yay!

[rene]

Because this is not a good example of API / ABI breakage. As I said gnulib is abusing an non-standard API which was intended only for libstdc++ 2.96 compat (which in libstdc++ has moved on for good and we are trying to move on as well) and if programs avoid to use such implementation details (which are not part of API/ABI boundaries) these kind of breakage would be avoided.

I am not saying in this past we did not have API/ABI breakage issues, but we are currently actively working on avoid such issues and every compatibility change is discussed upstream. Also, the GNU projects are developed in a independently manner, even for gnulib with shares a lot of code with glibc. And again we have lack or resources and developers in many areas, we don't have an a continuous integration system for instance and some architectures are only tested once every release.

yeah, but gnulib being GNU and used by various GNU core project, it would have been a prime example to have more standard compliant code as well as could have been fixed long before the glibc change broken building all the other core packages, … :-/

[ZatrazZ]

PS: https://bugzilla.redhat.com/show_bug.cgi?id=1595702

PPS: with breakage like this I always wonder (also already 2 decades ago w/ gcc-3.0, or glibc NPTL and such) why this is not orchestrated more perfectly. Is such API / ABI breakage is done, why are the GNU dependencies not updated first and new versions release, before pushing the glibc release, ..??!!

Because this is not a good example of API / ABI breakage. As I said gnulib is abusing an non-standard API which was intended only for libstdc++ 2.96 compat (which in libstdc++ has moved on for good and we are trying to move on as well) and if programs avoid to use such implementation details (which are not part of API/ABI boundaries) these kind of breakage would be avoided.

I am not saying in this past we did not have API/ABI breakage issues, but we are currently actively working on avoid such issues and every compatibility change is discussed upstream. Also, the GNU projects are developed in a independently manner, even for gnulib with shares a lot of code with glibc. And again we have lack or resources and developers in many areas, we don't have an a continuous integration system for instance and some architectures are only tested once every release.

[rene]

Care to explain which regression are you seeing? We try to cover all the supported architectures [1] and we take regressions quite seriously, so if you are seeing something that is broken please open a bugreport or contact the glibc developers at libc-alpha.



These interfaces from gnulib are abusing an internal implementation from a historical bad decision (libio.h) which we are trying to address (the libio.h is preventing us to move forward in a lot of places). We decided to stop providing libio.h as an external headers to avoid such internal ABI abuse (FILE is suppose to be an opaque type) and this is clearly an example which should be fixed by the application.

It was also fixed in gnulib upstream (it now check for __GNU_LIBRARY__), however it will require the project to actively update it.

I quoted the regression of a new bootstrap, all gnulib, obviously, a bit ironic, ;-) maybe time for new releases of those other core packages then, ... Certainly can't bootstrap further with all the core programs missing, ...

The main issue is, as GLIBC community, we usually lack infrastructure and manpower to continuously tests old hardware (sometimes even for newer). It ends which some platforms having better support than others. For SPARC, debian community provide me access to a T5 and later T1 machine and results looks ok for both 32 and 64 bits [1] (the issue on the youtube videos seems to be the old lack of unaligned support from SPARC with now and then hits the platform).

[1] https://sourceware.org/glibc/wiki/Release/2.28

I mentioned x86-64 crashes earlier, I just did not had a video about that, I fully understand the lack of sparc64 "testing", but that was the only mostly matching video at hand ;-) x86-64 videos are so boring, unless to assemble a new Ryzen 1.5 gen build: https://www.youtube.com/watch?v=jZNvj67PAEc

Even I only build sparc64 once a year, mostly also due to lack of faster hardware to use it on a daily basis, if someone wants to send an Ultra 45 my way I'm happy to run continuous integration testing ;-)

PS: https://bugzilla.redhat.com/show_bug.cgi?id=1595702

PPS: with breakage like this I always wonder (also already 2 decades ago w/ gcc-3.0, or glibc NPTL and such) why this is not orchestrated more perfectly. Is such API / ABI breakage is done, why are the GNU dependencies not updated first and new versions release, before pushing the glibc release, ..??!!

[rene]

i blame users of non-standard apis and people who are unable to use prebuilt distro packages

non standard APIs the Linux kernel and GNU introduced ? ;-) oh, ..! duh !1!!

[ZatrazZ]

Regressions in glibc also appear to be causing segfaults in Dying Light and Dead Island since last December (only when using Mesa). I cannot confirm this, as I don't have AMD or intel integrated graphics, but there is a 13-page thread on the issue:

https://www.gamingonlinux.com/forum/.../post_id=16449

The information provided is not clear it is a glibc regression, the reported stated it tested on different ubuntu and only with 16.04 (glibc 2.23) it worked. It hard to draw conclusions about it because not only glibc is different in the tested environments, but also all the other libraries. The information provided (a segfault in libc.so) is also inconclusive (it can be a wrong memcpy call which access invalid memory for instance). Taking in consideration that googling Dying Light returned a lot of hit where updates seemed to incurs a lot of issues, I also don't discard an issue with the port itself.

[ZatrazZ]

well, and plenty new regressions, ... glibc -2.27 was already mostly segfaulting for me on x86-64, I had to revert the upgrade in https://t2sde.org, while glibc-2.28 may not segfault as much anymore, it introduced plenty of base build regressions:

Care to explain which regression are you seeing? We try to cover all the supported architectures [1] and we take regressions quite seriously, so if you are seeing something that is broken please open a bugreport or contact the glibc developers at libc-alpha.

m4: freadahead.c "Please port gnulib freadahead.c to your platform"
gzip: fseterr.c "Please port gnulib fseterr.c to your platform"

These interfaces from gnulib are abusing an internal implementation from a historical bad decision (libio.h) which we are trying to address (the libio.h is preventing us to move forward in a lot of places). We decided to stop providing libio.h as an external headers to avoid such internal ABI abuse (FILE is suppose to be an opaque type) and this is clearly an example which should be fixed by the application.

It was also fixed in gnulib upstream (it now check for __GNU_LIBRARY__), however it will require the project to actively update it.

Will probably not get much further with such base stuff not building. Yes, patch might be trivial, but fun time when each release of base things breaks other base things, ..! https://www.youtube.com/watch?v=XYsKct4T2xk

PS: Breakage and ever changing libs and APIs are why we still do not have the year of the Linux desktop :-/

The main issue is, as GLIBC community, we usually lack infrastructure and manpower to continuously tests old hardware (sometimes even for newer). It ends which some platforms having better support than others. For SPARC, debian community provide me access to a T5 and later T1 machine and results looks ok for both 32 and 64 bits [1] (the issue on the youtube videos seems to be the old lack of unaligned support from SPARC with now and then hits the platform).

[1] https://sourceware.org/glibc/wiki/Release/2.28