This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: PATCH: Fix struct stat [__USE_FILE_OFFSET64] in sysdeps/unix/sysv/linux/bits/stat.h
- From: Uwe Reimann <libc-alpha at pulsar dot homelinux dot net>
- To: libc-alpha at sources dot redhat dot com
- Cc: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Date: Wed, 04 Jun 2003 13:11:39 +0200
- Subject: Re: PATCH: Fix struct stat [__USE_FILE_OFFSET64] in sysdeps/unix/sysv/linux/bits/stat.h
- References: <200306031011.h53ABEX4016645@ignucius.se.axis.com>
Hi,
Hans-Peter Nilsson wrote:
Hi.
>
This bug is visible for programs compiled with
-D_FILE_OFFSET_BITS=64 on platforms where the ABI says there is
no alignment-padding between structure elements. AFAIK only
cris-axis-linux-gnu matches that description. The bug causes
struct stat and struct stat64 to have different layout. To
repeat, compile GNU awk (3.1.1 specifically) on a
cris-axis-linux-gnu platform. Boom; "gawk: fatal error:
internal error" even with just "gawk --help". Reportedly ls
(from fileutils?) is also built with _FILE_OFFSET_BITS 64 by
default; the bug "only" causes erroneous output there.
User-level workaround: don't compile programs with
-D_FILE_OFFSET_BITS=64 (usually translates to: configure
programs with --disable-largefile).
The patch fixed the problem with ls (which is from fileutils-4.1.11).
Thanks for that.
However, I am still having a problem with bash-2.05b with glibc-2.3.1 on
cris. When invoking configure for fileutils-4.1.11 I get the following
error (this is done on cris):
./configure: line 1: Generated: command not found
./configure: line 399: syntax error near unexpected token `then'
./configure: line 399: `$ac_unique_file; then'
The first three lines from configure look like that:
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.53b for GNU fileutils 4.1.11.
So, it looks like bash (or glibc) starts to read at column 2 in the
third line.
This happens with both, the bash binary I was using until now, which is
compiled against cris-dist-glibc-1.25, or a new binary compiled against
a patched glibc-2.3.1 (no difference between a static or shared one).
This might not be glibc related. But as bash works with
cris-dist-glibc-1.25, I think it is.
Any ideas?
Best regards, Uwe