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

[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, … :-/

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

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

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

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

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

Assuming the segfauts are unrelated to gnulib build issue, It sounds like a rant because you do not provide any useful information so someone could debug or check where the issues lies. I might be just something wrong in your build system for instance.

[rene]

Assuming the segfauts are unrelated to gnulib build issue, It sounds like a rant because you do not provide any useful information so someone could debug or check where the issues lies. I might be just something wrong in your build system for instance.

Some people focus on their snowflake safespace ranting terminology, others to solve actual problems. I not once said the segfaults are related to any gnulib compile issue, and specifically said the segfaults started with the previous 2.17. And yes, blame my "build system", maybe something is rather wrong with the make install not using atomic install / moves and instead overwrite an existing shared library while mapped in memory already – like I remember happing with some release nearly two decades ago.

Why do you even continue replying and accusing me of ranting, have you nothing more positive to do?

[ZatrazZ]

Some people focus on their snowflake safespace ranting terminology, others to solve actual problems. I not once said the segfaults are related to any gnulib compile issue, and specifically said the segfaults started with the previous 2.17. And yes, blame my "build system", maybe something is rather wrong with the make install not using atomic install / moves and instead overwrite an existing shared library while mapped in memory already – like I remember happing with some release nearly two decades ago.

Why do you even continue replying and accusing me of ranting, have you nothing more positive to do?

You explict stated the new 2.28 release brought new regression, linked a totally unrelated video with brfts issues on sparc and some links with outdated embedded gnulib code with abused the API constraint. When I asked to further information to actually check if your issue is a real one you dismiss me.

And I never stated it is an issue with your build system, I just suggest it might be (I actually never heard about it until now). And yes, installation on a living system is not supported (it is clear stated in FAQ [1]) and while I do agree it is not optimal, it is a hard problem to provide atomicity and no one has suggested a better alternative (patches are welcome).

Now I understand you frustration and I do not want minimize or dismiss as unimportant. However if you want to move foward and help us narrow down where the issue might be you will need also to change your tone. If you have time, please address with issue on libc-alpha with as much information as possible. There are developers, including myself, that would sincere try to help you there.

[1] https://sourceware.org/glibc/wiki/FA..._just_built.3F

[rene]

You explict stated the new 2.28 release brought new regression, linked a totally unrelated video with brfts issues on sparc and some links with outdated embedded gnulib code with abused the API constraint. When I asked to further information to actually check if your issue is a real one you dismiss me.

And I never stated it is an issue with your build system, I just suggest it might be (I actually never heard about it until now). And yes, installation on a living system is not supported (it is clear stated in FAQ [1]) and while I do agree it is not optimal, it is a hard problem to provide atomicity and no one has suggested a better alternative (patches are welcome).

Now I understand you frustration and I do not want minimize or dismiss as unimportant. However if you want to move foward and help us narrow down where the issue might be you will need also to change your tone. If you have time, please address with issue on libc-alpha with as much information as possible. There are developers, including myself, that would sincere try to help you there.

[1] https://sourceware.org/glibc/wiki/FA..._just_built.3F

Please stop putting this questionable negativity into my post that was not there. I quoted the 2.18 gnulib regressions in detail, and the quoted video shortly mentioned glibc-2.17 segfaults on sparc64. It is also not my fault that the GNU project's own gnulib used internal APIs for decades and this was neither fixed nor coordinated with new releases before the release of glibc-2.18.

I understand your frustration, but mine is not there. Stop shooting the messenger, I sit here in peace and harmony between my sparc64, ppc64 and mips64 and did neither ask for help nor was a I ranting. PS: another unrelated YT video to improve your Sunday mood: https://www.youtube.com/watch?v=_-MgF4YXl5Y

[ZatrazZ]

Please stop putting this questionable negativity into my post that was not there. I quoted the 2.18 gnulib regressions in detail, and the quoted video shortly mentioned glibc-2.17 segfaults on sparc64. It is also not my fault that the GNU project's own gnulib used internal APIs for decades and this was neither fixed nor coordinated with new releases before the release of glibc-2.18.

I understand your frustration, but mine is not there. Stop shooting the messenger, I sit here in peace and harmony between my sparc64, ppc64 and mips64 and did neither ask for help nor was a I ranting. PS: another unrelated YT video to improve your Sunday mood: https://www.youtube.com/watch?v=_-MgF4YXl5Y

And the gnulib issue is neither a glibc regression as I explain. Anyway fell free to open bug reports or approach us on mailing list if you find a regression or bug, I just kindly ask you to actually provide useful information instead of just bashing the project.