Yesterday glibc was released in great secret. This version requires gcc 3.2 and contains many speed enchancements. Since then I have tried the existing glibc ebuild on it without the patches. The package compiles without problems but "make check" throws errors in maths/test-float. This is probably due to my CFLAGS (which worked in the last glibc version), will retry tomorrow with defaults and isolate the error. Will then attempt to make a glibc-2.3 system with all the old support (nvidia etc.) Will keep you posted. Stefan Jones (Cretin on IRC #gentoo)
Created attachment 4424 [details] A version to test if you are mad! Will only work with getoo-1.4, needs gcc-3.2 and binutils-2.13.90.0.4 This compiles and "make checks" ok Some floating point gcc flags are known to break it. All x86 patches have been removed as they are now in the offical tarball, except for reiserfs timeout test (not sure if needed tho) The atime test was stopped as it fails if filesystem mounted with "noatime". Will now install and try to bootstrap with it.
The posted ebuild works fine as far as I can see, I upgraded my default 1.4 system which has the default gentoo kernel The floating point tests failed again, due to agressive optimisations, but the error are not the serious, relative maths errors of about 0.00001% and different handeling of infinity (in divide by zero errors) Either filter the flags or add "touch math/test-float.out" in src_compile with the other touch command to disable the test. PS. ebuild doesn't fail on test errors, easy to change. Stefan Jones
The last two known issues, and then its done: gcc-3.2 doesn't compile under glibc-2.3, it needs a small patch to do so. See point 2.37 in the glibc FAQ, plz add to next gcc revision Some *.a /archive files on the system need to be recompiled as some don't link when you try and use them, symbol mismatches. Python and ncurses so far. Cretin heads off to the next project .....
Created attachment 4458 [details] gcc which builds with glibc-2.3 installed This is the standard gcc ebuild plus two pre-glibc-2.3 safe patches which allows gcc to be built with glibc-2.3 installed.
*** Bug 8941 has been marked as a duplicate of this bug. ***
Sorry, didn't find that bug because I actually looked for glibc 3.2.
glibc 2.3.1 is out, what about it ;D
In response to question and 2.3.1: I have sucessfully installed 2.3.1 using the above ebuild. The release version increase was only to fix a few bugs in the case of people who restrict the stack size for user processes, not many people do on desktop computers. I have had no problems so far, and the above features still apply, of course! Stefan (Cretin)
Hi, I am just interested, do you have done some performance tests (benchmarks) with the new glibc 2.3x (how are the results in comparison to the old system)? Regards Georg Sauthoff
Just a note.. I wasn't able to download the attachments to test out these ebuilds. If someone could post em as a message or change the mimetype to text or something, it'd be appreciated.
Created attachment 4826 [details] glibc-portage.tbz2 This is the ebuild for glibc 2.3.1, with a more sensible attachment name!
Created attachment 4827 [details] gcc-portage.tbz2 Another tar.bz2 file which contains the gcc ebuild and patches
glibc 2.3.1 introduces some incompatibilities were unwanted stuff got cut out. Static libraries are the victim of some old unwanted glibc 2.2.x behaviour that didn't make it into glibc 2.3.1 This causes all the undefined __ctype_b and such errors. Apparently there is a workaround: http://lists.debian.org/debian-glibc/2002/debian-glibc-200210/msg00093.html Someone more knowledgeable than me should definitely check it out. Red Hat 8.0 implements this workaround, but it might still cause unwanted side-effects. This might cause a lot of binaries to break if not applied. Ugh.
Created attachment 4991 [details] glibc-2.3.1-r1.tar.bz2 I made a patch and updated the ebuild according the link posted. I haven't had a chance to test it at all. This isn't a fix anyway, but it's at least a temporary workaround if it does in fact fix the problem.
Created attachment 4995 [details] glibc-2.3.1-r1.tar.bz2 sorry, uploaded the wrong file, this one should work.
Added a -r1, thanks.
Sorry for the double-posting... When I added my name to the CC list, I inadvertendly still had the text in the comments box... Dowp. Going back to the static .a borken question, after the patch, my system works perfectly. Basically my system worked perfectly BEFORE the patch except for Sun Java (which I built from scratch) and used a .a library for Motif. If someone can figure out how to use the OpenMotif installation in stead of Sun's provided Motif, I can say that the .a issue is a non-issue for me. Fact is, binary compatibility is a hard thing to maintain and that means that some errors or unwanted behaviour needs to be supported for a while. Ugh. Is there any other cases of borken binary-only static libs that anyone knows of? As a matter of fact, I haven't checked ICC yet without the patch.
Created attachment 5205 [details] glibc 2.3.1 ebuild with fixed __libc_wait This attachment is a fixed ebuild for glibc-2.3.1 that allows the export of __libc_wait which some binary-only apps need.
Another binary compatible feature glibc 2.3.1 enforces is that some symbols that were private are now bloody well private. Sun Java 1.3.1 used the unsupported internal symbol __libc_wait and now doesn't work. The trail led to: http://sources.redhat.com/ml/libc-alpha/2002-04/msg00143.html JDK 1.4.0 and higher doesn't do this naughty thing and therefore works. Unfortunately, some apps DO require JDK 1.3.1 specifically (notably postgresql). GLIBC will not support this patch to mainstream (to stop people from being naughty again), but since it won't break anything except badly (VERY badly) designed code, I think it's safe to apply until JDK 1.3.1 is phased out... Attaching an ebuild too, I think...
Done, thanks.
