Bugzilla Bug 16267

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 an attachment (id=8716) [details]
Fix errno

Fix use of errno by including errno.h

Created an attachment (id=8717) [details]
Fix ebuild 

Apply errno patch, minor spacing cleanup

Note that the above patches will NOT break building under older glibc versions.

Created an attachment (id=8719) [details]
Patch to make glimpse compile with new glibc

Attached patch makes glimpse compile with new glibc 2.3.2pre1

Created an attachment (id=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

*** Bug 16355 has been marked as a duplicate of this bug. ***

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