Shawn wrote: > On Fri, 2003-07-25 at 02:21, Terry Lambert wrote: > > You probably can't get away with the old gcc, since the binary > > format changed For No Good Reason(tm). > > Didn't the GNU people say they had to change it to be more ABI compliant > with the 'standard'?
I will believe that when they upgrade their FORTRAN compiler to be more compliant with 'the standard'. Some standards are not worth complying with; I still have yet to see anyone tell me exactly what the practical benefit of doing this is. It's like the ELF standard instead of a.out; I was very much in favor of the change-over because it was supposed to let us have section attribution and multiple text and data segements that got loaded in the same executable. Is your FreeBSD kernel capable of defragging kernel memory to permit large contiguaous allocations for a device driver like the BT848 to happen well after boot time? Mine isn't. Is your FreeBSD kernel capable of dicarding the code and data for the probe routines that are not currently being executed and are not used in the common operational case? Mine isn't. Is your FreeBSD kernel capable of paging out any kernel page that's not in the paging path, so that if you, for example, have sound hardware and aren't using your sound driver, you have the ability to use the physical memory to instead open more sockets? Mine isn't. Is your FreeBSD kernel capable of loading *only* the probe code for a device, and, if it doesn't probe as being there, never loading the rest of the device driver and cotributing to KVA fragmentation? Mine isn't. Does your system have a libc.so linked against a libresolv.so that's totally seperate so that you can pull in new libraries from ISC whenever you need to do that the name lookups aren't serialized and make your Netscape slow? Mine doesn't. Is your entire system linked shared? Well, mine is. 8-). But it was under a.out, too. ELF promised a lot of things that never ended up having any practical value beyond what we already had with a.out, which was one BSS, one TEXT, and one DATA: just like before ELF. So what exactly is being promised by "being more standards compliant" in this particular instance? I can tell you what isn't: binaries are larger and compilation is slower than in previous releases; keeping up with GCC feels like running further and deeper into a swamp filled with molasses. Yeah, it's nice that we support 64 bit architectures (sorta) now, but that particular feature didn't need the binary format changed. Does anyone else ever suspect that some standards are written to cripple your competition, if they are stupid enough to fully comply with them? -- Terry _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"