5 ms·

The State of Toolchains in OpenBSD

58 points by fcambus 5y ago

webaholic 5y ago
Why was the compromise made for LLVM 10 with the Apache license and not for GCC with the v3 GPL license?
- wahern 5y ago
  No compromise, AFAIU. They felt they had no choice but to upgrade to a more modern compiler, and they preferred clang+APL2 over gcc+GPLv3. Apache 2.0 still violates their licensing policy. Technically, GPLv2 also violated their licensing policy. They historically used GPL'd software like gcc when there were no viable alternatives and doing without wasn't acceptable either. EDIT: See https://marc.info/?l=openbsd-misc&m=159514079929237&w=2 https://marc.info/?l=openbsd-misc&m=159514079929237&w=2
- protomyth 5y ago
  Probably because of the drm code requirements and only having a choice between GPL v3 (gcc) or Apache 2 (llvm).
- mwfunk 5y ago
  I would imagine that many or most (or all?) OpenBSD developers consider the Apache license less than ideal but GPLv3 counterproductive or even malicious. Not a tough choice from that perspective. I'm not advocating for or against anything, just stating common reasoning amongst BSD folks.
ndesaulniers 5y ago
I just reviewed 2 m68k patches to LLVM today; I expect we should be able to build the m68k port of the Linux kernel with LLVM soon.
xvilka 5y ago
I hope they will do the transition from CVS too.
- yjftsjthsd-h 5y ago
  Dunno about "soon", but I'd assumed that was the ultimate goal of Got (https://gameoftrees.org/ https://gameoftrees.org/)
  - gbrown_ 5y ago
    There may be OpenBSD devs working on and using Got, but the OpenBSD project has never declared that it intends to move to it.
- deleted 5y ago
  [deleted]
- Wxc2jjJmST9XWWL 5y ago
  Sorry for a long answer to a one-liner. Whatever people's opinion about what they should use... CVS works for them, everyone of their users and developers is used to it, and they've been self hosting their code for ... 15 years at this point... 20 years? Even more? How many projects can actually say that? Using OpenBSD for servers at times their use of CVS has never been an issue for me. So I get it, it's not the newest tool around, but if it works, is understood, maybe there's no immediate need to switch? The same crowd which says "they should just use git already", would probably follow up with "and how come perl is part of the base system and the pkg manager is written in it?... could we get Rust into the kernel while we're at it?" OpenBSD's conservatism is what makes the system so immensely well documented, vetted, therefore secure and easy to use. They may switch at some point, and if they do it will be swift, and done right. But if I think about it: as a user I don't really care. It's not a huge deal to me what they're using for source control.
  - wrycoder 5y ago
    I agree. They had a project, OpenCVS, to rewrite CVS. It was eventually abandoned - apparently the team felt the gain wasn’t worth the effort. For a tightly knit team working with a central repository, CVS is just fine. Moving Python from CVS to SVN to Hg to Git gained nothing and made the development process so complicated that it was necessary to introduce even more complication by scripting it.
ggm 5y ago
The licence mailthread in the LLVM list (pointed to in the article) is brutal. Moving to a licence otherwise deprecated is a huge deal. For a "no compromise" community (OpenBSD), its huge++ But, the pragmatism appears useful: without this, modern hardware cannot be compiled to optimally. It was a least-worst choice decision.
- ansible 5y ago
  If LLVM is now not a blocker, I wonder if they'll be able to start using Rust for development. At least as an experiment.
  - protomyth 5y ago
    Rust's inability to compile itself on 32-bit machines was a blocker given the all OpenBSD supported platforms are self-hosted and releases must be built using the base system compiler on real hardware. No cross-compilation, no emulators. requirement.
    - ansible 5y ago
      Ooooo... that's right. I was reading about a related issue with (IIRC) Rust v1.51 on some 32-bit platform where they were running out of memory. Never mind how long that would take.
yjftsjthsd-h 5y ago
I'm curious whether it would be okay to optionally support other toolchains. For example, if openbsd works when built with GCC 4.x but also can build with GCC 10.x, it remains "safe" with the older GPLv2 GCC but a person wanting performance could opt to use the latest version. Or is that tempting a slippery slope?
- nix23 5y ago
  Well try it, that's the good stuff with bsd's, keep your base-system clean and just compile the ports with gcc. Your system will still always boot. something like that (but gcc instead of clang) in your make.conf: CC=clang11 CXX=clang++11 CPP=clang-cpp11
pjmlp 5y ago
> The main reason has to be newer C and C++ standards support. Ironically clang is now behind gcc and VC++ regarding newer ISO C++ support. https://en.cppreference.com/w/cpp/compiler_support https://en.cppreference.com/w/cpp/compiler_support

