Re: Why not use normal CONFLICTS in lang/gcc43 instead of custom?
Jeremy et al,
On Tue, 16 Jun 2009, Jeremy Messenger wrote:
>> I think ${LOCALBASE}/bin/gcc295 would be enough. As you say, gcc295 is
>> dying, while ccache is actively used. It's quite annoying to remove such
>> check from the Makefile, while I doubt anyone is still going to compile
>> gcc43 with gcc295 installed in a non-standard location.
> Yes, I agree about that ${LOCALBASE}. Either put full path or remove
> gcc295 sound good to me.
a bit later than I had hoped for, but this is now resolved in that in
agreement with the maintainer I removed lang/gcc295 and the checks for
a gcc295 executable from the other lang/gcc ports (with the exception
of lang/gcc44 where I will do this shortly but wanted to give people a
bit more of a migration period since it is the designated successor
per MOVED).
Gerald
--
Gerald (Jerry) Pfeifer ger...@pfeifer.com http://www.pfeifer.com/gerald/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Why not use normal CONFLICTS in lang/gcc43 instead of custom?
On Tue, 16 Jun 2009 03:54:18 -0500, Alex Dupre wrote:
Using the full path will not work too well either with different
LOCALBASEs
though I guess one could check /usr/local, $PREFIX, and $LOCALBASE and
consider that good enough.
I think ${LOCALBASE}/bin/gcc295 would be enough. As you say, gcc295 is
dying, while ccache is actively used. It's quite annoying to remove such
check from the Makefile, while I doubt anyone is still going to compile
gcc43 with gcc295 installed in a non-standard location.
Yes, I agree about that ${LOCALBASE}. Either put full path or remove
gcc295 sound good to me.
Cheers,
Mezz
--
me...@cox.net - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Why not use normal CONFLICTS in lang/gcc43 instead of custom?
Using the full path will not work too well either with different LOCALBASEs
though I guess one could check /usr/local, $PREFIX, and $LOCALBASE and
consider that good enough.
I think ${LOCALBASE}/bin/gcc295 would be enough. As you say, gcc295 is
dying, while ccache is actively used. It's quite annoying to remove such
check from the Makefile, while I doubt anyone is still going to compile
gcc43 with gcc295 installed in a non-standard location.
--
Alex Dupre
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Why not use normal CONFLICTS in lang/gcc43 instead of custom?
On Sat, 13 Jun 2009, Jeremy Messenger wrote: > I am trying to install x11/gnome2 last night and the build has gotten > stop at lang/gcc43, because of conflict with lang/gcc295. But wait, I > don't have lang/gcc295 install. I only have ccache installed that has > put 'gcc295' in /usr/local/libexec/ccache/ and this path is in the front > of my PATH. It caused lang/gcc43 to find it by mistake. I'm afraid you indeed ran into a false positive here, alas there is good news -- see below... > Puzzled me for you to not use the CONFLICTS, so why not use it? If you > really can't use CONFLICTS, then can you use the full path of gcc295? > Thanks. Originally I had CONFLICTS, but that does not work as you may think since it only gets active after the build, at which point the user will have run into the build failure. So, upon request by somone (in portmgr?) I added the current check. Using the full path will not work too well either with different LOCALBASEs though I guess one could check /usr/local, $PREFIX, and $LOCALBASE and consider that good enough. Now for the good news: lang/gcc295 is a living dead. It has not built for some eight, nine months and I have deprecated all dependencies (I think), and plan to yank this port finally now. (If anyone wants to start with that, I'm barely online for the next week, and it would be nice to see the process starting...) Gerald ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Why not use normal CONFLICTS in lang/gcc43 instead of custom?
Hello Gerald, I am trying to install x11/gnome2 last night and the build has gotten stop at lang/gcc43, because of conflict with lang/gcc295. But wait, I don't have lang/gcc295 install. I only have ccache installed that has put 'gcc295' in /usr/local/libexec/ccache/ and this path is in the front of my PATH. It caused lang/gcc43 to find it by mistake. --- # ls -l /usr/local/libexec/ccache/ | grep 295 lrwxr-xr-x 1 root wheel 21 June 12 14:36 g++295@ -> /usr/local/bin/ccache lrwxr-xr-x 1 root wheel 21 June 12 14:36 gcc295@ -> /usr/local/bin/ccache # echo $PATH /usr/local/libexec/ccache:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin --- --- pre-extract: @# Building libgcj with lang/gcc295 installed is causing a failure @# about "hidden symbol `__eprintf'" in libgcc.a(_eprintf.o). @if type gcc295 >/dev/null ; then \ echo "This port will not build in the presence of lang/gcc295."; \ exit 1; \ fi --- Puzzled me for you to not use the CONFLICTS, so why not use it? If you really can't use CONFLICTS, then can you use the full path of gcc295? Thanks. Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
