Fedora 32 Could Make It Easier To Swap Out GCC, Other Compiler Alternative Options

[phoronix]

Phoronix: Fedora 32 Could Make It Easier To Swap Out GCC, Other Compiler Alternative Options

Adding to the interesting list of proposed features for Fedora 32 would be update-alternatives handling of /usr/bin/cc and /usr/bin/c++ to more easily and seamlessly allowing pointing them at alternative compilers...

http://www.phoronix.com/scan.php?page=news_item&px=F32-Update-Alternatives-CC

[Volta]

It seems llvm have advantages in some benchmarks. It would be good to have it as an alternative option for Linux systems. Linux gcc vs Linux llvm would be interesting.

[Thaodan]

You don't swap out the compiler with this. The system compiler is still the default and packages expect this.
You just don't change something by hand and compile. Packages are build in a reproduce-able way in a clean chroot that was no manual changes.

[milkylainen]

You don't swap out the compiler with this. The system compiler is still the default and packages expect this.
You just don't change something by hand and compile. Packages are build in a reproduce-able way in a clean chroot that was no manual changes.

You're not making much sense. There aren't much problems replacing the compiler at all.
It's not like you use the desktop compiler to rebuild your Fedora from scratch anyway.
Host building packages from source could depend on a "qualified" series compiler, making it a non issue.

This is like adding a crosstool-ng toolchain at a path, but making it system default instead.
I could not care less if x86 GCC or LLVM Clang is used as a default path compiler.
Or a ARM GCC for that matter.

And of course you change stuff by hand and recompile. I do it all day long.

[Thaodan]

You're not making much sense. There aren't much problems replacing the compiler at all.
It's not like the desktop compiler is used to rebuild your Fedora from scratch anyway.
host source building could depend on the needed compiler, making it a non issue.

This is like adding a crosstool-ng toolchain at a path, but making it system default instead.
I could not care less if x86 GCC or LLVM Clang is used as a default path compiler.
Or a ARM GCC for that matter.

I don't said its an issue changing the compiler in a package but if you do it you force to use the specific compiler you want and not change the system default.
You won't to manual changes inside the build root e.g. running this command.

And of course you change stuff by hand and recompile. I do it all day long.

Sure but not when building packages.

[RahulSundaram]

Sure but not when building packages.

Why not?

Nothing wrong with building packages after running alternatives if you are doing it in a side tag to test out build compatibility for instance

[Thaodan]

Why not?

Nothing wrong with building packages after running alternatives if you are doing it in a side tag to test out build compatibility for instance

Because you have a clean build root that contains no manual changes.
If you want to do such a test you change that in your build system or your package file.

[RahulSundaram]

Because you have a clean build root that contains no manual changes.
If you want to do such a test you change that in your build system or your package file.

Alternatives can be handled by the build system. It doesn't mean manual changes. I am not sure why you think that

[killyou]

That's cool and all but can I get Terminus font back with F32?

[ThanosApostolou]

A bit irrelevant with the specific Fedora change but I have an honest question about changing compilers. If you are using system's libraries like libusb, sqlite, qt, or whatever which are built with gcc and you try to build a project with clang/llvm (without rebuilding all these libraries with clang/llvm), won't this lead to breakages and undefined problems? I've read that you should always build the libraries and your own project with the same compiler (at least for c++, I'm not sure about c) and I think that's the main argument for the necessity of things like vcpkg.