Fedora 29 Dropping GCC From Their Default Build Root Has Been Causing A Heated Debate

[Weasel]

I don't really get you. I mean you go on and on describing various issues that would happen if you mixed libc:s in Linux/BSD yet you some how manage to look like a question mark when I tell you that it's not supported. What is this, the twilight zone?

Looks like proper words don't get to you, so... I'll play your "game".

I tell you it's supported. My word is of higher authority than yours, thus I must be right? (sarcasm you know)

Your word is not law. Claims are not arguments. And that's all you did: you claimed it's not supported.

You're not an authority who decides what's supported or not. So you telling me it's "not supported" means exactly zero without backup.

In general, only an authority responsible decides whether something is supported or not. And the Linux kernel has done just that: it supports multiple libc by design.

So tell me again why should I listen to what you say is "not supported"? I don't mean that in a negative way, I mean in a logical way. Because that's just a claim, and claims are not arguments.

And for the millionth time, yes you can have as many libc:s on your drives as you like and you can use them as much as you like for what every app or library that you want but what you cannot reliably do is to mix two of them at the same time.

I know, because of deficiencies in ELF and library (userland) API designs. That's kind of my point.

And why would you even want to mix?

Already gave too many examples but it won't hurt one more time eh?

If you prefer glibc, musl, libowfat or something else, why would you want to only link your specific piece of software with it and not your entire dependency chain? E.g the Alpine people prefer musl since it has a lower memory foot print, why on earth would you then bring in an app linked with glibc and thus create the overhead of two libc:s loaded at the same time?

Because not everyone has this idiotic idea to recompile the entire userland for each distro. In fact, if you have to recompile it or link statically, this proves the design is rotten at its core. It's not "how Linux works" at all, it's not intentional, it's a mistake that can't be easily fixed. It's "how Linux is dragged down by ELF and shitty library interfaces" instead. It's dragged down by it, not "crappy on purpose".

Ever considered that some people (3rd party dev) just wants to compile their software once and have it work on all Linux-compatible distros? Really? It hasn't occurred to you after I explicitly told you it's how the majority works? (and why Linux lacks so many apps, this is a statistical fact, if you compare with other ecosystems)

So what happens if my app depends on some feature from musl and yet your distro ships glibc? Just like on Windows, I simply supply musl with my app, right? In Windows "it just works".

Oops, not on Linux, it might cause conflicts. You know, stuff I already said. Rotten design.

A "design" whose solution is to "recompile on each distro" or to "link statically everything" is rotten and stinks like putrid fish

[F.Ultra]

Looks like proper words don't get to you, so... I'll play your "game".

I tell you it's supported. My word is of higher authority than yours, thus I must be right? (sarcasm you know)

Your word is not law. Claims are not arguments. And that's all you did: you claimed it's not supported.

You're not an authority who decides what's supported or not. So you telling me it's "not supported" means exactly zero without backup.

In general, only an authority responsible decides whether something is supported or not. And the Linux kernel has done just that: it supports multiple libc by design.

So tell me again why should I listen to what you say is "not supported"? I don't mean that in a negative way, I mean in a logical way. Because that's just a claim, and claims are not arguments.

I know, because of deficiencies in ELF and library (userland) API designs. That's kind of my point.

Already gave too many examples but it won't hurt one more time eh?

Because not everyone has this idiotic idea to recompile the entire userland for each distro. In fact, if you have to recompile it or link statically, this proves the design is rotten at its core. It's not "how Linux works" at all, it's not intentional, it's a mistake that can't be easily fixed. It's "how Linux is dragged down by ELF and shitty library interfaces" instead. It's dragged down by it, not "crappy on purpose".

Ever considered that some people (3rd party dev) just wants to compile their software once and have it work on all Linux-compatible distros? Really? It hasn't occurred to you after I explicitly told you it's how the majority works? (and why Linux lacks so many apps, this is a statistical fact, if you compare with other ecosystems)

So what happens if my app depends on some feature from musl and yet your distro ships glibc? Just like on Windows, I simply supply musl with my app, right? In Windows "it just works".

Oops, not on Linux, it might cause conflicts. You know, stuff I already said. Rotten design.

A "design" whose solution is to "recompile on each distro" or to "link statically everything" is rotten and stinks like putrid fish

Now you are just being plain silly. Not a single time have I ever claimed to lay down the law, but it's damn funny that every post from you contains "facts" on how mixing libc:s does not work and still you for unknow reasons get mad when I write that it's not really supported.

And no this is no deficiency in ELF since ELF supports versioned symbols just fine, so changing to mach-o or PE would change exactly nothing here (and please be my guest and send a mail to LKML where you force Torvalds et al to changed from ELF to PE and let me know how well that will be received).

If your app depends on musl then you must bundle musl and every one of your dependencies linked with musl. Note that this is exactly no different from how you must do it on Windows either since you cannot assume that any of your dependencies are installed there either (this is simply the bane of binary distribution and have nothing what so ever to do with ELF vs PE).

