Qmail, Daemontools and djbDNS assumes that "errno" can be defined as "extern int errno;". This is a broken assertion. When Glibc 2.3.2pre1 is emerged, all DJB software immediately stop working. And compilation doesn't work any more, because "errno" is no more defined as a global symbol. Fix : add patches for all DJB software to #include <errno.h> and remove "extern int errno" Reproducible: Always Steps to Reproduce: 1. 2. 3.
dosfstools breaks too ... az: shall we just handle this on a case by case basis ?
*** Bug 16344 has been marked as a duplicate of this bug. ***
*** Bug 16355 has been marked as a duplicate of this bug. ***
glimpse (4.15) ebuild also fails with 'undefined reference to errno'.
daemontools is also broken ...
in light of these issues, imo this version of glibc should be masked asap ... any thought on how it'll affect binary packages ? we can patch source code of programs but we cant really patch binary packages (vmware) ...
Created attachment 8716 [details, diff] Fix errno (djbdns) Fix use of errno by including errno.h
Created attachment 8717 [details, diff] Fix ebuild (djbdns) Apply errno patch, minor spacing cleanup
Note that the above patches will NOT break building under older glibc versions.
Created attachment 8719 [details, diff] Patch to make glimpse compile with new glibc Attached patch makes glimpse compile with new glibc 2.3.2pre1
Created attachment 8720 [details] New ebuild for glimpse that uses errno patch Attached ebuild uses errno.diff to patch glimpse to compile with new glibc 2.3.2pre1
*** Bug 16370 has been marked as a duplicate of this bug. ***
Yep, havent looked at this yet, but we will have to handle it case by case. Basically a problem that you need to include errno.h, and not declare errno external. I already added patches to net-nds/portmap and x11-misc/xloadimage at the beginning of the year when I did some testing on glibc-2.3.2 cvs.
that is fine but what about binary only packages ? vmware breaks with the new glibc
also, i still maintain that the new glibc should be masked due to the sheer volume of broken ebuilds ... yes we patch them, but we do it on developer boxes and not let the users experience this too
Ok, I thought ~ was for developers, and users that *wanted to help test* developmental stuff ?
yes, ~ is for testing/development, but package.mask is for broken (which is what this is)
I am sorry, but the glibc developers do not consider this as broken. It will be the same in 2.3.2 official, and following versions. And this is what '~' if for .. we fix things now for when 2.3.2 is officially out. Do you want this chaos when 2.3.2 is actually out ?
i wasnt suggesting we mask it now and forever ... i was suggesting we package.mask it and then on our own dev boxes we try to emerge and patch as many packages as possible ... you can tell there are, and will be, plenty of packages that break ... then, we patched a large number of ebuild's, we release it to ~ and let all the other random users report the packages we missed ... however, we still need some kind of solution for older binary only packages ... even if it's like hacking something into lib-compat ...
*** Bug 16396 has been marked as a duplicate of this bug. ***
There is a hack available for vmware. It is described in in vmware.for-linux.experimental which I am copying below. It works for me with the caveat that for non root users, LD_PRELOAD clears suid. vmware needs suid access to /dev/misc/vmmon and /dev/tty0 and /dev/tty7(tty on which current X is running). I had to change the permissions on these to a+rw for vmware to run as non-root. It will complain about /dev/tty8 and not having permission to run full-screen. However changing permissions on tty8 does not seem to work. I don't rung full-screen, so not an issue for me, but may be problems for others. From researching on the web, I believe it is correct for LD_PRELOAD to clear suid. vmware-ui and vmware-mks have suid propagated to them from vmware. However the LD_PRELOAD, breaks the chain. I don't know what problems can be created by changing the permissions on the tty0 and tty7. So far I haven't seen any. But I am on a non-secure workstation. If security is important, this might be an issue. Hopefully vmware will release a patch sometime soon, as redhat 8.1 I believe will require that. Otherwise they might just move people to version 4.0 which is in beta now. Naren ------------------------------------------------ In the interest of posterity (and helping anyone else using vmware with rawhide glibc), here's what ended up working. Compile the attached file q.c into q.so. Put q.so into /usr/lib/, and chmod it 555. Then rename the files /usr/lib/vmware/bin/vmware-{ui,mks}, giving them a ".bin" extension. Then create two new files named /usr/lib/vmware/bin/vmware-{ui,mks} instead that contain: ------------------- #!/bin/bash LD_PRELOAD=q.so exec "$0.bin" "$@" ------------------- chmod a+rx these new files, and all should be well. The basic problem is that vmware binaries have their own copy of errno and related functions, and there is a clash with the new glibc ones. q.so will resolve this problem. The need for the scripts above arises from the fact that each of the binaries launched by the initial /usr/bin/vmware call needs to have the q.so preloaded. q.c was written by Petr Vendrovec, and many thanks go to him for the work he put into the debugging of the problem and the attached code! In summary, q.c qorreqts the formerly inqurable qrashes. Cheers, -- Ami Fischman usenet@fischman.org ------------------------------------------------------- /* * Build with: gcc -W -Wall -shared -o q.so q.c */ #include <dlfcn.h> #include <sys/mman.h> #include <stdlib.h> #include <stdio.h> void go(void) __attribute__((constructor)); void go(void) { void* qh; unsigned char *__real_errno_location, *__vm_errno_location; qh = dlopen("libc.so.6", RTLD_GLOBAL); __real_errno_location = dlsym(qh, "__errno_location"); __vm_errno_location = dlsym(NULL, "__errno_location"); printf("Got eroloc %p & %p\n", __vm_errno_location, __real_errno_location); if (__real_errno_location && __vm_errno_location && __real_errno_location != __vm_errno_location) { unsigned int errnobase = (int)__vm_errno_location; unsigned int mpbase = errnobase & ~0xFFF; unsigned int mplen = 4096; if (errnobase + 5 > mpbase + mplen) { mplen = mplen + 4096; } mprotect((void*)mpbase, mplen, PROT_READ|PROT_WRITE|PROT_EXEC); *__vm_errno_location = 0xE9; *(int*)(__vm_errno_location + 1) = __real_errno_location - __vm_errno_location - 5; mprotect((void*)mpbase, mplen, PROT_READ|PROT_EXEC); } } ----------------------------------
Another comment. There is an ongoing discussion on the wine lists as to how to solve this. This is a problem for wine. So wine will not work at this time, and the last I know there is no real solution for this yet. The same is true for the mono compiler and tools. There are issues there, and the wine and mono teams are trying to figure out a solutions. look at the following for more information. http://www.winehq.com/news/?view=155#Threading%20Problems%20with%20glibc%202.3
*** Bug 16420 has been marked as a duplicate of this bug. ***
Idea: Is it feasible to create an eclass that would facilitate fixing source files, changing "extern int errno;" to "#include <errno.h>" during the src_unpack stage? i.e. # grep pattern intentionally loose find ${S} -type f -name '*.[ch]' | xargs grep -l errno | while read f; do einfo "Fixing errno usage in ${f}" mv ${f} ${f}.orig # why are sed regexes so lame? perl -p -e 's|(extern\W+int\W+errno\W*;)|/* \1 */\n#include <errno.h>\n|;' \ <${f}.orig >${f} done Then the ebuilds of packages with problems just need to inherit fix_errno (or whatever) and we don't need a bazillion patches everywhere. I've tested the above script on qmail and it works correctly. I think it will work on the majority of cases. BTW, looks like mysql is another app that breaks with glibc-2.3.2. (I only tried 4.0.11a, but certainly older versions are affected as well.)
well, in addition to fixing it, we should be talking to upstream maintainers about this bug
glimpse fixed in cvs http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-x86/app-misc/glimpse/glimpse-4.15-r1.ebuild?rev=1.1&content-type=text/vnd.viewcvs-markup http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-x86/app-misc/glimpse/files/4.15-errno.patch?rev=1.1&content-type=text/vnd.viewcvs-markup
kerberos5 1.2.7 is also affected by the glibc bug. I tried to ship around with -DHAVE_ERRNO_AS_DEFINE=1 but it didn't work. I submited a seperate bug for kerberos5 1.2.7 itself
The Intel Fortran Compiler, ifc, is also broken by this. Presumably also their C Compiler, icc.
The intel c/c++ compiler icc & icpc Version 7.0 Build 20030212Z works without any problems on glibc 2.3.2. I have built an internal project on this and it is running with no bugs so far.
Another package affected by this is ezm3, needed to compile cvsup.
any updates on the wine situation?
The last I read, for wine they are still working on a solution. The reason for the delay is the intent to also fix the threading model which is definitely more work. So for now, people needing wine should not upgrade glibc.
fix: while OOo is extracting add this line: #include <errno.h> to this file: /var/tmp/portage/openoffice-1.0.2/work/oo_1.0.2_src/dmake/extern.h
^ for openoffice that is. fixes the dmake error
Right, we should just replace all declarations of errno with '#include <errno.h>'. What binary packages except for WineX (the one you pay for), and VMWare are affected ?
Sorry but please explain this to me... How come glibc developers don't consider this broken? There is appearently a change in 2.3.2 that breaks a majority of apps even if they are compiled with the latest gnu compiler... but seam to work some none-gnu ones... Then this must be a gcc bug then really or? To me keep on adding patches to apps making them work seam to be a temporary solution not THE solution?
Its rather simple: all programs that was coded like so: ------------ broken code ---------------- extern int errno; ----------------------------------------- breaks. The right way (and why the glibc devs do not really bother), is to include errno.h like so: ------------- the right way -------------- #include <errno.h> ------------------------------------------ System header files is there for a reason, and doing things like declaring 'errno' as an 'extern int' when the proper system header do exist, is just wrong (or in the glibc devs's books).
Crossover 1.2 is affected, I believe 1.3 suffers from the problem as well.
Fixed krb5-1.2.7 ebuild with a construct like in comment 24.
libmpeg3-1.5-r1 also has this problem.
what about the wine thing? could wie just replace the wrong errno things in code? or any other fix?
Got a quick fix for wine* from irc: 'export LD_ASSUME_KERNEL=2.2.5' before you run wine. Thanks to taviso in #gentoo. The related url is: http://www.winehq.com/index.php?issue=163#Making%20Wine%20Run%20With%20glibc%202.3 -phoen][x-
Ok, I was a bit busy, but I'll try now to get to everything. Could you guys add a bug for all packages that is affected by this? I can then start sorting them out. NOTE: please add a *new* bug, with me as owner.
*** Bug 16406 has been marked as a duplicate of this bug. ***
In xloadimage, I had to add: #include <errno.h> to the top of img.c in order for it to compile as well.
app-games/mindless-1.2 as well (needed to include errno.h in http_fetcher.c)
glibc-2.3.2 is marked stable, all packages are out w/errno fixes, and we should be good to go :) nice work all
*** Bug 22248 has been marked as a duplicate of this bug. ***
