Re: Removing default build of gcc
On Fri, 25 Jan 2013, David Chisnall wrote:
In 10.0, the plan is not to ship any GPL'd code, so I'd like to
start disconnecting things from the default build, starting with
gcc. I've been running a gcc-free system for a while, and I think
all of the ports that don't build with clang are now explicitly
depending on gcc.
I am surprised you did not run into problems with the ports infra-
structure, for there definitely are some still.
The patch below is the first in a series of contributions to address
this (though this specific one would not have lead to a failure -- yet).
I plan on shortly committing patches by Yamaya Takashi, destilled
from PR 175252, which will address further issues.
Gerald
Author: gerald
Date: Sat Mar 2 01:06:15 2013
New Revision: 313177
URL: http://svnweb.freebsd.org/changeset/ports/313177
Log:
Remove a bogus old check that assumes that every version of FreeBSD has
GCC in the base.
Adjust a comment, now describing the real purpose of the code remaining
in that block.
PR: 175252
Modified:
head/Mk/bsd.gcc.mk
Modified: head/Mk/bsd.gcc.mk
==
--- head/Mk/bsd.gcc.mk Sat Mar 2 00:40:53 2013(r313176)
+++ head/Mk/bsd.gcc.mk Sat Mar 2 01:06:15 2013(r313177)
@@ -143,20 +143,16 @@ IGNORE= Unknown version of GCC specified
.endif
#
-# Determine current GCCVERSION
+# Initialize _GCC_FOUND${v}.
#
.for v in ${GCCVERSIONS}
. if exists(${LOCALBASE}/bin/gcc${_GCCVERSION_${v}_V:S/.//})
_GCC_FOUND${v}=port
. endif
. if ${OSVERSION} = ${_GCCVERSION_${v}_L} ${OSVERSION}
${_GCCVERSION_${v}_R}
-_GCCVERSION:= ${v}
_GCC_FOUND${v}:= base
. endif
.endfor
-.if !defined(_GCCVERSION)
-IGNORE=Couldn't find your current GCCVERSION
(OSVERSION=${OSVERSION})
-.endif
#
# If the GCC package defined in USE_GCC does not exist, but a later
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Removing default build of gcc
On Fri, Jan 25, 2013 at 03:36:15PM -0500, Pedro Giffuni wrote: I don't care much about gcc in current. clang, even on -9, can't build the following: - most of kde - graphics/GraphicsMagick - editors/emacs21 - www/libxul19 any one of which I would consider showstoppers for making a gcc-less system. mcl ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Removing default build of gcc
Hello; Sorry for top-posting: I am in a mobile device that doesnt know better. I am aware that openoffice is also broken due to stlport. The situation is not too different from the fortran removal: for many reasons it is convenient to use a pre-packaged compiler for many ports. Gcc 4.2.1 is also becoming obsolete and is really difficult to maintain.. Pedro. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Removing default build of gcc
On Sat, Jan 26, 2013 at 02:53:16AM -0600, Mark Linimon wrote: On Fri, Jan 25, 2013 at 03:36:15PM -0500, Pedro Giffuni wrote: I don't care much about gcc in current. clang, even on -9, can't build the following: - most of kde - graphics/GraphicsMagick - editors/emacs21 - www/libxul19 any one of which I would consider showstoppers for making a gcc-less system. IMO this is not the approach we should take in regard to gcc and ports. Ports should use port-provided compiler, and be untangled from the base toolchain. I believe that forcing ports committers to port 20K+ packages to clang is a waste of the FreeBSD resources and is is destined to fail despite the efforts. pgpTHTXzllHoH.pgp Description: PGP signature
Re: Removing default build of gcc
On Fri, Jan 25, 2013 at 02:47:19AM -0600, Mark Linimon wrote: On Fri, Jan 25, 2013 at 08:41:11AM +, David Chisnall wrote: I think all of the ports that don't build with clang are now explicitly depending on gcc. Nope. We switched some of the most notorious failures, but hundreds more remain -- mostly leaf ports. Without the ability to run -exp builds, which I do not currently have, this is extremely premature. I also think this is a bit premature, ports is one issue, second one is that other major archs are still with gcc. Developers should be able to fix sources broken on non-clang archs easily. Once arm/mips/ppc are switched (fingers crossed that it's going to be soon) disabling gcc by default should be easier. Roman ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Removing default build of gcc
On Jan 25, 2013, at 4:31 AM, Konstantin Belousov wrote: On Fri, Jan 25, 2013 at 08:41:11AM +, David Chisnall wrote: Hi All, In 10.0, the plan is not to ship any GPL'd code, so I'd like to start disconnecting things from the default build, starting with gcc. I've been running a gcc-free system for a while, and I think all of the ports that don't build with clang are now explicitly depending on gcc. Does anyone have strong opinions on when would be a good time for head on x86 and x86-64 to default to not building gcc? To clarify: there is no plans to not ship any GPLed code for 10.x. Instead, there are still plans to ship working 10.x. Please do not consider the personal opinion as the statement of the project policy. The goal is to try not to ship GPL'd code in 10. The goal is not to ship 10 without GPL'd code if that results in a broken system. The goal also as articulated at different forum, was for Tier 1 systems. Tier 2 and 3 systems may use GPL code as a fallback if the non-gpl'd code doesn't work on those platforms. That is to say, it is a goal, not an absolute requirement. Warner ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Removing default build of gcc
On Fri, Jan 25, 2013 at 03:36:15PM -0500, Pedro Giffuni wrote: On 01/25/2013 14:59, Konstantin Belousov wrote: On Fri, Jan 25, 2013 at 12:31:39PM -0700, Warner Losh wrote: On Jan 25, 2013, at 4:31 AM, Konstantin Belousov wrote: On Fri, Jan 25, 2013 at 08:41:11AM +, David Chisnall wrote: Hi All, In 10.0, the plan is not to ship any GPL'd code, so I'd like to start disconnecting things from the default build, starting with gcc. I've been running a gcc-free system for a while, and I think all of the ports that don't build with clang are now explicitly depending on gcc. Does anyone have strong opinions on when would be a good time for head on x86 and x86-64 to default to not building gcc? To clarify: there is no plans to not ship any GPLed code for 10.x. Instead, there are still plans to ship working 10.x. Please do not consider the personal opinion as the statement of the project policy. The goal is to try not to ship GPL'd code in 10. The goal is not to ship 10 without GPL'd code if that results in a broken system. The goal also as articulated at different forum, was for Tier 1 systems. Tier 2 and 3 systems may use GPL code as a fallback if the non-gpl'd code doesn't work on those platforms. That is to say, it is a goal, not an absolute requirement. All you said is reasonable and quite coincides with what I thought. Unfortunately, it has very tangential relations to what is proposed to do and to the political agenda declared in the message started the thread. I don't care much about gcc in current. It doesn't seem like the right time to kill it but it is a dead end and we should be using the pre pkg'ed version instead (I know, easier said than done, but the Debian guys did it). Either way, there is no hurry but it is a desirable goal. I am really tired of the constant struggle against the consumation of the FreeBSD as the test-bed for the pre-alpha quality software. E.g., are we fine with broken C++ runtime in 9 ? The libstdc++ issue is really REALLY worrying. I would prefer if the hack to attempt using libstdc++ as a filter library were reverted altogether in 9.x. I had a lots of stress with that issue as some people pointed at my libstdc++ updates as possible root cause. I felt some natural relief when the real cause was found but I certainly wonder why the change was made in 9.x though since it's clear that codebase will not be migrated to libc++. You were finger-pointed due to the rule 'blame the last committer from the VCS log'. Even less so, you were asked about it because you probably knew most about possible cause. I am not worried about the bug itself, which needs a proper identification and fixing. I am indeed wery disappointed regarding the attitude of the person who introduced the bug. Reverting the split may be the best action in my opinion. Both in head and stable. pgp_TsCxdi6uk.pgp Description: PGP signature
Re: Removing default build of gcc
On 2013-01-25 21:54, Pedro Giffuni wrote: ... I am aware a fix is being worked on. I think that as long as the default compiler/C++ library works it is OK to make things easier for other compilers. I am OK with having that change in -current but for 9.x it is simply unacceptable. Actually, clang with libc++ works fine, and both clang and gcc with libstdc++ don't... If the problem is caused by the switchable libsupc++.so backend lib, I would have no trouble with reverting that. But do we know that for sure at this point? I have not spent enough time looking deeply into the issue. I did notice that libsupc++ .So objects get linked into libstdc++.so, even while they are also in libsupc++.so. Maybe that is causing trouble? ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Removing default build of gcc
on 25/01/2013 21:35 Warner Losh said the following: This has been talked about in a vague way for years. Warner, just a nitpick, couldn't resist - sorry, so for years we talked about the magic 10.x release to become GPL-free? Or was it just a goal for 'some day'? -- Andriy Gapon ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Removing default build of gcc
On Jan 25, 2013, at 3:18 PM, Andriy Gapon wrote: on 25/01/2013 21:35 Warner Losh said the following: This has been talked about in a vague way for years. Warner, just a nitpick, couldn't resist - sorry, so for years we talked about the magic 10.x release to become GPL-free? Or was it just a goal for 'some day'? In the talks that we've had at different venues, 10.x has been a short hand for someday. At first it was clear that it was too ambitious to be in 9.0, then later it was a nice goal to have for 10.x, but it isn't a show-stopper for shipping 10.0 if there's still GPL'd code in the tree. Remove as much as possible, as fast as possible, but with the big caveat of without removing features that mattered. clang is nice and all, but it isn't yet a complete replacement for the tier 2/3 platforms for gcc. It is unrealistic to expect that we'll have something that's functional on those platforms in the 10.0 time frame, unless that timeframe is very far in the future. Again, it is the difference between a goal (which we can fail to achieve fully) and a requirement (which gates the release) that's the important distinction here. Core has never set GPL-free as a requirement for 10.x. They haven't even stated, as far as I can recall, that it is a desired goal for the project. The goal has been driven by many stakeholders that can't use GPL today, as well as a recognition that GPL-free is a big selling point in some markets. The more we can do this, in general, the better. However, the drive must also be tempered by the need to keep current things working and not break them needlessly. Which, btw, is the whole reason full external toolchain support is necessary. With that, we can kill three birds with one stone. (1) we can allow users to use the vendor optimized versions of the gcc toolchain, if they want. (2) non-tier 1 platforms could use it to build with known good gcc/binutils versions that may live in ports. ia64 is often mentioned here. (3) We provide a fallback for people that want to use gcc on tier-1 platforms, but newer versions. We've only kinda sorted solved these problems in a kludgy, error-prone tedious manner today, and much work remains to bring the support up to the quality users expect and need from the project. Warner ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
