This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [Felipe Contreras <al593181@mail.mty.itesm.mx>] bug in useldt.h
- From: Greg Schafer <gschafer at zip dot com dot au>
- To: libc-alpha at sources dot redhat dot com
- Cc: Felipe Contreras <al593181 at mail dot mty dot itesm dot mx>,Andreas Jaeger <aj at suse dot de>, Ulrich Drepper <drepper at redhat dot com>
- Date: Sat, 8 Dec 2001 19:10:51 +1100
- Subject: Re: [Felipe Contreras <al593181@mail.mty.itesm.mx>] bug in useldt.h
Hello
Andreas Jaeger <aj@suse.de> writes:
> I can't reproduce this with current CVS sources. Can anybody else
> reproduce this or has anybody an idea what might be the problem?
I have managed to figure out the sequence of events that can
reproduce this problem.
In summary, the bug only occurs if you install glibc on a
completely blank system ie: glibc is not installed yet. If you
install glibc when an existing glibc is already in place, the
bug does not surface and everything works as expected.
This snippet of code from "linuxthreads/sysdeps/i386/i686/pt-machine.h"
#if __ASSUME_LDT_WORKS > 0
#include "../useldt.h"
#endif
(which is only activated by passing --enable-kernel=2.3.99 and greater
to ./configure) seems to get mis-compiled in the first instance.
I suspect it is something to do with ./configure finding different
results depending on whether you have a glibc installed or not.
Example diffs of glibc-build dir:
from "glibc-build/config.h"
-/* #undef HAVE_ASM_SET_DIRECTIVE */
+#define HAVE_ASM_SET_DIRECTIVE 1
and this from "glibc-build/config.make"
-have-z-nodelete = no
-have-z-nodlopen = no
-have-z-initfirst = no
+have-z-nodelete = yes
+have-z-nodlopen = yes
+have-z-initfirst = yes
-sizeof-long-double = 0
+sizeof-long-double = 12
I'm yet to determine exactly which one of these differnces causes the problem.
I suppose some sed hacks could be used to work around the problem (for us folk
who want to install from scratch).
Any thoughts?
Regards
Greg