Originally posted by ZatrazZ
View Post
Announcement
Collapse
No announcement yet.
Glibc 2.28 Released With Unicode 11.0 Support, Statx & Intel Improvements
Collapse
X
-
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!
Comment
-
Originally posted by rene View Post
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, … :-/
- Likes 1
Comment
-
Originally posted by rene View PostSo 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!
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.
- Likes 2
Comment
-
Originally posted by ZatrazZ View Post
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.
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, ..!Last edited by rene; 04 August 2018, 04:59 AM.
Comment
-
Originally posted by rene View Post
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, ..!
- Likes 1
Comment
-
Originally posted by ZatrazZ View Post
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.
Why do you even continue replying and accusing me of ranting, have you nothing more positive to do?
Comment
-
Originally posted by rene View Post
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?
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.3FLast edited by ZatrazZ; 04 August 2018, 09:07 PM.
- Likes 2
Comment
-
Originally posted by ZatrazZ View Post
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
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
Comment
-
Originally posted by rene View Post
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
- Likes 1
Comment
Comment