On Aug 26, 2004, at 4:20 AM, Martin Costabel wrote:
[snip]
This is not a discussion about philosophy or policy, but about how to deal with buggy software.
Absolutely correct. Thanks for the detailed response.
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.
I think we also want to be careful not to have them proliferate too much, but a few well-chosen gcc packages may be needed.
[snip]
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.
We need to be prepared for the day when Apple decides to stop shipping gcc-2.95.2 and/or gcc-3.1. We've almost completely gotten rid of 2.95.2 within fink, but as you point out, there are a number of places where we need gcc-3.1. Preparing a gcc-3.1 package sooner rather than later would be wise.
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
Seems like a good case for a fink package, then.
(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.
I am still hopeful that Apple will solve this soon, but if we can find our own solution in the meantime, that would be great.
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
They have revived it (at our request).
-- Dave
------------------------------------------------------- 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
