[Felipe Contreras <al593181@mail.mty.itesm.mx>] bug in useldt.h
Felipe Contreras
al593181@mail.mty.itesm.mx
Mon Dec 10 20:12:00 GMT 2001
On Fri, Dec 07, 2001 at 02:50:38PM +0100, Andreas Jaeger wrote:
> Felipe reports:
> > The program that failed: int main() { return 0; }
> >
> > Compiled with: gcc tmp.c -o tmp -lpthread
>
> He's using a selfcompiled glibc that and using the i686 LDT thread
> implementation.
>
> 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've found the problem, it only happends when you are building a system
and there is no glibc allredy installed (cleanly, a la LFS). As Greg
mentioned only few things change:
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
(^--I am pretty sure one of theese is the cause)
-sizeof-long-double = 0
+sizeof-long-double = 12
config.h
-/* #undef HAVE_ASM_SET_DIRECTIVE */
+#define HAVE_ASM_SET_DIRECTIVE 1
This is the cause:
...
configure:2800: checking for -z nodelete option
configure:2807: gcc -shared -o conftest.so conftest.c -Wl,--enable-new-dtags,-z,nodelete 1>&5
/static/usr/bin/ld: cannot open crti.o: No such file or directory
collect2: ld returned 1 exit status
...
Errors like this one goes on and on.
If you ask me it is a bad idea to think that glibc is installed in order
in install properly glibc. Imagine a system were you have all the tools,
compiled statically, but no glibc, glibc should compile properly, and
the configure script should now have the errors as the one metioned
above. I know it is hard to do that, but there must be a way, and it
will be the right way.
More information about the Libc-alpha
mailing list