18 ms·

The title is highly misleading. First, it's the ancient GCC 4.2.1 from 2007. Next, it's removed from the FreeBSD build system, which means it's no longer used i

The title is highly misleading. First, it's the ancient GCC 4.2.1 from 2007. Next, it's removed from the FreeBSD build system, which means it's no longer used in the internal development of FreeBSD and you can no longer build FreeBSD with GCC. Meanwhile, GCC is still maintained for userspace and the latest GCC 9 is included in the FreeBSD Port [0], you can install it on your machine for your personal use. Finally, the commit message said "At this time all supported architectures either use in-tree Clang, or rely on external toolchain (i.e., a contemporary GCC version from ports)", so I assume even with GCC support removed, you can still build FreeBSD, if you insist, with an external copy of modern GCC. Suggested alternative title: FreeBSD has Removed GCC from Build Infrastructure. [0] https://github.com/freebsd/freebsd-ports/blob/master/Mk/bsd.gcc.mk https://github.com/freebsd/freebsd-ports/blob/master/Mk/bsd....

ianai 7y ago
Is it all licensing making the push away from gcc?
- lvh 7y ago
  Depends on how you look at it. It's that particular old version of GCC in base because of licensing, yes -- but that old version is now effectively obsolete, so there's a technical reason (originally forced from licensing) to move away from it. That said: it's good to remember how much of a breath of fresh air clang was way back when. Error messages in that era of GCC were _terrible_. Clang showed up with colorized error messages and ASCII art arrows and it felt like magic. So, sure, licensing alone would have been a fine reason for base to do what it did, but I don't think it's fair to characterize it as _just_ licensing. GCC has made huge improvements since then, but those are only visible in ports (which has always had and continues to have modern GCC). Which I guess you could argue makes it a licensing issue? :-)
  - clarry 7y ago
    > That said: it's good to remember how much of a breath of fresh air clang was way back when. Error messages in that era of GCC were _terrible_. I disagree; I think clang set a trend and now GCC's error message are worse than they used to be. In the recent days I've seriously considered patching them out because I'm getting really tired of the wall of text of useless suggestions, macro expansion, etc. that hides the actual error. 99% of the time I just need to see which line my error originates from (before any macro expansion) and I can follow the chain manually in the remaining 1% of cases. What's happening now is that I have a line with an error, and I get 50 lines of trash output among which the actual error is buried. And trying to jump to the error in my editor has me jump through headers, #include rows, and other garbage, sometimes missing the original error line entirely! It's ridiculous. The suggestions are also largely either wrong or so obvious that they have only negative value. It's just clutter. Same goes for the ascii art arrows. Just clutter, making it harder to see relevant things. I can see these messages being helpful for a total newbie who's still acquainting themselves with the standard library and figuring out the basics of the language, but for me (writing C daily for a living, and as a hobby for the past 15+ years) it's just getting in the way.
    - dman 7y ago
      Perhaps users should be given a mechanism for configuring the error printing :)
    - Avamander 7y ago
      I can't help but be reminded of https://xkcd.com/1172/ https://xkcd.com/1172/
      - JdeBP 7y ago
        It's a pity that you weren't instead reminded of -fno-color-diagnostics, -fno-caret-diagnostics, and -fno-diagnostics-show-note-include-stack. You could have told clarry about them. (-:
  - guenthert 7y ago
    In which way terrible? Error messages for C++ were at times unhelpful, but I can't remember being dissatisfied with those for C. Outside the Desktop environment, is there much C++ code in the FreeBSD system?
    - lvh 7y ago
      I was making a general comment about clang vs gcc: the push to clang was not exclusive to FreeBSD.
    - JdeBP 7y ago
      devd is C++, and it is not alone. Unfortunately, the dynamically-linkable C++ runtime library is in the wrong place, and not in the same place as the C runtime library, so things like devd have to be statically linked. But the clang switch was not motivated by its C++ error messages, to my knowledge.
  - JdeBP 7y ago
    I've recently found something to dislike about the coloured error messages. The default colour is restored after the newline, rather than before it. * https://github.com/llvm-mirror/clang/blob/6803cc1958b56e0bd5a8139fd3252d5042ca37b9/lib/Frontend/TextDiagnostic.cpp#L1264 https://github.com/llvm-mirror/clang/blob/6803cc1958b56e0bd5... I have recently set DECSCNM on in my terminal(s), which inverts everything, effectively swapping the foreground and background colours. The clang error messages now come out with unsightly large streaks of extraneous colour, as freshly erased lines caused by scrolling fill with the colour that clang has not yet turned off. clang was always doing this. But when it's the background colour it's more visible. It would be such a simple fix, that's actually in line with code elsewhere in the same class. I wonder how many years it will take to get it changed.
  - loeg 7y ago
    IMO, still very much a licensing issue. Modern GPL3 GCC versions produce superior debuginfo as compared with Clang, in 2020, and the error messages and optimizations are currently competitive between the two. The ancient GPL2 GCC4.2.1 (C) compiled much faster than the modern Clang (C++), but I don't know if that still holds true for newer versions of GCC. I have heard that the LLD (LLVM linker) is much faster than either ld.bfd or ld.gold.
- ethelward 7y ago
  IIRC, yes; it was the last version under GPLv2.
  - alerighi 7y ago
    What is the problem of using a GPLv3 compiler? Only political reason, since FreeBSD is still an open source project and they can use GPLv3 software without any problem. Not only that, but even proprietary software can be built with a GPL compiler, the binaries produced by the compiler are not considered derived work that must be covered by the same GPL license, so if Microsoft wanst to build Windows with GCC for example they can do that, provided that they don't link in the executable produced GPL code (e.g. glibc).
    - lazyier 7y ago
      The legal subject of licensing GPLv3 is a lot more nuanced then you are indicating. One example of this is that while the license can explicitly allow proprietary software to link to a library it cannot explicitly deny proprietary software linking to a library. Copyright law defines what is and what isn't derivative works, not licenses. And copyright licenses are fundamentally limited to copyright law. But there are technical reasons to avoid using GCC nowadays as well. The GNU people have built in shitty anti-features into GCC suite, ostensibly to limit the ability of proprietary software to incorporate GCC into their products. LLVM, which is what CLang uses, was partially a response to the artificial technical limitations intentionally imposed on users by the GNU GCC authors.
      - Avamander 7y ago
        I don't see it as an anti-feature.
      - cycloptic 7y ago
        Don't write proprietary compilers. You can thank GCC for mostly eliminating that possibility in the years before clang. Now we are dealing with that again.
      - 7y ago
kevans91 7y ago
> [...] so I assume even with GCC support removed, you can still build FreeBSD, if you insist, with an external copy of modern GCC. Indeed- "external toolchain" includes gcc6[0] and gcc9[1] ports that can be used specifically for building the FreeBSD base system. These are mostly easy to use, install the flavor for whatever architecture you're building and specify CROSS_TOOLCHAIN=<arch>-gcc6 when you build. More/better/complete information (and examples!) at [2]. [0] https://www.freshports.org/devel/freebsd-gcc6 https://www.freshports.org/devel/freebsd-gcc6 [1] https://www.freshports.org/devel/freebsd-gcc9 https://www.freshports.org/devel/freebsd-gcc9 [2] https://wiki.freebsd.org/ExternalToolchain https://wiki.freebsd.org/ExternalToolchain
- grapeli23 7y ago
  What compiler is used to build blas and lapack, as well as a whole lot of programming based on them like numpy, scipy, julia, etc.?
  - loeg 7y ago
    That's encoded in each individual port. lapack, for example, has USES=fortran[1]. That invokes Uses/fortran.mk[2] and accepts the ports-default fortran compiler, FORTRAN_DEFAULT, which is definedin bsd.default-versions.mk[3] as gfortran (GCC). [1]: https://svnweb.freebsd.org/ports/head/math/lapack/Makefile?revision=507372&view=markup#l21 https://svnweb.freebsd.org/ports/head/math/lapack/Makefile?r... [2]: https://svnweb.freebsd.org/ports/head/Mk/Uses/fortran.mk?revision=497798&view=markup https://svnweb.freebsd.org/ports/head/Mk/Uses/fortran.mk?rev... [3]: https://svnweb.freebsd.org/ports/head/Mk/bsd.default-versions.mk?revision=525000&view=markup#l43 https://svnweb.freebsd.org/ports/head/Mk/bsd.default-version...
  - kevans91 7y ago
    Nothing changes here- this is solely about removing GCC 4.2 from the base/ repository; ports are almost entirely unaffected, and the GCC ecosystem in ports is fairly healthy.
simias 7y ago
I disagree, for anybody who knows how FreeBSD works the title is perfectly clear IMO. They removed FreeBSD from the base system. Of course you can still build GCC from ports, but that's not part of the base OS. It's as if MacOS decided to stop shipping bash by default. Of course you'll still be able to install it yourself, but it's not part of the OS anymore and you can't rely on it being available and supported. FreeBSD is not Linux, it's a full OS, not just a kernel. There's a very clear line between what's part of the base system and what's not.
- lloeki 7y ago
  > It's as if MacOS decided to stop shipping bash by default. More precisely, it’s as if macOS stopped shipping GCC in the CLT. Oh wait, they did exactly that already, the last one being gcc 4.2 on Darwin 11, after that a GCC command is still present but it’s just a front to llvm. https://github.com/archmac/packages/blob/master/core/apple-gcc/PKGBUILD https://github.com/archmac/packages/blob/master/core/apple-g...
  - fullstop 7y ago
    > It's as if MacOS decided to stop shipping bash by default. They switched from tcsh to bash, so it's not out of the question. edit: looks like tcsh is still available, but not the default.
    - michaelsbradley 7y ago
      https://support.apple.com/en-us/HT208050 https://support.apple.com/en-us/HT208050
- ori_b 7y ago
  > I disagree, for anybody who knows how FreeBSD works That excludes the bulk of this site's readers.
  - oefrha 7y ago
    It’s a good time for the bulk of this site’s readers to learn something about the BSD philosophy then. Edit: This comment was not meant to be snarky.
umanwizard 7y ago
It was entirely removed from the operating system. As with most general-purpose operating systems, nothing prevents FreeBSD users from installing third-party software, including GCC. This does not mean that GCC is still part of the OS.
- agapon 7y ago
  There are many ways to install third-party software. Some are harder: download source and build from it yourself (while handling any cross-platform issues, etc). Some are easier: just install from an OS supplied package. The latter still works for GCC on FreeBSD.
  - umanwizard 7y ago
    It is a ports tree provided package, not an OS supplied package. Ports are not considered part of the OS.
    - agapon 7y ago
      I'd argue that the software provided via the ports is not part of the OS. But the FreeBSD ports themselves (and official packages built from them) can be considered part of FreeBSD. P.S. You can disagree with me and state your point, but you do not have to downvote me.
      - umanwizard 7y ago
        I didn't downvote you: https://i.imgur.com/PPNWIqA.png https://i.imgur.com/PPNWIqA.png
gcoleman 7y ago
OP here. I assumed knowledge of how FreeBSD works and the ongoing efforts to move to clang. I can see how the title could be misleading for people who are not familiar. As others have pointed out "FreeBSD has removed GCC from the. base system" would be a better title.
- cryptonector 7y ago
  The damned version number should be in the title.
  - dang 7y ago
    That would imply that a different version might be left in.
loeg 7y ago
I don't know what to tell you. As someone who develops and uses FreeBSD, the title is true on its face and long-awaited. Yes, "from the base system as a supported base compiler" is implicit context here that someone outside of that community might not understand, but I think everyone familiar with FreeBSD can understand the headline, or failing that, the body of the (short) commit message and have a good understanding of the truth.
dang 7y ago
Ok, we've put the base system in the title above.

ianai 7y ago

Is it all licensing making the push away from gcc?

lvh 7y ago
Depends on how you look at it. It's that particular old version of GCC in base because of licensing, yes -- but that old version is now effectively obsolete, so there's a technical reason (originally forced from licensing) to move away from it. That said: it's good to remember how much of a breath of fresh air clang was way back when. Error messages in that era of GCC were _terrible_. Clang showed up with colorized error messages and ASCII art arrows and it felt like magic. So, sure, licensing alone would have been a fine reason for base to do what it did, but I don't think it's fair to characterize it as _just_ licensing. GCC has made huge improvements since then, but those are only visible in ports (which has always had and continues to have modern GCC). Which I guess you could argue makes it a licensing issue? :-)
- clarry 7y ago
  > That said: it's good to remember how much of a breath of fresh air clang was way back when. Error messages in that era of GCC were _terrible_. I disagree; I think clang set a trend and now GCC's error message are worse than they used to be. In the recent days I've seriously considered patching them out because I'm getting really tired of the wall of text of useless suggestions, macro expansion, etc. that hides the actual error. 99% of the time I just need to see which line my error originates from (before any macro expansion) and I can follow the chain manually in the remaining 1% of cases. What's happening now is that I have a line with an error, and I get 50 lines of trash output among which the actual error is buried. And trying to jump to the error in my editor has me jump through headers, #include rows, and other garbage, sometimes missing the original error line entirely! It's ridiculous. The suggestions are also largely either wrong or so obvious that they have only negative value. It's just clutter. Same goes for the ascii art arrows. Just clutter, making it harder to see relevant things. I can see these messages being helpful for a total newbie who's still acquainting themselves with the standard library and figuring out the basics of the language, but for me (writing C daily for a living, and as a hobby for the past 15+ years) it's just getting in the way.
  - dman 7y ago
    Perhaps users should be given a mechanism for configuring the error printing :)
  - Avamander 7y ago
    I can't help but be reminded of https://xkcd.com/1172/ https://xkcd.com/1172/
    - JdeBP 7y ago
      It's a pity that you weren't instead reminded of -fno-color-diagnostics, -fno-caret-diagnostics, and -fno-diagnostics-show-note-include-stack. You could have told clarry about them. (-:
- guenthert 7y ago
  In which way terrible? Error messages for C++ were at times unhelpful, but I can't remember being dissatisfied with those for C. Outside the Desktop environment, is there much C++ code in the FreeBSD system?
  - lvh 7y ago
    I was making a general comment about clang vs gcc: the push to clang was not exclusive to FreeBSD.
  - JdeBP 7y ago
    devd is C++, and it is not alone. Unfortunately, the dynamically-linkable C++ runtime library is in the wrong place, and not in the same place as the C runtime library, so things like devd have to be statically linked. But the clang switch was not motivated by its C++ error messages, to my knowledge.
- JdeBP 7y ago
  I've recently found something to dislike about the coloured error messages. The default colour is restored after the newline, rather than before it. * https://github.com/llvm-mirror/clang/blob/6803cc1958b56e0bd5a8139fd3252d5042ca37b9/lib/Frontend/TextDiagnostic.cpp#L1264 https://github.com/llvm-mirror/clang/blob/6803cc1958b56e0bd5... I have recently set DECSCNM on in my terminal(s), which inverts everything, effectively swapping the foreground and background colours. The clang error messages now come out with unsightly large streaks of extraneous colour, as freshly erased lines caused by scrolling fill with the colour that clang has not yet turned off. clang was always doing this. But when it's the background colour it's more visible. It would be such a simple fix, that's actually in line with code elsewhere in the same class. I wonder how many years it will take to get it changed.
- loeg 7y ago
  IMO, still very much a licensing issue. Modern GPL3 GCC versions produce superior debuginfo as compared with Clang, in 2020, and the error messages and optimizations are currently competitive between the two. The ancient GPL2 GCC4.2.1 (C) compiled much faster than the modern Clang (C++), but I don't know if that still holds true for newer versions of GCC. I have heard that the LLD (LLVM linker) is much faster than either ld.bfd or ld.gold.
ethelward 7y ago
IIRC, yes; it was the last version under GPLv2.
- alerighi 7y ago
  What is the problem of using a GPLv3 compiler? Only political reason, since FreeBSD is still an open source project and they can use GPLv3 software without any problem. Not only that, but even proprietary software can be built with a GPL compiler, the binaries produced by the compiler are not considered derived work that must be covered by the same GPL license, so if Microsoft wanst to build Windows with GCC for example they can do that, provided that they don't link in the executable produced GPL code (e.g. glibc).
  - lazyier 7y ago
    The legal subject of licensing GPLv3 is a lot more nuanced then you are indicating. One example of this is that while the license can explicitly allow proprietary software to link to a library it cannot explicitly deny proprietary software linking to a library. Copyright law defines what is and what isn't derivative works, not licenses. And copyright licenses are fundamentally limited to copyright law. But there are technical reasons to avoid using GCC nowadays as well. The GNU people have built in shitty anti-features into GCC suite, ostensibly to limit the ability of proprietary software to incorporate GCC into their products. LLVM, which is what CLang uses, was partially a response to the artificial technical limitations intentionally imposed on users by the GNU GCC authors.
    - Avamander 7y ago
      I don't see it as an anti-feature.
    - cycloptic 7y ago
      Don't write proprietary compilers. You can thank GCC for mostly eliminating that possibility in the years before clang. Now we are dealing with that again.
    - 7y ago

kevans91 7y ago

> [...] so I assume even with GCC support removed, you can still build FreeBSD, if you insist, with an external copy of modern GCC. Indeed- "external toolchain" includes gcc6[0] and gcc9[1] ports that can be used specifically for building the FreeBSD base system. These are mostly easy to use, install the flavor for whatever architecture you're building and specify CROSS_TOOLCHAIN=<arch>-gcc6 when you build. More/better/complete information (and examples!) at [2]. [0] https://www.freshports.org/devel/freebsd-gcc6 https://www.freshports.org/devel/freebsd-gcc6 [1] https://www.freshports.org/devel/freebsd-gcc9 https://www.freshports.org/devel/freebsd-gcc9 [2] https://wiki.freebsd.org/ExternalToolchain https://wiki.freebsd.org/ExternalToolchain

grapeli23 7y ago
What compiler is used to build blas and lapack, as well as a whole lot of programming based on them like numpy, scipy, julia, etc.?
- loeg 7y ago
  That's encoded in each individual port. lapack, for example, has USES=fortran[1]. That invokes Uses/fortran.mk[2] and accepts the ports-default fortran compiler, FORTRAN_DEFAULT, which is definedin bsd.default-versions.mk[3] as gfortran (GCC). [1]: https://svnweb.freebsd.org/ports/head/math/lapack/Makefile?revision=507372&view=markup#l21 https://svnweb.freebsd.org/ports/head/math/lapack/Makefile?r... [2]: https://svnweb.freebsd.org/ports/head/Mk/Uses/fortran.mk?revision=497798&view=markup https://svnweb.freebsd.org/ports/head/Mk/Uses/fortran.mk?rev... [3]: https://svnweb.freebsd.org/ports/head/Mk/bsd.default-versions.mk?revision=525000&view=markup#l43 https://svnweb.freebsd.org/ports/head/Mk/bsd.default-version...
- kevans91 7y ago
  Nothing changes here- this is solely about removing GCC 4.2 from the base/ repository; ports are almost entirely unaffected, and the GCC ecosystem in ports is fairly healthy.

simias 7y ago

I disagree, for anybody who knows how FreeBSD works the title is perfectly clear IMO. They removed FreeBSD from the base system. Of course you can still build GCC from ports, but that's not part of the base OS. It's as if MacOS decided to stop shipping bash by default. Of course you'll still be able to install it yourself, but it's not part of the OS anymore and you can't rely on it being available and supported. FreeBSD is not Linux, it's a full OS, not just a kernel. There's a very clear line between what's part of the base system and what's not.

lloeki 7y ago
> It's as if MacOS decided to stop shipping bash by default. More precisely, it’s as if macOS stopped shipping GCC in the CLT. Oh wait, they did exactly that already, the last one being gcc 4.2 on Darwin 11, after that a GCC command is still present but it’s just a front to llvm. https://github.com/archmac/packages/blob/master/core/apple-gcc/PKGBUILD https://github.com/archmac/packages/blob/master/core/apple-g...
- fullstop 7y ago
  > It's as if MacOS decided to stop shipping bash by default. They switched from tcsh to bash, so it's not out of the question. edit: looks like tcsh is still available, but not the default.
  - michaelsbradley 7y ago
    https://support.apple.com/en-us/HT208050 https://support.apple.com/en-us/HT208050
ori_b 7y ago
> I disagree, for anybody who knows how FreeBSD works That excludes the bulk of this site's readers.
- oefrha 7y ago
  It’s a good time for the bulk of this site’s readers to learn something about the BSD philosophy then. Edit: This comment was not meant to be snarky.

umanwizard 7y ago

It was entirely removed from the operating system. As with most general-purpose operating systems, nothing prevents FreeBSD users from installing third-party software, including GCC. This does not mean that GCC is still part of the OS.

agapon 7y ago
There are many ways to install third-party software. Some are harder: download source and build from it yourself (while handling any cross-platform issues, etc). Some are easier: just install from an OS supplied package. The latter still works for GCC on FreeBSD.
- umanwizard 7y ago
  It is a ports tree provided package, not an OS supplied package. Ports are not considered part of the OS.
  - agapon 7y ago
    I'd argue that the software provided via the ports is not part of the OS. But the FreeBSD ports themselves (and official packages built from them) can be considered part of FreeBSD. P.S. You can disagree with me and state your point, but you do not have to downvote me.
    - umanwizard 7y ago
      I didn't downvote you: https://i.imgur.com/PPNWIqA.png https://i.imgur.com/PPNWIqA.png

gcoleman 7y ago

OP here. I assumed knowledge of how FreeBSD works and the ongoing efforts to move to clang. I can see how the title could be misleading for people who are not familiar. As others have pointed out "FreeBSD has removed GCC from the. base system" would be a better title.

cryptonector 7y ago
The damned version number should be in the title.
- dang 7y ago
  That would imply that a different version might be left in.

loeg 7y ago

I don't know what to tell you. As someone who develops and uses FreeBSD, the title is true on its face and long-awaited. Yes, "from the base system as a supported base compiler" is implicit context here that someone outside of that community might not understand, but I think everyone familiar with FreeBSD can understand the headline, or failing that, the body of the (short) commit message and have a good understanding of the truth.

dang 7y ago

Ok, we've put the base system in the title above.