> Similarly, the bundled `cc`s with classic Unices (if they were provided at all
It has been a generation since it was common for people to pay for Unix, and then pay more for shitty developer tools.
That gcc has gone from savior to legacy in that time is a huge testament to the value the open source world has created. But I think people forget the bad old days pretty quickly.
HP-UX, Aix, Solaris and mainframes POSIX environments are still around.
Additionally, embedded also has plenty of POSIX like OSes that arent' Linux based.
Re:When can glibc be built with Clang?
by hackerbrother on Thursday October 14, 2021 @09:10PM
(#28872619)
AIX is doing a lot better than HP-UX and Solaris are. In relative terms.
Re:When can glibc be built with Clang?
by Ericson2314 on Friday October 15, 2021 @12:15AM
(#28874214)
> That gcc has gone from savior to legacy in that time is a huge testament to the value the open source world has created
I hope GNU can turn itself around, but because having n+1 competing FOSS implementations is a huge boost. I just fear it is not a sustainable situation.
libgccjit and the new rust backend is a good sign.
Re:When can glibc be built with Clang?
by GoblinSlayer on Friday October 15, 2021 @05:38AM
(#28875936)
That's exactly an illustration that a few competitors is unhealthy for the ecosystem, and llvm isn't going to evolve as fast as it did.
Re:When can glibc be built with Clang?
by Ericson2314 on Friday October 15, 2021 @04:19PM
(#28882667)
If LLVM vanquishes GCC, you mean?
Re:When can glibc be built with Clang?
by eschaton on Thursday October 14, 2021 @09:53PM
(#28873081)
The thing is, you didn’t pay more for shitty developer tools. You paid more for good tools. The system compiler existed solely to enable kernel rebuilds prior to the advent of loadable kernel modules on most vendor UNIX platforms.
Edit - also, lack of updates. POSIX added a new feature to a tool 5 years ago? Well, the built-in tool that came with your classic Unix probably still doesn't support it yet. The GNU tool does though.
If your build system effectively relies on GNU `make` because 75% of the other `make` implementations out there either barf on your makefile, or don't run the build steps correctly, despite it being valid according to the spec; and GNU `make` has a bunch of features that are really powerful and would allow you do some complex things more easily, or even do them at all; then why not just actually rely on GNU `make` and use the extensions?
Similarly, the bundled `cc`s with classic Unices (if they were provided at all) frequently had weird bugs or poor code generation that would go unfixed for years. If `gcc` was the only compiler you could rely on a) your users having access to, and b) to correctly compile your code; and it has a bunch of really cool features that make your code smaller or faster or cleaner, it's hard to resist that. Your code is still portable, because `gcc` is portable, and Free.