Re: 2 GB file limitation

[safemode <safemode@speakeasy.net>]

On Sunday 30 September 2001 04:23, Gábor Lénárt wrote:
> On Sat, Sep 29, 2001 at 03:51:53PM +0200, Luigi Genoni wrote:
> > > > ?? slackware 8 has large file support (I've been useing it for a
> > > > while now)
> > >
> > > I think you can get >2GB support if you've Gcc 3.0. Even with the
> > > latest

It's already been posted that the compiler used isn't the issue. You dont 
have to recompile libc with gcc 3.x to get large file support, you just 
enable the non-standard option and compile libc. 

> > ???
> > I am using it and I am using gcc 2.95.3 for normal things,
> > and to compiled my kernel and my libc, because gcc
> > 3.0.1 produces slower binaries on my Athlons (yes, with athlon
> > optimizzations turned on), at less for my programs, and it is better to
> > avoid it for glibc compilation because of back compatibility issues.
>
> Yes, gcc3 is (well at least NOW) a piece of shit. It produces BIGGER and
> SLOWER binaries ... Checked on: Athlon, AMD K6-2.
> With the same gcc command line ...

gcc 3.0.2 produces lame binaries that are 45 seconds faster encoding 
74minutes of audio than the gcc 2.95.4 binaries with the same cflags.   
gcc 2.95.4 produces a binary of 39432 bytes when gcc 3.0.2 with the same 
flags on the same source produces a binary of 37452 bytes.  I then tested it 
with lame.  gcc 2.95.4 produced a binary of 245664 bytes and 3.0.2 produced 
one of 238016 bytes.  Same exact cflags and settings. 
So basically my testing absolutely contradicts your statement.  So who is 
right? 

gcc performance all depends on the code being used, no matter what version 
and both completely on the CFLAGS being used.  Which is why compileable 
benchmarks are so unreliable etc etc.  So enough of the compiler trashing and 
just use whatever makes you happy.  Recompile the entire system with 3.x if 
you want. The backwards incompatibility is not something new to 3.x, it's 
something indicative to gcc throughout it's history.