The changes to lang/egcs to use gcc-2.95 break a number of ports that depend on egcc and eg++ being installed by this port. The new names are gcc295 and g++295 respectively. I've already been in contact with David O'Brien about this, who asked me to send-pr in the (trivial) changes. Ports affected are: audio/kdemultimedia11-i18n converters/kdesupport11-i18n deskutils/korganizer11-i18n devel/ORBacus devel/gnustep devel/mico games/flightgear games/kdegames11-i18n graphics/kdegraphics11-i18n java/guavac java/shujit misc/kdeutils11-i18n net/kdenetwork11-i18n textproc/aspell www/mozilla x11/kdebase11-i18n x11/kdelibs11-i18n x11-clocks/kdetoys11-i18n x11-toolkits/gtk-- x11-toolkits/plib x11-toolkits/qt-i18n Fix: uuencoded, gzipped tarball attached. Creates a directory patches/, containing one patch for each of the above mentioned ports. Note: this just fixes the dependencies for the new lang/egcs -- I have absolutely no idea at all whether any of the ports will build with this new compiler, certainly textproc/aspell has some problems (see PR/13166). How-To-Repeat: With the gcc-2.95 version of lang/egcs, try to build any of the above ports.
Responsible Changed From-To: freebsd-ports->cpiazza I was about to do this anyway :)
State Changed From-To: open->closed Changes committed, thanks!
* The changes to lang/egcs to use gcc-2.95 break a number of * ports that depend on egcc and eg++ being installed by this * port. The new names are gcc295 and g++295 respectively. In order to avoid having to change all the ports again when they are updated to gcc296 (or whatever), should we handle this in bsd.port.mk? I can add something like .if defined(USE_NEWGCC) CC= gcc295 CXX= g++295 BUILD_DEPENDS= gcc295:${PORTSDIR}/lang/egcs .endif to bsd.port.mk and the ports can just define USE_NEWGCC. Satoshi
On Tue, Aug 17, 1999 at 03:37:01PM -0700, Satoshi - Ports Wraith - Asami wrote: > > In order to avoid having to change all the ports again when they are > updated to gcc296 (or whatever), should we handle this in bsd.port.mk? > > I can add something like > > .if defined(USE_NEWGCC) > CC= gcc295 > CXX= g++295 > BUILD_DEPENDS= gcc295:${PORTSDIR}/lang/egcs > .endif > > to bsd.port.mk and the ports can just define USE_NEWGCC. I think that's a pretty elegant solution, yes -- David was mentioning an upgrade to gcc-2.95.1 which may or may not (I haven't looked) change the names of the executables again. I think we can safely say that there will be new releases of this gcc before everyone has migrated to a 4.x system, so it makes sense to drop it in. Of course, it doesn't deal with the extreme weirdness with LIBSTDC variable hacking in devel/ORBacus/Makefile, but that's possibly a good thing -- I don't understand that bit at all.. -aDe -- Ade Lovett, Austin, TX.
* From: Ade Lovett <ade@lovett.com> * > .if defined(USE_NEWGCC) * > CC= gcc295 * > CXX= g++295 * > BUILD_DEPENDS= gcc295:${PORTSDIR}/lang/egcs * > .endif * > * > to bsd.port.mk and the ports can just define USE_NEWGCC. Actually, I can even pull in the test for ${OSVERSION}. .if defined(USE_NEWGCC) && ${OSVERSION} < 400004 CC= gcc295 CXX= g++295 BUILD_DEPENDS= gcc295:${PORTSDIR}/lang/egcs .endif That will make the depending ports much simpler. * Of course, it doesn't deal with the extreme weirdness with LIBSTDC * variable hacking in devel/ORBacus/Makefile, but that's possibly * a good thing -- I don't understand that bit at all.. ;) Satoshi
On Tue, Aug 17, 1999 at 04:22:30PM -0700, Satoshi - Ports Wraith - Asami wrote: > > Actually, I can even pull in the test for ${OSVERSION}. > > .if defined(USE_NEWGCC) && ${OSVERSION} < 400004 > CC= gcc295 > CXX= g++295 > BUILD_DEPENDS= gcc295:${PORTSDIR}/lang/egcs > .endif > > That will make the depending ports much simpler. Yup. But it might lead to inconsistencies if the system compiler in -current is different from that specified by USE_NEWGCC. I know we don't "support" -current as a ports building platform, but I can envisage a case where the only reason a port won't build on -current is because of a system compiler problem. The USE_NEWGCC here doesn't even give us the option of being able to test out the theories by specifying a "known working" compiler. But I guess we can cross that bridge when we come to it :) One other thing.. it's probably worth adding a comment in the lang/egcs Makefile pointing back to this USE_NEWGCC definition, so that when the port gets updated (and the executable names change) there is an explicit "go fix this macro" edict.. -aDe -- Ade Lovett, Austin, TX.
* From: Ade Lovett <ade@lovett.com> * > Actually, I can even pull in the test for ${OSVERSION}. * > * > .if defined(USE_NEWGCC) && ${OSVERSION} < 400004 * > CC= gcc295 * > CXX= g++295 * > BUILD_DEPENDS= gcc295:${PORTSDIR}/lang/egcs * > .endif * > * > That will make the depending ports much simpler. * * Yup. But it might lead to inconsistencies if the system compiler * in -current is different from that specified by USE_NEWGCC. The above ".if" statement excludes -current. In -current, we always use "gcc/g++". * I know we don't "support" -current as a ports building platform, but No, you don't. Please don't spread misinformation. :) We DO support -current as well as -stable. It has been that way ever since the Ports Collection started and has only been false for a couple of months when we had the glitch with the 2.2/3.0 split a while ago. * One other thing.. it's probably worth adding a comment in the * lang/egcs Makefile pointing back to this USE_NEWGCC definition, so * that when the port gets updated (and the executable names change) * there is an explicit "go fix this macro" edict.. Sure. -PW
On Wed, Aug 18, 1999 at 03:11:22PM -0700, Satoshi - Ports Wraith - Asami wrote: > > The above ".if" statement excludes -current. In -current, we always > use "gcc/g++". I'm aware of that :) The point I was making is that there is the possibility that a port will compile and run successfully on -stable (using gcc295) but might fail on -current (using gcc, assuming the system compiler isn't the same as USE_NEWGCC). This may or may not be a bad thing.. > * I know we don't "support" -current as a ports building platform, but > > No, you don't. Please don't spread misinformation. :) We DO support > -current as well as -stable. Sorry, the comment was a little tongue-in-cheek (hence the quotes), I'm just trying to think of all the possibilities here for a case when the same port works on -stable, but not -current, when the only difference is the compiler. It's probably not that much of an issue, so I'll shut up now :) -aDe -- Ade Lovett, Austin, TX.