mmap stdio breaks GNU ld

[Bruno Haible <haible at ilog dot fr>]

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.