This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
mmap stdio breaks GNU ld
- From: Bruno Haible <haible at ilog dot fr>
- To: libc-alpha at sources dot redhat dot com
- Date: Fri, 18 Jan 2002 23:54:20 +0100 (CET)
- Subject: mmap stdio breaks GNU ld
Hi,
After installing glibc-2002-01-15, gcc cannot create programs any more,
because the linker /usr/bin/ld has trouble with the new mmap based
stdio behaviour.
$ cat /tmp/test-prg14062.c
#include <stdio.h>
#include <stdlib.h>
int main(void) {
printf ("Your new glibc installation seems to be ok.\n");
exit (0);
}
$ gcc /tmp/test-prg14062.c
/usr/lib/crt1.o: In function `_start':
/usr/lib/crt1.o(.text+0x1d): undefined reference to `__libc_start_main'
/tmp/cckFOSKm.o: In function `main':
/tmp/cckFOSKm.o(.text+0xf): undefined reference to `printf'
/tmp/cckFOSKm.o(.text+0x1c): undefined reference to `exit'
collect2: ld returned 1 exit status
$ gcc -c /tmp/test-prg14062.c -o /tmp/test-prg14062.o
$ /usr/bin/ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o /tmp/test-prg14062 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i486-suse-linux/2.95.3/crtbegin.o -L/usr/lib/gcc-lib/i486-suse-linux/2.95.3 -L/usr/i486-suse-linux/lib /tmp/test-prg14062.o /usr/lib/libc.so -lgcc /usr/lib/libc.so -lgcc /usr/lib/gcc-lib/i486-suse-linux/2.95.3/crtend.o /usr/lib/crtn.o
/usr/lib/crt1.o: In function `_start':
/usr/lib/crt1.o(.text+0x1d): undefined reference to `__libc_start_main'
/tmp/test-prg14062.o: In function `main':
/tmp/test-prg14062.o(.text+0xf): undefined reference to `printf'
/tmp/test-prg14062.o(.text+0x1c): undefined reference to `exit'
"ld" appears to ignore the contents of /usr/lib/libc.so.
$ cat /usr/lib/libc.so
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
By using ltrace I could isolate it in a small test program:
$ cat iotest.c
#include <stdio.h>
int main ()
{
FILE *fp = fopen("/usr/lib/libc.so", "r");
char buf[8192];
printf ("%p\n", fp);
printf ("%d\n", isatty (fileno (fp)));
printf ("%d\n", read (fileno (fp), buf, 8192));
printf ("%d\n", isatty (fileno (fp)));
return 0;
}
On a glibc-2.1 system, this program produces the output
0x8049898
0
178
0
On a glibc-2002-01-15 system, it produces
0x8049708
0
0
0
I.e. 'fileno' has become useless because the file pointer
is positioned at the end of the file right after opening it.
In ld, the fopen call has the following backtrace:
fopen
try_open
ldfile_find_command_file
ldfile_open_command_file
load_symbols
open_input_bfds
lang_process
main
the isatty + fileno call has the following backtrace:
fileno
yy_init_buffer
yy_create_buffer
lex_push_file
ldfile_open_command_file
load_symbols
open_input_bfds
lang_process
main
and the read + fileno call has the following backtrace:
fileno
yy_input
yy_get_next_buffer
yylex
yyparse
load_symbols
open_input_bfds
lang_process
main
i.e. it actually comes from flex. The problem is therefore likely
not limited to ld, but applies to many applications that use flex.
System: Linux 2.4.10 on i686.