Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • lsatenstein
    replied
    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.

    Last edited by lsatenstein; 01 January 2019, 02:20 PM.

    Leave a comment:


  • chinoto
    replied
    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?

    Leave a comment:


  • Weasel
    replied
    Originally posted by brrrrttttt View Post
    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)
    Last edited by Weasel; 24 July 2018, 07:28 AM.

    Leave a comment:


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

    Leave a comment:


  • Weasel
    replied
    Originally posted by F.Ultra View Post
    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.

    Originally posted by F.Ultra View Post
    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.

    Originally posted by F.Ultra View Post
    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.

    Leave a comment:


  • brrrrttttt
    replied
    Originally posted by F.Ultra View Post
    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.

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by Weasel View Post
    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).

    Leave a comment:


  • Weasel
    replied
    Originally posted by F.Ultra View Post
    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.

    Originally posted by F.Ultra View Post
    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.

    Originally posted by F.Ultra View Post
    And why would you even want to mix?
    Already gave too many examples but it won't hurt one more time eh?

    Originally posted by F.Ultra View Post
    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
    Last edited by Weasel; 21 July 2018, 10:58 AM.

    Leave a comment:


  • brrrrttttt
    replied
    Disingenuous and obtuse is his/her MO. Stop feeding.

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by Weasel View Post
    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).

    Leave a comment:

Working...
X