Messages in this thread |  | | From | safemode <> | Subject | Re: 2 GB file limitation | Date | Sun, 30 Sep 2001 04:59:49 -0400 |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |