Daniel Macks wrote:
[]
I think we'd be setting ourselves up for a user support nightmare
At least we would have to think of a system how to avoid this. I also tend to think (but I am not yet sure about this) that it would probably be a bad idea to completely replace (for building Fink packages) Apple's gcc by a Fink package, because that would have too many ramifications that we cannot see in advance. But I would like to mention some facts that need to be clear in this discussion:
1. We are talking about tools for compiling Fink packages. Obj-C++ does not enter this picture, nor do Apple-specific optimizations like -fast. AFAICT there are no Fink packages that uses these. Or are there? We are also only talking about gcc (including C, Obj-C and C++), not the binutils. The binutils would work in the same way with other versions of gcc.
2. All known versions of gcc have bugs, and bugs without known workaround. We already have some hacks in place for dealing with some of them(1). Others are either ignored(3) or not yet solved(3). There are packages that cannot be built with Apple's compiler right now.
This is not a discussion about philosophy or policy, but about how to deal with buggy software.
3. The recent versions of gcc seem to be sufficiently binary compatible so that you can combine binaries compiled with different versions without problems. You can also have several versions of gcc around without interference. Fortunately, Apple does not use dynamic gcc runtime libraries like some other systems are doing.
It would be possible to have one or more Fink gcc packages and have those packages that really do not work when compiled with Apple's compiler builddepend on them. The hard part isn't making the gcc packages (I have a couple of them here in various forms, for 3.3.3, 3.4.1, 3.5.0), but identifying those Fink packages that need them.
One problem with having several versions of gcc is that these are big packages. But they are not much bigger than, let's say, python, where we already have such a construction. A gcc package could also be combined with g77. The g77 package already compiles gcc-3.4.1 and then discards it before installation.
Using one new Fink gcc package that solves all the problems is a tempting idea, but apart from the management problems already mentioned, there is also the problem that we will probably not be able to find a version where all the bugs are fixed. gcc3.4.1 would go a long way, but it wouldn't solve all the problems.
Footnotes:
(1) We have several packages that need to be compiled with gcc-2.95.2 or with gcc-3.1. At least in the cases I know where gcc-3.1 is needed, this is not caused by old outdated code, but by the fact that for some reason these things really do not work when compiled with gcc-3.3. This is also not the g++3.1/g++3.3 binary-incompatibility question, quite the opposite, the code that is compiled with g++3.1 is actually linked with libraries compiled with gcc-3.3.
In the cases of pwlib (discussed recently here) and of visual-py23 (my package), even only the g++3 (=g++-3.1) executable itself is used, the headers and other parts of the compiler are taken from gcc-3.3, without any compatibility problem.
I'll mention visual-py23 also because I would like to release a Fink package for the new upstream version. The reason why I haven't done so is that this needs to be compiled with gcc-3.3.3 or gcc-3.4.1. It just does not work with gcc-3.1, whether from Apple or from gnu. The upstream maintainers have an instruction in place how to do this, based on Fink. It involves downloading and compiling gcc-3.3.3 and installing it into /usr/local. It would be much cleaner to do this with a Fink gcc3.3.3 package, but I have held back on this, because a discussion like the present one needed to be held first
(2) There is still the old bug with "section difference relocatable subtraction expression, "_foo" minus "L00000000001$pb" using a symbol at the end of section will not produce an assembly time constant". This is still not fixed in Apple's latest compiler. For C code, apparently one can live with this bug, the constructions triggering it being sufficiently infrequent, and for Fortran where it really bites, we have the g77-3.4.1 package. Well, the latter has other bugs that won't be fixed by the gcc people, so we have to live with them.
(3) The problems with octave, singular-libfac and others that cannot be built with Apple's latest g++-3.3 are too fresh in the discussion to have to be recalled, but they are real and urgent problems that have to be solved. Telling people "Don't install Xcode-1.5 if you haven't yet done so" can only be a very temporary measure. We have to provide some working solution.
We should also not forget the current state of the 10-2-gcc3.3 source distribution which is dead until Apple revives the August2003gccUpdater on their server or we provide a gcc3.3 package.
-- Martin
------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
