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

[hoohoo]

Yes but some are complaining that if they one day would switch to Clang then having gcc here would require a massive change then

Seems a silly complaint, they can just change the dependency to clang.

[Weasel]

Seems a silly complaint, they can just change the dependency to clang.

No, point is when you mix some with GCC and others with Clang. When requiring "gcc" it obviously means that you can require alternative compilers (otherwise you could just do "c++" as requirement).

[F.Ultra]

Absolutely nonsense. Show me the promise or law that prohibits Linux from using another libc. Not to mention that this is not part of the LANGUAGE which was the context. It's not a contract enforced by the language (i.e. "thou shall not use any other libc on Linux").

https://stackoverflow.com/questions/...-a-single-host

Keep in mind that an executable can link to a different loader or libc than one of its dependencies (libraries). The kernel does support multiple libc (other than glibc) that's why even its libc syscall interface is stable in the first place, to support alternative libc like MUSL. (apparently some distros even use musl as default, imagine if you try to use a library compiled for another distro and you supply all the dependencies... yeah, on Windows this is no problem due to better DLL design, on Linux they break standards and language rules left and right, assume GCC, etc, so fiasco ensures)

We have to remember that just because something happens in your particular case and distro/system does not make it a fact.

Have you forgotten the long thread about ELF that we have in the other topic? While it's of course true that you can have several libc:s on your drive (why would that even be a question) you should be well aware by now that the malloc() and free() symbols will be linked from a single version when ldd does the run-time linking. I.e if you bring a glibc linked application to Alpine (that uses musl) then your application will be linked with musl at run-time.

[Weasel]

Have you forgotten the long thread about ELF that we have in the other topic? While it's of course true that you can have several libc:s on your drive (why would that even be a question) you should be well aware by now that the malloc() and free() symbols will be linked from a single version when ldd does the run-time linking. I.e if you bring a glibc linked application to Alpine (that uses musl) then your application will be linked with musl at run-time.

Yeah, but then the library which depends on the other libc might crash the process since it uses a different libc with different features? Or maybe a function available only in one libc and then "mix" the two with missing symbols from the other. Not to mention if it uses versioned symbols you're kinda screwed since it will import from its own libc and then passing around free()/malloc() ends in disaster with mixing them. :P

[TheBlackCat]

Yes but some are complaining that if they one day would switch to Clang then having gcc here would require a massive change then

In openSUSE they have a "c++_compiler" dependency, which just depends on the default c++ compiler.

[F.Ultra]

Yeah, but then the library which depends on the other libc might crash the process since it uses a different libc with different features? Or maybe a function available only in one libc and then "mix" the two with missing symbols from the other. Not to mention if it uses versioned symbols you're kinda screwed since it will import from its own libc and then passing around free()/malloc() ends in disaster with mixing them. :P

So you do now agree that it's not supported to mix and match C runtimes on Linux/BSD?

[Weasel]

So you do now agree that it's not supported to mix and match C runtimes on Linux/BSD?

What do you mean with "not supported"? Obviously nobody stops you from installing both, and if an app uses either of them (but not both, including all its deps) then it works just fine.

Problem is that ELF craps out without versioned symbols (elf issue, DLL/Mach-O doesn't have it), and even with versioned symbols people assume there's only one libc and design bad libraries (you know from the other thread, free an object malloc'd by another module). This doesn't mean it's "not supported", not like there's a central authority which said there's only one libc, or which decides what's "supported" on Linux in general.

In fact, the kernel was effectively designed with the idea of more libc co-existing (one of the reasons for a stable kernel interface even for libc wrappers), so if you go by the kernel as the "authority" (I mean it is called Linux after all), then it's just the badly coded libraries in the userland which are at fault here...

...and ELF.

[azdaha]

If the idea of a "standard" is to help stabilize things with respect to builds, then maybe the "gcc standard" that Weasel seems to point to is the way to go. It's GNU/Linux, btw; userland and kernel. Also, there are distros that use or offer musl as the library, as you pointed out; but it's separated from the libc-based tree. Again, maybe the assumption that people make should be treated as a standard, rather than being dismissed.

[F.Ultra]

What do you mean with "not supported"? Obviously nobody stops you from installing both, and if an app uses either of them (but not both, including all its deps) then it works just fine.

Problem is that ELF craps out without versioned symbols (elf issue, DLL/Mach-O doesn't have it), and even with versioned symbols people assume there's only one libc and design bad libraries (you know from the other thread, free an object malloc'd by another module). This doesn't mean it's "not supported", not like there's a central authority which said there's only one libc, or which decides what's "supported" on Linux in general.

In fact, the kernel was effectively designed with the idea of more libc co-existing (one of the reasons for a stable kernel interface even for libc wrappers), so if you go by the kernel as the "authority" (I mean it is called Linux after all), then it's just the badly coded libraries in the userland which are at fault here...

...and ELF.

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?

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.

And why would you even want to mix? 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?

But if you must for whatever reason use glibc on say Alpine then by all means do it but then you just have to make sure that any library that you link with are also linked with glibc and not musl.

OR you just make sure that every single library is using versioned symbols and you can go your merry WIndows way by bringing in several libc:s at the same time (why bother with resources when RAM is cheap right).

[brrrrttttt]

Disingenuous and obtuse is his/her MO. Stop feeding.