[brrrrttttt]

And no this is no deficiency in ELF since ELF supports versioned symbols just fine, so changing to mach-o or PE would change exactly nothing here (and please be my guest and send a mail to LKML where you force Torvalds et al to changed from ELF to PE and let me know how well that will be received).

The civilised world moved on from COFF years ago. It has many deficiencies compared to ELF or mach-o.

[Weasel]

Now you are just being plain silly. Not a single time have I ever claimed to lay down the law, but it's damn funny that every post from you contains "facts" on how mixing libc:s does not work and still you for unknow reasons get mad when I write that it's not really supported.

Because I am aware it doesn't work well and that's exactly my problem with it because it SHOULD work. Claiming it's not supported is a completely different thing, because it means it's so by design, when it is not. It excuses stupid design.

And no this is no deficiency in ELF since ELF supports versioned symbols just fine, so changing to mach-o or PE would change exactly nothing here (and please be my guest and send a mail to LKML where you force Torvalds et al to changed from ELF to PE and let me know how well that will be received).

Too bad most libraries don't use them?

Clearly, if we had this argument before they added versioned symbols, you'd say the exact same thing, despite the fact they acknowledged the design issues and added them later. Don't kid yourself. So yes it is a design flaw with a bad workaround.

However, the musl vs libc mixing is a userspace design problem, not part of ELF. It's a problem with the incompetent design in LIBRARIES.

If your app depends on musl then you must bundle musl and every one of your dependencies linked with musl. Note that this is exactly no different from how you must do it on Windows either since you cannot assume that any of your dependencies are installed there either (this is simply the bane of binary distribution and have nothing what so ever to do with ELF vs PE).

Wrong! If you bundle musl on Windows then your app will always just work. But on Linux, I already explained at least 5 times why it won't, randomly depending on how your distro and other system libraries were built.

The fact is, on Windows you link to a lot of system libraries (at least kernel32.dll), and you don't know what those libraries link against, nor should you care. So if you also link to musl it will just work.

This won't happen in Linux userland, because who knows what kind of shitty system library will link to libc instead and then call its (versioned, so no symbol conflict here) malloc, and let your app free it with musl and cause a crash. It worked on your system that such library used musl's malloc (maybe Alpine) but now it doesn't work on another distro even if you supply musl, because some other system library is now compiled against libc.

This is not a fault of ELF though, since we did use versioned symbols: this is a fault of library design which the userland lib devs are fully at fault for. They don't follow proper coding practice to clean up their own junk and let another module to call free, that's just stupid.

[brrrrttttt]

Windows doesn't magically protect you from somebody using a different (non-MS malloc/free compatible) allocator and passing you ownership of a pointer.

[Weasel]

Windows doesn't magically protect you from somebody using a different (non-MS malloc/free compatible) allocator and passing you ownership of a pointer.

I couldn't care less about protecting anyone, they should be shamed for bad design in the first place instead of "protected".

I'm talking about the existing userland, where the libraries on Linux are just subpar in quality (in design) and thus why this move to support "alternative compilers" and "mixing them" is just retarded on the existing Linux userland.

It's not that Windows protects you or not, is that anyone who probably ports something to Windows is forced to design his library better because it just won't work with this idiotic assumption. It's only Linux that excuses them instead of shaming them, because of the "de facto" assumption that there's only one compiler, one libc and libstdc++, etc.

This is not Linux' fault it's the userland library developers who should be shamed. (well it's also an ELF problem since people don't use versioned symbols, but that's another subject)

[chinoto]

For any unique compiler features, the compiler package could provide them and the dependent package requires them.
If alternative compilers gain these unique features and adds them to their provide list, they should be able to compile any packages that depends on those features.
If the dependencies are fulfilled to use a different compiler, but the package has a failure, the dev/maintainer either needs to add more feature requires or fix their source code.
Problem solved?

[lsatenstein]

I have been testing moderate sized C programs with both clang and gcc. It is true that clang compiles faster, but gcc's code is generally smaller and runs very slightly faster. To change would be trading four quarters for a dollar.

If you state that in one year's time, the spread in compile and output results between the two will widen, I would choose the product that has the best future for Fedora.
Right now, there is no need to change.

Some results
CFLAGS= -O3 -Wall -Wextra -Fpic -std=gnu99
gcc
total 256
-rwxrwxr-x. 1 leslie leslie 47968 Jan 1 13:08 fstabxref raw
-rwxrwxr-x. 1 leslie leslie 40352 Jan 1 13:09 xstabxref applying strip
clang
total 256
-rwxrwxr-x. 1 leslie leslie 47640 Jan 1 13:10 fstabxref raw
-rwxrwxr-x. 1 leslie leslie 40368 Jan 1 13:11 xstabxref applying strip

strip clears away most of the symbol table info, leaving just the executable code.