This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: functions statically linked on x86_64 while i386 uses glibc functions
- From: Jim Meyering <jim at meyering dot net>
- To: Andi Kleen <ak at suse dot de>
- Cc: bug-coreutils at gnu dot org, libc-alpha at sourceware dot org
- Date: Mon, 29 Jan 2007 10:52:05 +0100
- Subject: Re: functions statically linked on x86_64 while i386 uses glibc functions
- References: <200701290740.22303.ak@suse.de>
Andi Kleen <ak@suse.de> wrote:
> Hello,
>
> I was doing some binary size comparisons between -m32 and -m64 builds on x86_64
> Linux (SUSE 10.2 with gcc 4.1.2). This is the same build environment, same glibc, etc.
> just one configured for i386-linux and built with -m32 and the other for x86_64-linux
>
> One thing I noticed is that a few executable sizes differ widely:
>
> (.text sizes) 64bit 32bit
> ./src/csplit 95481 27704
> ./src/nl 87879 19551
> ./src/ptx 98316 28623
> ./src/expr 88373 20731
> ./src/tac 83726 15935
>
> The other differences are in the expected range of a few percent.
>
> On some investigation it looks like 64bit contains the regexpr functions and some
> other library functions, while the 32bit versions use the one from glibc.
> I assume that must be a (harmless) bug since the glibc version (2.5) is identical
> between 32bit and 64bit.
Hi Andi,
Thanks for reporting that. glibc-2.5's regex code probably still suffers
from the bug that makes it misbehave on 64-bit systems for strings
longer than 2^31 bytes. This has been fixed in gnulib's regex code since
glibc-2.3.5. So, coreutils works around it, along with any other project
that uses gnulib's regex module, by detecting the offending condition and
providing a working replacement. Here's the relevant part of m4/regex.m4:
/* Reject hosts whose regoff_t values are too narrow.
These include glibc 2.3.5 on hosts with 64-bit ptrdiff_t
and 32-bit int. */
if (sizeof (regoff_t) < sizeof (ptrdiff_t)
|| sizeof (regoff_t) < sizeof (ssize_t))
exit (1);
When that configure-run test program fails, those programs link with
the replacement regex functions from gnulib.
If you want to save space in those executables, and you don't think
there's a significant risk of malfunction[*], you can make coreutils
use the library code like this:
gl_cv_func_re_compile_pattern_working=yes ./configure
[*] Can you even get a 2GB-long string into expr?
I rarely use the regexp code in tac and nl, and use ptx even less
frequently. Personally, I'm not worried about csplit failing if/when
I run it on a file with such a long line -- I'll have other, more
immediate problems with the file, like getting that line into memory :)