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

[phoronix]

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

Glibc 2.28, the latest update to the GNU C Library, is now available to start off the month of August...

http://www.phoronix.com/scan.php?pag...-2.28-Released

[cl333r]

Will Fedora 29 ship with Glibc 2.28? If so one can use statx OOTB?

[rene]

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:

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

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 :-/
PPS: you can add coreutils to the list: !> lib/fseterr.c:78:3: error: #error "Please port gnulib fseterr.c to your pl ..

[lectrode]

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

[pal666]

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

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

[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

[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.

[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!!

[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, ..??!!

[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.