Re: [Cooker] gcc 2.96 - statement of intent, please?
Heheh, here we go again. On Friday 23 February 2001 08:01, you wrote: http://gcc.gnu.org/gcc-2.96.html While I understand that the cooker's generally considered "alpha" code, many of us see it as the precursor to the next release - are you planning on releasing Mandrake 8.0 it with gcc 2.96, clearly against the developer's specific advice (as in the above URL)? I really want to try this out, but I can't see doing so with the current libstdc++ locked into so many rpm's at the 2.96 code base. I've seen a few other posts go by Thanks in advance for responding - Gio Content-Type: text/html; charset="iso-8859-1"; name="Attachment: 1" Content-Transfer-Encoding: quoted-printable Content-Description: -- Jason Straight
Re: [Cooker] gcc 2.96 - statement of intent, please?
I have to wonder what's going to happen here myself - I was told that gnome 1.4 (due in march) wouldn't be done in time to make it into 8.0. So I am guessing that at the very least cooker will freeze before then. If that's the case then gnome can't be rebuilt and tested in time for release then surely an entire rebuild of the distro with a new compiler (if 3.0 is even ready) is out of the question. So one would assume that it is Mandrakes full intent to release 8.0 with gcc 2.96 snapshot? Is this the fact? What is Mandrakes stance on this, if so? How is it justified? If Mandrake has other plans than using a compiler snapshot, what are they? On Friday 23 February 2001 08:01, you wrote: http://gcc.gnu.org/gcc-2.96.html While I understand that the cooker's generally considered "alpha" code, many of us see it as the precursor to the next release - are you planning on releasing Mandrake 8.0 it with gcc 2.96, clearly against the developer's specific advice (as in the above URL)? I really want to try this out, but I can't see doing so with the current libstdc++ locked into so many rpm's at the 2.96 code base. I've seen a few other posts go by Thanks in advance for responding - Gio Content-Type: text/html; charset="iso-8859-1"; name="Attachment: 1" Content-Transfer-Encoding: quoted-printable Content-Description: -- Jason Straight
Re: [Cooker] gcc 2.96 - statement of intent, please?
On 02.23 Paul Giordano wrote: http://gcc.gnu.org/gcc-2.96.html While I understand that the cooker's generally considered "alpha" code, many of us see it as the precursor to the next release - are you planning on releasing Mandrake 8.0 it with gcc 2.96, clearly against the developer's specific advice (as in the above URL)? I really want to try this out, but I can't see doing so with the current libstdc++ locked into so many rpm's at the 2.96 code base. Don't look at the nowadays gcc-2.96 in cooker like the initial alpha snapshot. It is closer to the 3.0 snapshots. gcc-2.96 has many changes that make it generate much better code than any gcc before, AFAIK. And to be more correct and efficient, especially g++. The problem was that when RedHat and Mdk took the source snapshot to ship gcc-2.96 the optimizer was very broken in certain silly things. But with the level of patching it has suffered since then, it is really near a real compiler. I have been building kernels with it since 2.2.18 - 2.3.x and now it compiles perfectly my 2.4.2-ac3. It does not imply that there was still some obscure driver used not so often which can still trigger some gcc bug (and many of that 'bugs' are not bugs, but badly written code relaying on gcc doing low level things in a certain way you should not suppose, like guessing which alignment the compiler is going to do inside a struct, how will it pad the struct, and so on). In my oppinion (I also cried 'how can they ship that') using 2.96, even in alpha or beta stage, has helped to clean much code. -- J.A. Magallon $ cd pub mailto:[EMAIL PROTECTED] $ more beer Linux werewolf 2.4.2-ac1 #2 SMP Fri Feb 23 02:34:42 CET 2001 i686
Re: [Cooker] gcc 2.96 - statement of intent, please?
I'm more concerned about the problems that might arise simply because the packages in the distro were built with it. What problems that may occur, if one get's into the habbit of making binary incompatible packages at every distro release it kind of renders the whole idea of rpm useless. There will be rpm's for i386 using glibc 2.1 with gcc2.96, 2.2 with gcc 2.96, 2.2 with 2.96 and 2.2 with gcc 3.0 eventually. May as well just figure on using source for everything. While I personally use source for 99% of my software that doesn't come with a distro this isn't really a problem, but it's a nighmare for uninitiated users. It's even more of a mess than the differences between different versions of windows. On Friday 23 February 2001 18:04, you wrote: On 02.23 Paul Giordano wrote: http://gcc.gnu.org/gcc-2.96.html While I understand that the cooker's generally considered "alpha" code, many of us see it as the precursor to the next release - are you planning on releasing Mandrake 8.0 it with gcc 2.96, clearly against the developer's specific advice (as in the above URL)? I really want to try this out, but I can't see doing so with the current libstdc++ locked into so many rpm's at the 2.96 code base. Don't look at the nowadays gcc-2.96 in cooker like the initial alpha snapshot. It is closer to the 3.0 snapshots. gcc-2.96 has many changes that make it generate much better code than any gcc before, AFAIK. And to be more correct and efficient, especially g++. The problem was that when RedHat and Mdk took the source snapshot to ship gcc-2.96 the optimizer was very broken in certain silly things. But with the level of patching it has suffered since then, it is really near a real compiler. I have been building kernels with it since 2.2.18 - 2.3.x and now it compiles perfectly my 2.4.2-ac3. It does not imply that there was still some obscure driver used not so often which can still trigger some gcc bug (and many of that 'bugs' are not bugs, but badly written code relaying on gcc doing low level things in a certain way you should not suppose, like guessing which alignment the compiler is going to do inside a struct, how will it pad the struct, and so on). In my oppinion (I also cried 'how can they ship that') using 2.96, even in alpha or beta stage, has helped to clean much code. -- Jason Straight
Re: [Cooker] gcc 2.96 - statement of intent, please?
On 02.24 Jason Straight wrote: I'm more concerned about the problems that might arise simply because the packages in the distro were built with it. What problems that may occur, if one get's into the habbit of making binary incompatible packages at every distro release it kind of renders the whole idea of rpm useless. There will be rpm's for i386 using glibc 2.1 with gcc2.96, 2.2 with gcc 2.96, 2.2 with 2.96 and 2.2 with gcc 3.0 eventually. May as well just figure on using source for everything. While I personally use source for 99% of my software that doesn't come with a distro this isn't really a problem, but it's a nighmare for uninitiated users. It's even more of a mess than the differences between different versions of windows. I agree this can be a problem. But C is a minor issue, and also glibc. See, you do everytime you jump from 7.2 to cooker. The first thing you must install is glibc2.2. And everything works. They are binary compatible, AFAIK. (when jumpin from 2.1 to 2.2, what worked in 2.1 works in 2.2, the reverse can be a problem, perhaps). C is C and has a well defined ABI. The only problem is using features in newer glibc that are not present in previous. The BigIssue(tm) are g++ and libstdc++. And you will not have an stable g++ ABI until 3.0. gcc-3.0 is already branched (whatever that word means with regards to tree stability...), anybody knows if its ABI is definitive, with only minor changes waiting ? -- J.A. Magallon $ cd pub mailto:[EMAIL PROTECTED] $ more beer Linux werewolf 2.4.2-ac3 #1 SMP Fri Feb 23 21:48:09 CET 2001 i686