58 points by fcambus 5y ago

webaholic 5y ago

Why was the compromise made for LLVM 10 with the Apache license and not for GCC with the v3 GPL license?

wahern 5y ago
No compromise, AFAIU. They felt they had no choice but to upgrade to a more modern compiler, and they preferred clang+APL2 over gcc+GPLv3. Apache 2.0 still violates their licensing policy. Technically, GPLv2 also violated their licensing policy. They historically used GPL'd software like gcc when there were no viable alternatives and doing without wasn't acceptable either. EDIT: See https://marc.info/?l=openbsd-misc&m=159514079929237&w=2 https://marc.info/?l=openbsd-misc&m=159514079929237&w=2
protomyth 5y ago
Probably because of the drm code requirements and only having a choice between GPL v3 (gcc) or Apache 2 (llvm).
mwfunk 5y ago
I would imagine that many or most (or all?) OpenBSD developers consider the Apache license less than ideal but GPLv3 counterproductive or even malicious. Not a tough choice from that perspective. I'm not advocating for or against anything, just stating common reasoning amongst BSD folks.

ndesaulniers 5y ago

I just reviewed 2 m68k patches to LLVM today; I expect we should be able to build the m68k port of the Linux kernel with LLVM soon.

xvilka 5y ago

I hope they will do the transition from CVS too.

yjftsjthsd-h 5y ago
Dunno about "soon", but I'd assumed that was the ultimate goal of Got (https://gameoftrees.org/ https://gameoftrees.org/)
- gbrown_ 5y ago
  There may be OpenBSD devs working on and using Got, but the OpenBSD project has never declared that it intends to move to it.
deleted 5y ago
[deleted]
Wxc2jjJmST9XWWL 5y ago
Sorry for a long answer to a one-liner. Whatever people's opinion about what they should use... CVS works for them, everyone of their users and developers is used to it, and they've been self hosting their code for ... 15 years at this point... 20 years? Even more? How many projects can actually say that? Using OpenBSD for servers at times their use of CVS has never been an issue for me. So I get it, it's not the newest tool around, but if it works, is understood, maybe there's no immediate need to switch? The same crowd which says "they should just use git already", would probably follow up with "and how come perl is part of the base system and the pkg manager is written in it?... could we get Rust into the kernel while we're at it?" OpenBSD's conservatism is what makes the system so immensely well documented, vetted, therefore secure and easy to use. They may switch at some point, and if they do it will be swift, and done right. But if I think about it: as a user I don't really care. It's not a huge deal to me what they're using for source control.
- wrycoder 5y ago
  I agree. They had a project, OpenCVS, to rewrite CVS. It was eventually abandoned - apparently the team felt the gain wasn’t worth the effort. For a tightly knit team working with a central repository, CVS is just fine. Moving Python from CVS to SVN to Hg to Git gained nothing and made the development process so complicated that it was necessary to introduce even more complication by scripting it.

ggm 5y ago

The licence mailthread in the LLVM list (pointed to in the article) is brutal. Moving to a licence otherwise deprecated is a huge deal. For a "no compromise" community (OpenBSD), its huge++ But, the pragmatism appears useful: without this, modern hardware cannot be compiled to optimally. It was a least-worst choice decision.

ansible 5y ago
If LLVM is now not a blocker, I wonder if they'll be able to start using Rust for development. At least as an experiment.
- protomyth 5y ago
  Rust's inability to compile itself on 32-bit machines was a blocker given the all OpenBSD supported platforms are self-hosted and releases must be built using the base system compiler on real hardware. No cross-compilation, no emulators. requirement.
  - ansible 5y ago
    Ooooo... that's right. I was reading about a related issue with (IIRC) Rust v1.51 on some 32-bit platform where they were running out of memory. Never mind how long that would take.

yjftsjthsd-h 5y ago

I'm curious whether it would be okay to optionally support other toolchains. For example, if openbsd works when built with GCC 4.x but also can build with GCC 10.x, it remains "safe" with the older GPLv2 GCC but a person wanting performance could opt to use the latest version. Or is that tempting a slippery slope?

nix23 5y ago
Well try it, that's the good stuff with bsd's, keep your base-system clean and just compile the ports with gcc. Your system will still always boot. something like that (but gcc instead of clang) in your make.conf: CC=clang11 CXX=clang++11 CPP=clang-cpp11

pjmlp 5y ago

> The main reason has to be newer C and C++ standards support. Ironically clang is now behind gcc and VC++ regarding newer ISO C++ support. https://en.cppreference.com/w/cpp/compiler_support https://en.cppreference.com/w/cpp/compiler_support