Re: options for forcing use of GCC vs CLANG
On 4/28/14, 12:30 AM, Ian Lepore wrote: On Sun, 2014-04-27 at 22:25 +0800, Julian Elischer wrote: I need to hold off using CLANG for a while at $JOB. We are moving to a newer FBSD in the vicinity of 10.0 but we need to keep the gcc in hte picture for a bit longer before switching. What options do I put into various /etc/make.conf to keep CLANG out ofhte picture until we are ready for it? From reading various posts I see: WITHOUT_CLANG=yes CC=gcc CXX=g++ CPP=gcc -E but that doesn't seem complete to me. For now I want to not compile clang in our official build environment. (and obviously not use it until we are ready for it later this year.) What other hooks do I need to set? Julian We've got the same situation at work. What I'm using right now to build 11-current @ r264151 is this: WITH_GCC=yes \ WITH_GNUCXX=yes \ WITHOUT_CLANG=yes \ WITHOUT_CLANG_IS_CC=yes \ But that's now several weeks out of date, and there are two new knobs I haven't investigated yet: WITH_CLANG_BOOTSTRAP and WITH_GCC_BOOTSTRAP. -- Ian Thanks Ian. Can soneone who is driving this please chime in? I will need to keep GCC on systems from 9.0 to 10.1 (and various points in between on the -current lineage). Will the lines above work for that whole range? or did it change over time? I expect to flip the CLANG switch sometime around the time when we slide on to 10.1 or so. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: options for forcing use of GCC
On 4/28/14, 12:30 AM, Ian Lepore wrote: WITH_GCC=yes \ WITH_GNUCXX=yes \ WITHOUT_CLANG=yes \ WITHOUT_CLANG_IS_CC=yes \ forgot to ask.. is this in /etc/make.conf? or elsewhere? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: options for forcing use of GCC vs CLANG
On Mon, 2014-04-28 at 14:47 +0800, Julian Elischer wrote: On 4/28/14, 12:30 AM, Ian Lepore wrote: On Sun, 2014-04-27 at 22:25 +0800, Julian Elischer wrote: I need to hold off using CLANG for a while at $JOB. We are moving to a newer FBSD in the vicinity of 10.0 but we need to keep the gcc in hte picture for a bit longer before switching. What options do I put into various /etc/make.conf to keep CLANG out ofhte picture until we are ready for it? From reading various posts I see: WITHOUT_CLANG=yes CC=gcc CXX=g++ CPP=gcc -E but that doesn't seem complete to me. For now I want to not compile clang in our official build environment. (and obviously not use it until we are ready for it later this year.) What other hooks do I need to set? Julian We've got the same situation at work. What I'm using right now to build 11-current @ r264151 is this: WITH_GCC=yes \ WITH_GNUCXX=yes \ WITHOUT_CLANG=yes \ WITHOUT_CLANG_IS_CC=yes \ But that's now several weeks out of date, and there are two new knobs I haven't investigated yet: WITH_CLANG_BOOTSTRAP and WITH_GCC_BOOTSTRAP. -- Ian Thanks Ian. Can soneone who is driving this please chime in? I will need to keep GCC on systems from 9.0 to 10.1 (and various points in between on the -current lineage). Will the lines above work for that whole range? or did it change over time? I expect to flip the CLANG switch sometime around the time when we slide on to 10.1 or so. Adding Warner, since he's the one doing the work on this stuff. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: options for forcing use of GCC
On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: On 4/28/14, 12:30 AM, Ian Lepore wrote: WITH_GCC=yes \ WITH_GNUCXX=yes \ WITHOUT_CLANG=yes \ WITHOUT_CLANG_IS_CC=yes \ forgot to ask.. is this in /etc/make.conf? or elsewhere? Actually in our build system we build in a chroot, and we inject those args into the environment during the builds so that we can have different options for building world versus cross-world within the chroot, but I think the more-normal place would be make.conf. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: options for forcing use of GCC
On 4/28/14, 8:05 PM, Ian Lepore wrote: On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: On 4/28/14, 12:30 AM, Ian Lepore wrote: WITH_GCC=yes \ WITH_GNUCXX=yes \ WITHOUT_CLANG=yes \ WITHOUT_CLANG_IS_CC=yes \ forgot to ask.. is this in /etc/make.conf? or elsewhere? Actually in our build system we build in a chroot, and we inject those args into the environment during the builds so that we can have different options for building world versus cross-world within the chroot, but I think the more-normal place would be make.conf. we also use a combination of environment and make.conf in a chroot. though people sometimes talk about a src.conf (or is that src.mk?) but I haven't found that one yet. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: options for forcing use of GCC
On Mon, 2014-04-28 at 22:03 +0800, Julian Elischer wrote: On 4/28/14, 8:05 PM, Ian Lepore wrote: On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: On 4/28/14, 12:30 AM, Ian Lepore wrote: WITH_GCC=yes \ WITH_GNUCXX=yes \ WITHOUT_CLANG=yes \ WITHOUT_CLANG_IS_CC=yes \ forgot to ask.. is this in /etc/make.conf? or elsewhere? Actually in our build system we build in a chroot, and we inject those args into the environment during the builds so that we can have different options for building world versus cross-world within the chroot, but I think the more-normal place would be make.conf. we also use a combination of environment and make.conf in a chroot. though people sometimes talk about a src.conf (or is that src.mk?) but I haven't found that one yet. -- Ian In theory, /etc/make.conf affects all builds you do -- world, kernel, ports, your own apps, everything -- whereas /etc/src.conf affects only kernel and world. I've heard it said that the reality falls short of that and src.conf settings inappropriately leak into ports builds. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: options for forcing use of GCC
On Mon, Apr 28, 2014 at 7:23 AM, Ian Lepore i...@freebsd.org wrote: On Mon, 2014-04-28 at 22:03 +0800, Julian Elischer wrote: On 4/28/14, 8:05 PM, Ian Lepore wrote: On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: On 4/28/14, 12:30 AM, Ian Lepore wrote: WITH_GCC=yes \ WITH_GNUCXX=yes \ WITHOUT_CLANG=yes \ WITHOUT_CLANG_IS_CC=yes \ forgot to ask.. is this in /etc/make.conf? or elsewhere? Actually in our build system we build in a chroot, and we inject those args into the environment during the builds so that we can have different options for building world versus cross-world within the chroot, but I think the more-normal place would be make.conf. we also use a combination of environment and make.conf in a chroot. though people sometimes talk about a src.conf (or is that src.mk?) but I haven't found that one yet. -- Ian In theory, /etc/make.conf affects all builds you do -- world, kernel, ports, your own apps, everything -- whereas /etc/src.conf affects only kernel and world. I've heard it said that the reality falls short of that and src.conf settings inappropriately leak into ports builds. -- Ian I have also heard this, but a grep of ports/Mk finds no matches to src\.conf, so this appears to not be the case. It should not be as the whole purpose of src.conf was to have a make configuration that would be used to build the system, but not other things. make.conf already provided for that. The only exception I might see is the building of a kernel module which might need to know how the system was made and that would be in the specific port's Makefile, not a system wide file. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: options for forcing use of GCC
On Apr 28, 2014, at 12:54 AM, Julian Elischer jul...@freebsd.org wrote: On 4/28/14, 12:30 AM, Ian Lepore wrote: WITH_GCC=yes \ WITH_GNUCXX=yes \ WITHOUT_CLANG=yes \ WITHOUT_CLANG_IS_CC=yes \ forgot to ask.. is this in /etc/make.conf? or elsewhere? Add them to /etc/make.conf. They will be global to the entire system. Current may also require WITHOUT_CLANG_BOOTSTRAP=t and WITH_GCC_BOOTSTRAP=t if you want to build the system with gcc. The ‘build for the target’ and ‘what to build with’ have been decoupled and there’s no clean way to fallback. Also, in the future CLANG_IS_CC is going to die entirely. It was supposed to be a short-term hack, and it has lived too long and been used in too many lame, hackey ways. It is time to retire it. It will be replaced by DEFAULT_COMPILER=blah which will drive the defaults to build with as well as to install with (nicely solving the current friction points here). I have the start of patches to do this, so maybe by BSDcan it will be gone in current, along with every last clang-induced build-system kludge. I’ve killed about a dozen already, but more remain. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: options for forcing use of GCC
On Apr 28, 2014, at 9:52 AM, Kevin Oberman rkober...@gmail.com wrote: On Mon, Apr 28, 2014 at 7:23 AM, Ian Lepore i...@freebsd.org wrote: On Mon, 2014-04-28 at 22:03 +0800, Julian Elischer wrote: On 4/28/14, 8:05 PM, Ian Lepore wrote: On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: On 4/28/14, 12:30 AM, Ian Lepore wrote: WITH_GCC=yes \ WITH_GNUCXX=yes \ WITHOUT_CLANG=yes \ WITHOUT_CLANG_IS_CC=yes \ forgot to ask.. is this in /etc/make.conf? or elsewhere? Actually in our build system we build in a chroot, and we inject those args into the environment during the builds so that we can have different options for building world versus cross-world within the chroot, but I think the more-normal place would be make.conf. we also use a combination of environment and make.conf in a chroot. though people sometimes talk about a src.conf (or is that src.mk?) but I haven't found that one yet. -- Ian In theory, /etc/make.conf affects all builds you do -- world, kernel, ports, your own apps, everything -- whereas /etc/src.conf affects only kernel and world. I've heard it said that the reality falls short of that and src.conf settings inappropriately leak into ports builds. That’s bogus. Port builds define _WITHOUT_SRCCONF which precludes not only including /etc/src.conf, but also disables the while WITH/WITHOUT_FOO mechanism from converting those options into MK_FOO options. I have also heard this, but a grep of ports/Mk finds no matches to src\.conf, so this appears to not be the case. Ports specifically goes out of its way to make sure this doesn’t happen. Perhaps it isn’t going out of its way far enough? It should not be as the whole purpose of src.conf was to have a make configuration that would be used to build the system, but not other things. make.conf already provided for that. If someone can show me a specific, verifiable leak, I’ll look into it. Vague rumors about possible issues that may have existed once upon a time aren’t fruitful to chase. The only exception I might see is the building of a kernel module which might need to know how the system was made and that would be in the specific port's Makefile, not a system wide file. I’m not sure I understand here. If a kernel module uses the kernel module build stuff, it should be affected by the src.conf files unless you specifically request otherwise because you know what you are doing (e.g., building for another system, cross building, etc). Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: options for forcing use of GCC
On Mon, 2014-04-28 at 10:04 -0600, Warner Losh wrote: On Apr 28, 2014, at 9:52 AM, Kevin Oberman rkober...@gmail.com wrote: On Mon, Apr 28, 2014 at 7:23 AM, Ian Lepore i...@freebsd.org wrote: On Mon, 2014-04-28 at 22:03 +0800, Julian Elischer wrote: On 4/28/14, 8:05 PM, Ian Lepore wrote: On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: On 4/28/14, 12:30 AM, Ian Lepore wrote: WITH_GCC=yes \ WITH_GNUCXX=yes \ WITHOUT_CLANG=yes \ WITHOUT_CLANG_IS_CC=yes \ forgot to ask.. is this in /etc/make.conf? or elsewhere? Actually in our build system we build in a chroot, and we inject those args into the environment during the builds so that we can have different options for building world versus cross-world within the chroot, but I think the more-normal place would be make.conf. we also use a combination of environment and make.conf in a chroot. though people sometimes talk about a src.conf (or is that src.mk?) but I haven't found that one yet. -- Ian In theory, /etc/make.conf affects all builds you do -- world, kernel, ports, your own apps, everything -- whereas /etc/src.conf affects only kernel and world. I've heard it said that the reality falls short of that and src.conf settings inappropriately leak into ports builds. That’s bogus. Port builds define _WITHOUT_SRCCONF which precludes not only including /etc/src.conf, but also disables the while WITH/WITHOUT_FOO mechanism from converting those options into MK_FOO options. I have also heard this, but a grep of ports/Mk finds no matches to src\.conf, so this appears to not be the case. Ports specifically goes out of its way to make sure this doesn’t happen. Perhaps it isn’t going out of its way far enough? It should not be as the whole purpose of src.conf was to have a make configuration that would be used to build the system, but not other things. make.conf already provided for that. If someone can show me a specific, verifiable leak, I’ll look into it. Vague rumors about possible issues that may have existed once upon a time aren’t fruitful to chase. You've known me long enough to know that the Vague rumors... sentence doesn't describe the way I operate. I was vague on the fine details, but I remember an email thread where it was specifically shown that the contents of src.conf were affecting ports builds. I just tracked it down [1] and about midway through that thread it materialized that some ports' makefiles include bsd.prog.mk or bsd.lib.mk and that leads to the inappropriate inclusion of src.conf into a port build. So I figured I'd do a quick look for ports makefiles that are including bsd.[lib|prog|subdir].mk : revolution find . -name Make* | xargs grep bsd.*mk | \ grep -v bsd.port| grep -E lib.mk|prog.mk|subdir.mk | wc -l 66 That's probably not a perfect search, but it looks like there are a few ports that may be perturbed by src.conf settings, plus as was revealed in that thread, if you use /usr/share/mk/bsd.*.mk for your own software (as we do at $work) then your own builds are also affected by src.conf. I quite agree with the sentiments expressed in that thread that the genesis of the problem is the opt-out nature of src.conf. If it had been designed as an opt-in feature with a handful of /usr/src makefiles opting in as-needed, maybe the situation would be cleaner today. Then again, maybe that leads to other problems -- it's always easy to say the right thing to do would have been... when you haven't fought your way through actually making your plan work. [1] http://lists.freebsd.org/pipermail/freebsd-current/2013-February/039709.html -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: options for forcing use of GCC
Em Mon, 28 Apr 2014 08:23:34 -0600, Ian Lepore escreveu On Mon, 2014-04-28 at 22:03 +0800, Julian Elischer wrote: On 4/28/14, 8:05 PM, Ian Lepore wrote: On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: On 4/28/14, 12:30 AM, Ian Lepore wrote: WITH_GCC=yes \ WITH_GNUCXX=yes \ WITHOUT_CLANG=yes \ WITHOUT_CLANG_IS_CC=yes \ forgot to ask.. is this in /etc/make.conf? or elsewhere? Actually in our build system we build in a chroot, and we inject those args into the environment during the builds so that we can have different options for building world versus cross-world within the chroot, but I think the more-normal place would be make.conf. we also use a combination of environment and make.conf in a chroot. though people sometimes talk about a src.conf (or is that src.mk?) but I haven't found that one yet. You must be create in /etc the src.conf and put this knobs there. In my case I would like to use only clang, but have some ports that assume gcc as mandatory. Rizzo -- Ian In theory, /etc/make.conf affects all builds you do -- world, kernel, ports, your own apps, everything -- whereas /etc/src.conf affects only kernel and world. I've heard it said that the reality falls short of that and src.conf settings inappropriately leak into ports builds. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org --- /* **Nilton José RizzoUFRRJ **http://www.rizzo.eng.br http://www.ufrrj.br **http://lattes.cnpq.br/0079460703536198 **/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: options for forcing use of GCC
On Apr 28, 2014, at 11:38 AM, Ian Lepore i...@freebsd.org wrote: On Mon, 2014-04-28 at 10:04 -0600, Warner Losh wrote: On Apr 28, 2014, at 9:52 AM, Kevin Oberman rkober...@gmail.com wrote: On Mon, Apr 28, 2014 at 7:23 AM, Ian Lepore i...@freebsd.org wrote: On Mon, 2014-04-28 at 22:03 +0800, Julian Elischer wrote: On 4/28/14, 8:05 PM, Ian Lepore wrote: On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: On 4/28/14, 12:30 AM, Ian Lepore wrote: WITH_GCC=yes \ WITH_GNUCXX=yes \ WITHOUT_CLANG=yes \ WITHOUT_CLANG_IS_CC=yes \ forgot to ask.. is this in /etc/make.conf? or elsewhere? Actually in our build system we build in a chroot, and we inject those args into the environment during the builds so that we can have different options for building world versus cross-world within the chroot, but I think the more-normal place would be make.conf. we also use a combination of environment and make.conf in a chroot. though people sometimes talk about a src.conf (or is that src.mk?) but I haven't found that one yet. -- Ian In theory, /etc/make.conf affects all builds you do -- world, kernel, ports, your own apps, everything -- whereas /etc/src.conf affects only kernel and world. I've heard it said that the reality falls short of that and src.conf settings inappropriately leak into ports builds. That’s bogus. Port builds define _WITHOUT_SRCCONF which precludes not only including /etc/src.conf, but also disables the while WITH/WITHOUT_FOO mechanism from converting those options into MK_FOO options. I have also heard this, but a grep of ports/Mk finds no matches to src\.conf, so this appears to not be the case. Ports specifically goes out of its way to make sure this doesn’t happen. Perhaps it isn’t going out of its way far enough? It should not be as the whole purpose of src.conf was to have a make configuration that would be used to build the system, but not other things. make.conf already provided for that. If someone can show me a specific, verifiable leak, I’ll look into it. Vague rumors about possible issues that may have existed once upon a time aren’t fruitful to chase. You've known me long enough to know that the Vague rumors... sentence doesn't describe the way I operate. Sorry that I misconstrued the sentiment you were expressing. My bad. I was vague on the fine details, but I remember an email thread where it was specifically shown that the contents of src.conf were affecting ports builds. I just tracked it down [1] and about midway through that thread it materialized that some ports' makefiles include bsd.prog.mk or bsd.lib.mk and that leads to the inappropriate inclusion of src.conf into a port build. So I figured I'd do a quick look for ports makefiles that are including bsd.[lib|prog|subdir].mk : revolution find . -name Make* | xargs grep bsd.*mk | \ grep -v bsd.port| grep -E lib.mk|prog.mk|subdir.mk | wc -l 66 Ah, it is affecting the building of the actual ports, not the bsd.ports.mk system. That’s the kind of detail that’s good to know. In the near future, that won’t happen, unless the port’s controlling Makefile. That's probably not a perfect search, but it looks like there are a few ports that may be perturbed by src.conf settings, plus as was revealed in that thread, if you use /usr/share/mk/bsd.*.mk for your own software (as we do at $work) then your own builds are also affected by src.conf. It is sufficient for me to get the issue. I’d mistakenly thought it was affecting ports build orchestration, but it is affecting anything that causes bsd.own.mk to be included using our make(1). Since I thought it was a reference to the former I was quite confused. Now that I know it is to the latter, I’m no longer confused. I quite agree with the sentiments expressed in that thread that the genesis of the problem is the opt-out nature of src.conf. If it had been designed as an opt-in feature with a handful of /usr/src makefiles opting in as-needed, maybe the situation would be cleaner today. Then again, maybe that leads to other problems -- it's always easy to say the right thing to do would have been... when you haven't fought your way through actually making your plan work. I agree as well… Which is why I have been moving the options into their own file and separating them into different categories. In my tree I have a src.opts.mk file now, which is easy enough to do from where we are in the tree. The trouble is untangling it so that we can set it free from the bsd.*.mk files and have it only influence the /usr/src build without breaking other currently useful features of the /usr/src build. My plan is to move inclusion of src.conf into that file once I work those kinks out. Once that happens, then only make.conf will affect the subordinate builds that opt to use the bsd.*.mk. I’ve been reluctant to commit this next step because to not break things, I’d have to install src.opts.mk, which
Re: options for forcing use of GCC
On Apr 27, 2014, at 10:30 AM, Ian Lepore i...@freebsd.org wrote: On Sun, 2014-04-27 at 22:25 +0800, Julian Elischer wrote: I need to hold off using CLANG for a while at $JOB. We are moving to a newer FBSD in the vicinity of 10.0 but we need to keep the gcc in hte picture for a bit longer before switching. What options do I put into various /etc/make.conf to keep CLANG out ofhte picture until we are ready for it? From reading various posts I see: WITHOUT_CLANG=yes CC=gcc CXX=g++ CPP=gcc -E but that doesn't seem complete to me. For now I want to not compile clang in our official build environment. (and obviously not use it until we are ready for it later this year.) What other hooks do I need to set? Julian We've got the same situation at work. What I'm using right now to build 11-current @ r264151 is this: WITH_GCC=yes \ WITH_GNUCXX=yes \ WITHOUT_CLANG=yes \ WITHOUT_CLANG_IS_CC=yes \ But that's now several weeks out of date, and there are two new knobs I haven't investigated yet: WITH_CLANG_BOOTSTRAP and WITH_GCC_BOOTSTRAP. Just to be clear, you’ll need WITHOUT_CLANG_BOOTSTRAP and WITH_GCC_BOOTSTRAP for -current, but not -stable. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: options for forcing use of GCC
On Sun, 2014-04-27 at 22:25 +0800, Julian Elischer wrote: I need to hold off using CLANG for a while at $JOB. We are moving to a newer FBSD in the vicinity of 10.0 but we need to keep the gcc in hte picture for a bit longer before switching. What options do I put into various /etc/make.conf to keep CLANG out ofhte picture until we are ready for it? From reading various posts I see: WITHOUT_CLANG=yes CC=gcc CXX=g++ CPP=gcc -E but that doesn't seem complete to me. For now I want to not compile clang in our official build environment. (and obviously not use it until we are ready for it later this year.) What other hooks do I need to set? Julian We've got the same situation at work. What I'm using right now to build 11-current @ r264151 is this: WITH_GCC=yes \ WITH_GNUCXX=yes \ WITHOUT_CLANG=yes \ WITHOUT_CLANG_IS_CC=yes \ But that's now several weeks out of date, and there are two new knobs I haven't investigated yet: WITH_CLANG_BOOTSTRAP and WITH_GCC_BOOTSTRAP. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
