Re: State of gcc 2.95 use in Debian unstable
Bill Allombert [EMAIL PROTECTED] writes:
On Fri, Dec 09, 2005 at 04:22:37PM +0100, Goswin von Brederlow wrote:
Heiko M?ller [EMAIL PROTECTED] writes:
We found that gcc-2.95 -Os produces object code of acceptable quality
within reasonable compilation times. gcc =3 is less efficient w.r.t.
compilation time and memory consumption and in many cases even fails
to compile our codes due to the very long expressions. The C/C++ codes
generated from the computer algebra software are perhaps unusual but
not broken.
Can you send in a few (hopefully short) examples that fail as
bugreports?
I cannot speak for Heiko, but my examples are far from short. Indeed
they include a statement that is several megabytes long.
Short as in
double foo(double in1, double in2, ...) {
return /* very very long formula */
}
or something. Not 20MB of unintresting prefix to the actual code that
fails.
gcc exhaust all the memory available and fail with
Internal compiler error:
virtual memory exhausted
An gcc version that use less memory will be able to complete the
compilation.
Or a system with more memory.
It would be intresting to see if it actualy does compile or if it get
stuck in a loop allocating memory all the time or something. Bug like
that do exist.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Hi, thanks for all the comments. I will do tests with gcc-4.x and, if the regression is still there, file a bug report upstream. Heiko On Saturday 10 December 2005 20:03, Thiemo Seufer wrote: Heiko Müller wrote: Dear Thiemo, we very much appreciate your work on the gcc-2.95 debian package. For us - and probably also for other users in the scientific community - the old compiler version is still of great value. We use gcc-2.95 to compile C/C++ code with very large mathematical expressions generated by computer algebra software. This involves very long (several thousand lines of code) functions to evaluate multi-variable polynomial expression resulting from perturbation theoretical solutions of physical problems. We found that gcc-2.95 -Os produces object code of acceptable quality within reasonable compilation times. gcc =3 is less efficient w.r.t. compilation time and memory consumption and in many cases even fails to compile our codes due to the very long expressions. The C/C++ codes generated from the computer algebra software are perhaps unusual but not broken. Well, gcc 3.x was somewhat disappointing WRT, but I would expect 4.0 to do better. If 4.x fails for your (valid and standard-conforming) code, please consider to provide a testcase to the upstream developers. I'm sure they are interested in it, and long-term it will help you as well to have a more modern compiler which can handle such cases. Since what we are doing is not so unusual in theoretical physics we are probably not alone with these kind problems. Please consider that even if no other debian packages would depend on gcc-2.95 many users may very much require it. Indeed, I got also one private reply which suggested gcc-2.95 is still an interesting choice for some numerics code. Thiemo
Re: State of gcc 2.95 use in Debian unstable
On Fri, Dec 09, 2005 at 04:22:37PM +0100, Goswin von Brederlow wrote: Heiko M?ller [EMAIL PROTECTED] writes: We found that gcc-2.95 -Os produces object code of acceptable quality within reasonable compilation times. gcc =3 is less efficient w.r.t. compilation time and memory consumption and in many cases even fails to compile our codes due to the very long expressions. The C/C++ codes generated from the computer algebra software are perhaps unusual but not broken. Can you send in a few (hopefully short) examples that fail as bugreports? I cannot speak for Heiko, but my examples are far from short. Indeed they include a statement that is several megabytes long. gcc exhaust all the memory available and fail with Internal compiler error: virtual memory exhausted An gcc version that use less memory will be able to complete the compilation. There is probably nothing to do about compile time and memory consuption but it should at least work. Maybe the compiled result is even faster. Provide you have enough memory to get it at all. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
On Fri, Dec 09, 2005 at 09:33:11AM +0100, Heiko Müller wrote: We found that gcc-2.95 -Os produces object code of acceptable quality within reasonable compilation times. gcc =3 is less efficient w.r.t. compilation time and memory consumption and in many cases even fails to compile our codes due to the very long expressions. Note that there were considerable improvements done in gcc 3.4 and gcc 4.0 with regard to compilation speed (in particular in non-optimizing builds); you might want to re-test with GCC 4.x if you haven't already. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Heiko Müller wrote: Dear Thiemo, we very much appreciate your work on the gcc-2.95 debian package. For us - and probably also for other users in the scientific community - the old compiler version is still of great value. We use gcc-2.95 to compile C/C++ code with very large mathematical expressions generated by computer algebra software. This involves very long (several thousand lines of code) functions to evaluate multi-variable polynomial expression resulting from perturbation theoretical solutions of physical problems. We found that gcc-2.95 -Os produces object code of acceptable quality within reasonable compilation times. gcc =3 is less efficient w.r.t. compilation time and memory consumption and in many cases even fails to compile our codes due to the very long expressions. The C/C++ codes generated from the computer algebra software are perhaps unusual but not broken. Well, gcc 3.x was somewhat disappointing WRT, but I would expect 4.0 to do better. If 4.x fails for your (valid and standard-conforming) code, please consider to provide a testcase to the upstream developers. I'm sure they are interested in it, and long-term it will help you as well to have a more modern compiler which can handle such cases. Since what we are doing is not so unusual in theoretical physics we are probably not alone with these kind problems. Please consider that even if no other debian packages would depend on gcc-2.95 many users may very much require it. Indeed, I got also one private reply which suggested gcc-2.95 is still an interesting choice for some numerics code. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Dear Thiemo, we very much appreciate your work on the gcc-2.95 debian package. For us - and probably also for other users in the scientific community - the old compiler version is still of great value. We use gcc-2.95 to compile C/C++ code with very large mathematical expressions generated by computer algebra software. This involves very long (several thousand lines of code) functions to evaluate multi-variable polynomial expression resulting from perturbation theoretical solutions of physical problems. We found that gcc-2.95 -Os produces object code of acceptable quality within reasonable compilation times. gcc =3 is less efficient w.r.t. compilation time and memory consumption and in many cases even fails to compile our codes due to the very long expressions. The C/C++ codes generated from the computer algebra software are perhaps unusual but not broken. Since what we are doing is not so unusual in theoretical physics we are probably not alone with these kind problems. Please consider that even if no other debian packages would depend on gcc-2.95 many users may very much require it. Best regards, Heiko -- Dr. Heiko Mueller Englerstr. 28 Tel: +49 6221 89467-21 CEOS GmbH D-69126 Heidelberg Fax: +49 6221 89467-29 Germany http://www.ceos-gmbh.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Heiko Müller [EMAIL PROTECTED] writes: We found that gcc-2.95 -Os produces object code of acceptable quality within reasonable compilation times. gcc =3 is less efficient w.r.t. compilation time and memory consumption and in many cases even fails to compile our codes due to the very long expressions. The C/C++ codes generated from the computer algebra software are perhaps unusual but not broken. Can you send in a few (hopefully short) examples that fail as bugreports? There is probably nothing to do about compile time and memory consuption but it should at least work. Maybe the compiled result is even faster. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Heiko Müller writes: We found that gcc-2.95 -Os produces object code of acceptable quality within reasonable compilation times. gcc =3 is less efficient w.r.t. please be more precise. Debian currently uses 4.0, and has a 4.1 prerelease in the archives (gcc-snapshot). such regressions are best filed as bug reports with a self-contained example. thanks, Matthias
Re: State of gcc 2.95 use in Debian unstable
On Tue, 15 Nov 2005, Thiemo Seufer wrote: while preparing an upload of gcc-2.95 which fixes its worst problems I wondered how many users of it are actually left. 9 packages in unstable still declare a build dependency on gcc-2.95 or g++-2.95, this makes it IMHO a plausible release goal to get rid of 2.95 maintenance for etch. I guess it is not a good idea as long as Linus still has the line - Make sure you have gcc 2.95.3 available in his README in the kernel source tree. Best wishes, -- Christian Fromme Mail: kaner at strace.org GPG: 9DE5E8B9 If you seek the kernel, then you must break the shell. (Meister Eckhart) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
On Wed, Nov 16, 2005 at 01:23:43PM +0100, Thiemo Seufer wrote: I wouldn't recommend to compile new code with 2.95 just because it is faster. It doesn't do standard C and misses many broken constructs which are caught by newer compilers. The real advantage of gcc-2.95 is that we start to know what are its bugs and limitations so we are less likely to get unpredicted behaviour than with gcc-3.3. In some case this is unvaluable. For the same reason I am quite happy to have woody gcc272 around. (If woody had gcc272, then etch can have gcc-2.95 without shame, I think.) Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Dave Carrigan wrote: On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote: this makes it IMHO a plausible release goal to get rid of 2.95 maintenance for etch. No it is not. Just because debian packages don't use 2.95 doesn't mean that end users have the same luxury. The need for gcc-2.95 usually means the source code is broken (in C99 terms) and should be fixed. Do you have an example of an use case where this is unfeasible, and which is important enough to justify continued maintenance of gcc 2.95? Device driver development for embedded systems? There are embedded systems, including x86-based, that run kernels which fail to compile with gcc = 3.x. Also, people have some code (old completed internal projects, etc), which probably would never be ported to newer C++ standards (it's plainly too big job), but which are still useful to keep working - e.g. for demonstration/education/similar purposes. I have to deal with the both above situations. And I believe I'm far not alone here. So there is user benefit from keeping gcc 2.95 in usable state. Not fixing internal compiler bugs - user who faces old compiler's failure to build code should seriously consider switching to newer versions - but just keeping packages installable and usable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
In linux.debian.devel, you wrote: The need for gcc-2.95 usually means the source code is broken (in C99 terms) and should be fixed. Do you have an example of an use case where this is unfeasible, and which is important enough to justify continued maintenance of gcc 2.95? [..] Also, people have some code (old completed internal projects, etc), which probably would never be ported to newer C++ standards (it's plainly too big job), but which are still useful to keep working - e.g. for demonstration/education/similar purposes. I have to deal with the both above situations. And I believe I'm far not alone here. So there is user benefit from keeping gcc 2.95 in usable state. Not fixing internal compiler bugs - user who faces old compiler's failure to build code should seriously consider switching to newer versions - but just keeping packages installable and usable. I agree. Plus, compilation of C code with 2.95 is typically twice as fast as 4.0. While 2.95 may be too buggy wrt C++, it's still useful for C. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Mark Brown wrote: On Tue, Nov 15, 2005 at 06:30:00PM +0100, Thiemo Seufer wrote: The need for gcc-2.95 usually means the source code is broken (in C99 terms) and should be fixed. Do you have an example of an use case where this is unfeasible, and which is important enough to justify continued maintenance of gcc 2.95? It was relatively common to find C++ code that wouldn't build with the new C++ front end in GCC 3.0. Is there one left today? (Does this mean it is dead upstream?) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Nikita V. Youshchenko wrote: Dave Carrigan wrote: On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote: this makes it IMHO a plausible release goal to get rid of 2.95 maintenance for etch. No it is not. Just because debian packages don't use 2.95 doesn't mean that end users have the same luxury. The need for gcc-2.95 usually means the source code is broken (in C99 terms) and should be fixed. Do you have an example of an use case where this is unfeasible, and which is important enough to justify continued maintenance of gcc 2.95? Device driver development for embedded systems? There are embedded systems, including x86-based, that run kernels which fail to compile with gcc = 3.x. In that case you likely need as well an older binutils version, which probably means to use a sarge or even woody chroot. Also, people have some code (old completed internal projects, etc), which probably would never be ported to newer C++ standards (it's plainly too big job), but which are still useful to keep working - e.g. for demonstration/education/similar purposes. I have to deal with the both above situations. And I believe I'm far not alone here. So there is user benefit from keeping gcc 2.95 in usable state. Not fixing internal compiler bugs AFAICS this makes a point to have some (un-/little) maintained version of gcc-2.95 somewhere. It doesn't make a point to distribute it as part of an official etch release. - user who faces old compiler's failure to build code should seriously consider switching to newer versions - but just keeping packages installable and usable. Apparently those packages weren't useful/important enough to bring them into Debian... Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Thiemo Seufer wrote: Nikita V. Youshchenko wrote: [snip] Also, people have some code (old completed internal projects, etc), which probably would never be ported to newer C++ standards (it's plainly too big job), but which are still useful to keep working - e.g. for demonstration/education/similar purposes. I have to deal with the both above situations. And I believe I'm far not alone here. So there is user benefit from keeping gcc 2.95 in usable state. Not fixing internal compiler bugs AFAICS this makes a point to have some (un-/little) maintained version of gcc-2.95 somewhere. It doesn't make a point to distribute it as part of an official etch release. - user who faces old compiler's failure to build code should seriously consider switching to newer versions - but just keeping packages installable and usable. Apparently those packages weren't useful/important enough to bring them into Debian... s/packages/programs which need gcc 2.95/, that is. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Moritz Muehlenhoff wrote: In linux.debian.devel, you wrote: The need for gcc-2.95 usually means the source code is broken (in C99 terms) and should be fixed. Do you have an example of an use case where this is unfeasible, and which is important enough to justify continued maintenance of gcc 2.95? [..] Also, people have some code (old completed internal projects, etc), which probably would never be ported to newer C++ standards (it's plainly too big job), but which are still useful to keep working - e.g. for demonstration/education/similar purposes. I have to deal with the both above situations. And I believe I'm far not alone here. So there is user benefit from keeping gcc 2.95 in usable state. Not fixing internal compiler bugs - user who faces old compiler's failure to build code should seriously consider switching to newer versions - but just keeping packages installable and usable. I agree. Plus, compilation of C code with 2.95 is typically twice as fast as 4.0. While 2.95 may be too buggy wrt C++, it's still useful for C. I wouldn't recommend to compile new code with 2.95 just because it is faster. It doesn't do standard C and misses many broken constructs which are caught by newer compilers. It may still have some use for regression tests, and for old code without a prospect of getting updated. I don't know how relevant those cases are for Debian. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
The need for gcc-2.95 usually means the source code is broken (in C99 terms) and should be fixed. Do you have an example of an use case where this is unfeasible, and which is important enough to justify continued maintenance of gcc 2.95? Device driver development for embedded systems? There are embedded systems, including x86-based, that run kernels which fail to compile with gcc = 3.x. In that case you likely need as well an older binutils version, which probably means to use a sarge or even woody chroot. I have not yet faced a situation where newer binutils wont, work. Also, people have some code (old completed internal projects, etc), which probably would never be ported to newer C++ standards (it's plainly too big job), but which are still useful to keep working - e.g. for demonstration/education/similar purposes. AFAICS this makes a point to have some (un-/little) maintained version of gcc-2.95 somewhere. It doesn't make a point to distribute it as part of an official etch release. - user who faces old compiler's failure to build code should seriously consider switching to newer versions - but just keeping packages installable and usable. Apparently those packages weren't useful/important enough to bring them into Debian... Are debian compiler packages intended to compile debian packages only, or also to be used as compiler for non-debian tasks also? The situation is: gcc-2.95 is no longer needed to compile debian packages, but it is still needed for other tasks, by many people. So why remove it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Nikita V. Youshchenko wrote: The need for gcc-2.95 usually means the source code is broken (in C99 terms) and should be fixed. Do you have an example of an use case where this is unfeasible, and which is important enough to justify continued maintenance of gcc 2.95? Device driver development for embedded systems? There are embedded systems, including x86-based, that run kernels which fail to compile with gcc = 3.x. In that case you likely need as well an older binutils version, which probably means to use a sarge or even woody chroot. I have not yet faced a situation where newer binutils wont, work. #336022, as the latest example I saw. [snip] Apparently those packages weren't useful/important enough to bring them into Debian... Are debian compiler packages intended to compile debian packages only, or also to be used as compiler for non-debian tasks also? IMHO the latter, as long as it incurs no additional overhead. The situation is: gcc-2.95 is no longer needed to compile debian packages, but it is still needed for other tasks, by many people. By whom, and for what? So far I haven't heard a specific project's name. So why remove it? Is it worth to fix when it breaks again? (Currently it FTBFS on alpha, probably binutils-induced.) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
On Wed, Nov 16, 2005 at 04:12:45PM +0100, Thiemo Seufer wrote: The situation is: gcc-2.95 is no longer needed to compile debian packages, but it is still needed for other tasks, by many people. By whom, and for what? So far I haven't heard a specific project's name. Debian does not exist for the benefit of its developers, it exists for the benefit of its users. I doubt that many Debian *users* read debian-devel so they aren't going to be responding to messages in this thread. I am quite sure that there are Debian *users* out there that have legacy code that only builds under gcc 2.95 (or more likely g++ 2.95) and they haven't ported it to a newer C compiler because there is no business case for it. Removing a package simply because the Debian developers don't need it any more is the kind of arrogance that drives users away from Debian to other distributions. -- Dave Carrigan Seattle, WA, USA [EMAIL PROTECTED] | http://www.rudedog.org/ UNIX-Apache-Perl-Linux-Firewalls-LDAP-C-C++-DNS-PalmOS-PostgreSQL-MySQL-Postfix signature.asc Description: Digital signature
Re: State of gcc 2.95 use in Debian unstable
Dave Carrigan wrote: On Wed, Nov 16, 2005 at 04:12:45PM +0100, Thiemo Seufer wrote: The situation is: gcc-2.95 is no longer needed to compile debian packages, but it is still needed for other tasks, by many people. By whom, and for what? So far I haven't heard a specific project's name. [...] I am quite sure that there are Debian *users* out there that have legacy code that only builds under gcc 2.95 (or more likely g++ 2.95) and they haven't ported it to a newer C compiler because there is no business case for it. Dave, we're not working on the removal of gcc 2.95 for the fun of it. Sarge ships with gcc 3.3 as default and supports gcc 2.95. More than one year from now, Debian will release its next stable release and the balance of the costs of continued support of gcc 2.95 versus its benefits is shifting to a point where the effort of keeping 2.95 is undesirable. Support for old compilers is quite an effort and it's in the best interest of Debian and its users by dropping it so that Debian can retain its high quality standard. Debian is not rushing to drop gcc 2.95, but in the long run, it's inevitable. Or, to put it in your words, there is a business case for dropping gcc 2.95 support in etch. Removing a package simply because the Debian developers don't need it any more is the kind of arrogance that drives users away from Debian to other distributions. Well, Debian is a fairly large sample of (free) software. If reliance on gcc 2.95 is a vanishing characteristic of Debian packages, this suggests that the general usage has diminished to a point where it is unreasonable to continue support. this is why Thiemo asks for evidance of the contrary. This has nothing to do with arrogance or developers disregarding the interests of its users. It is about sustaining quality by allocating resources appropriately. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
* Dave Carrigan [EMAIL PROTECTED] [2005:11:16 07:33 -0800]: I am quite sure that there are Debian *users* out there that have legacy code that only builds under gcc 2.95 (or more likely g++ 2.95) and they haven't ported it to a newer C compiler because there is no business case for it. I fit this use case -- I work with embedded devices and as a result, sometimes older versions of software are necessary. However, it's usually not just gcc alone, it's glibc et al as well. The solution isn't to keep gcc 2.95 around indefinitely; it's for people to use debootstrap and chroots. -- off the chain like a rebellious guanine nucleotide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
On Wednesday 16 November 2005 12:05, Thiemo Seufer wrote: Device driver development for embedded systems? There are embedded systems, including x86-based, that run kernels which fail to compile with gcc = 3.x. In that case you likely need as well an older binutils version, which probably means to use a sarge or even woody chroot. 2.95 works fine with the latest binutils in my experience. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote: Replacement (2.6 Kernel) in the works, should be removed once 2.6 is stable enough: Christian T. Steigies [EMAIL PROTECTED] kernel-image-2.4.27-m68kBuild-Depends: gcc-2.95 kernel-patch-2.4.27-m68kBuild-Depends-Indep: gcc-2.95 It might take a while until 2.6 kernels can fully replace 2.4 (and 2.2!) kernels on m68k. Half of our buildds can not be installed with a 2.6 kernel at the moment. But people are working on it. Until then we need 2.4 on m68k, however I just (cross-)compiled 2.4.27 with gcc-3.3 with no problems. Since the 2.6 kernels are already built with gcc-3.3, 2.4 might actually work with gcc-3.3 also, I will give it a try and let you know. Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Dave Carrigan writes: I am quite sure that there are Debian *users* out there that have legacy code that only builds under gcc 2.95 (or more likely g++ 2.95) and they haven't ported it to a newer C compiler because there is no business case for it. Removing a package simply because the Debian developers don't need it any more is the kind of arrogance that drives users away from Debian to other distributions. You are still ok, aren't you? It's rather that kind of arrogance of a minority of users/lobbyists/some persons, who try to enforce support of old software for obscure reasons. You are free to maintain it outside the debian archives, if your time does permit it. Just yelling that somebody (i.e. Debian) should do it is so easy ... There's hardly any current distribution which still ships 2.95, so I'm unsure where you will go to. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Debian is not rushing to drop gcc 2.95, but in the long run, it's inevitable. Or, to put it in your words, there is a business case for dropping gcc 2.95 support in etch. If current debian maintainer(s) don't want to maintain gcc-2.95 any longer, they should probably orphan it, just like any other package. Maybe someone else will take it over. And only if nobody would, package should be removed. It's that simple. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
On Wed, 2005-11-16 at 07:33 -0800, Dave Carrigan wrote: On Wed, Nov 16, 2005 at 04:12:45PM +0100, Thiemo Seufer wrote: The situation is: gcc-2.95 is no longer needed to compile debian packages, but it is still needed for other tasks, by many people. By whom, and for what? So far I haven't heard a specific project's name. Debian does not exist for the benefit of its developers, it exists for the benefit of its users. I doubt that many Debian *users* read debian-devel so they aren't going to be responding to messages in this thread. [snip] Removing a package simply because the Debian developers don't need it any more is the kind of arrogance that drives users away from Debian to other distributions. Geez, talk about looking a gift horse in the mouth. How much do you *pay*, in hard, cold Dead Presidents, to use Debian? That's right: Zero. Nada. Zilch. Debian is staffed by volunteers who do this because they want to. I, for one, appreciate very, very much what they do for me. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. We have the power to do any damn fool thing we want to do, and we seem to do it about every ten minutes. Senator J. William Fulbright (D-AR) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
16.11.2005 pisze Ron Johnson ([EMAIL PROTECTED]): Debian is staffed by volunteers who do this because they want to. I, for one, appreciate very, very much what they do for me. quote Writing/maintaining software is providing a service (even when it's free). You need to listen to your customers if you want to learn what features they need and thereby improve your product. Of course, the customer isn't _always_ right, and often they suggest specific implementations which don't fit into the grand scheme, but it's the input of ideas which is important. Even if they seem at first to be wrong, I've found it's always worth thinking about them, even if you ultimate modify or reject them. This is all IMHO, of course. --Philip Hazel on exim-users@exim.org /quote Jubal -- [ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ] [ BOF2510053411, http://hell.pl/baran/tek/, alchemy pany! ] [ The Answer ] ''It's like our visit to the moon or to that other star I guess you go for nothing if you really want to go that far.'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
On Wed, 2005-11-16 at 21:07 +0100, Miros/law Baran wrote: 16.11.2005 pisze Ron Johnson ([EMAIL PROTECTED]): Debian is staffed by volunteers who do this because they want to. I, for one, appreciate very, very much what they do for me. quote Writing/maintaining software is providing a service (even when it's free). You need to listen to your customers if you want to learn what features they need and thereby improve your product. Consumer, yes (of bandwidth and DD time, effort, etc), or user, but not a customer, since the dictionary explicitly uses terms and phrases like makes purchases of a trader; a purchaser; a buyer and person with whom a business house has dealing. Now, if used RHAS, then I'd be a customer of RH, since I'd be paying them. Of course, the customer isn't _always_ right, and often they suggest specific implementations which don't fit into the grand scheme, but it's the input of ideas which is important. Even if they seem at first to be wrong, I've found it's always worth thinking about them, even if you ultimate modify or reject them. This is all IMHO, of course. If you did s/customer/user/ then I'd agree with you. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. There's no obfuscated Perl contest because it's pointless. Jeff Polk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Thiemo Seufer [EMAIL PROTECTED] writes: while preparing an upload of gcc-2.95 which fixes its worst problems I wondered how many users of it are actually left. 9 packages in unstable still declare a build dependency on gcc-2.95 or g++-2.95, this makes it IMHO a plausible release goal to get rid of 2.95 maintenance for etch. The most recent LJ notes that Adrian Bunk tried to push a patch in the kernel to remove support for older compilers, but was met with resistance from people that still use GCC 2.95. Apparently, these people prefer it for development due to its significantly faster compilation times compared to v3 and higher versions. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
State of gcc 2.95 use in Debian unstable
Hello All, while preparing an upload of gcc-2.95 which fixes its worst problems I wondered how many users of it are actually left. 9 packages in unstable still declare a build dependency on gcc-2.95 or g++-2.95, this makes it IMHO a plausible release goal to get rid of 2.95 maintenance for etch. The appended list gives a short overview of what needs to be done to achieve this. Please tell me if I missed or misunderstood something. Thiemo Unacknowledged NMU for one year, FTBFS for 200 days, either update or remove: Bao C. Ha [EMAIL PROTECTED] curselBuild-Depends: gcc-2.95 Sparc bootloader, needs update: Ben Collins [EMAIL PROTECTED] silo Build-Depends: gcc-2.95 Obsolete according to #debian-hurd, no request for removal filed yet: GNU Hurd Maintainers bug-hurd@gnu.org gnumach1 Build-Depends: gcc-2.95 Replacement (2.6 Kernel) in the works, should be removed once 2.6 is stable enough: Christian T. Steigies [EMAIL PROTECTED] kernel-image-2.4.27-m68k Build-Depends: gcc-2.95 kernel-patch-2.4.27-m68k Build-Depends-Indep: gcc-2.95 Openfirmware emulator/replacement(?), powerpc specific, needs update: Guillem Jover [EMAIL PROTECTED] openhackware Build-Depends-Indep: gcc-2.95 Unacknowledged NMU for one year, either update or remove: Ben Pfaff [EMAIL PROTECTED] gcccheckerBuild-Depends: gcc-2.95 Erraneous build dependency, should get fixed in the next upload, #336564: Robin Verduijn [EMAIL PROTECTED] mcvs Build-Depends: gcc-2.95 [mips mipsel] Malloc debugging, #285685 suggests it is broken for 300 days now, either update or remove: Steve M. Robbins [EMAIL PROTECTED] ccmalloc Build-Depends: g++-2.95 [alpha arm i386 m68k mips mipsel powerpc s390 sparc] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote: this makes it IMHO a plausible release goal to get rid of 2.95 maintenance for etch. No it is not. Just because debian packages don't use 2.95 doesn't mean that end users have the same luxury. -- Dave Carrigan Seattle, WA, USA [EMAIL PROTECTED] | http://www.rudedog.org/ UNIX-Apache-Perl-Linux-Firewalls-LDAP-C-C++-DNS-PalmOS-PostgreSQL-MySQL-Postfix signature.asc Description: Digital signature
Re: State of gcc 2.95 use in Debian unstable
On Nov 15, Dave Carrigan [EMAIL PROTECTED] wrote: No it is not. Just because debian packages don't use 2.95 doesn't mean that end users have the same luxury. Can you point us to some examples of such programs? Also, are you sure that users will not just be able to install the 2.95 packages from sarge? -- ciao, Marco signature.asc Description: Digital signature
Re: State of gcc 2.95 use in Debian unstable
Dave Carrigan wrote: On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote: this makes it IMHO a plausible release goal to get rid of 2.95 maintenance for etch. No it is not. Just because debian packages don't use 2.95 doesn't mean that end users have the same luxury. The need for gcc-2.95 usually means the source code is broken (in C99 terms) and should be fixed. Do you have an example of an use case where this is unfeasible, and which is important enough to justify continued maintenance of gcc 2.95? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Thiemo Seufer [EMAIL PROTECTED] writes: Unacknowledged NMU for one year, either update or remove: Ben Pfaff [EMAIL PROTECTED] gccchecker Build-Depends: gcc-2.95 I recently filed a request to have this package removed. It is not maintained upstream and valgrind is a better replacement. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote: Malloc debugging, #285685 suggests it is broken for 300 days now, either update or remove: Steve M. Robbins [EMAIL PROTECTED] ccmallocBuild-Depends: g++-2.95 [alpha arm i386 m68k mips mipsel powerpc s390 sparc] It's not broken. That bug is there to remind me to improve the package dependencies. Ccmalloc isn't dependent on GCC 2.95 per se. It's just that we build a stub for each supported version of g++. So if 2.95 goes away, I'll just remove that build-dep. No problem. -Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Steve M. Robbins wrote: On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote: Malloc debugging, #285685 suggests it is broken for 300 days now, either update or remove: Steve M. Robbins [EMAIL PROTECTED] ccmalloc Build-Depends: g++-2.95 [alpha arm i386 m68k mips mipsel powerpc s390 sparc] It's not broken. That bug is there to remind me to improve the package dependencies. Ccmalloc isn't dependent on GCC 2.95 per se. It's just that we build a stub for each supported version of g++. So if 2.95 goes away, I'll just remove that build-dep. No problem. Ok, I'll record it as Build-Deps on g++-2.95 only to support gcc-2.95. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Ben Pfaff wrote: Thiemo Seufer [EMAIL PROTECTED] writes: Unacknowledged NMU for one year, either update or remove: Ben Pfaff [EMAIL PROTECTED] gcccheckerBuild-Depends: gcc-2.95 I recently filed a request to have this package removed. It is not maintained upstream and valgrind is a better replacement. JFTR, request for removal was #337558. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
On Tue, Nov 15, 2005 at 06:30:00PM +0100, Thiemo Seufer wrote: The need for gcc-2.95 usually means the source code is broken (in C99 terms) and should be fixed. Do you have an example of an use case where this is unfeasible, and which is important enough to justify continued maintenance of gcc 2.95? It was relatively common to find C++ code that wouldn't build with the new C++ front end in GCC 3.0. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: State of gcc 2.95 use in Debian unstable
On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote: while preparing an upload of gcc-2.95 which fixes its worst problems I wondered how many users of it are actually left. 9 packages in unstable still declare a build dependency on gcc-2.95 or g++-2.95, this makes it IMHO a plausible release goal to get rid of 2.95 maintenance for etch. Obsolete according to #debian-hurd, no request for removal filed yet: GNU Hurd Maintainers bug-hurd@gnu.org gnumach1Build-Depends: gcc-2.95 I'll be asking for its removal this week. Openfirmware emulator/replacement(?), powerpc specific, needs update: Guillem Jover [EMAIL PROTECTED] openhackwareBuild-Depends-Indep: gcc-2.95 I'll allocate some time to upgrade this to latest gcc. thanks, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
