Announcement

Collapse
No announcement yet.

Fedora To Remain Monogamist Towards GCC

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

  • jrch2k8
    replied
    Originally posted by Awesomeness View Post
    Wrong. Darwin, the underlying OS, is C and C++.


    Can you prove that or is that just some made-up stuff?


    Apache License 2 has the same patent grants as GPLv3. Apple releases lots of software under Apache License.
    Before you make such assumptions, try to think, please. Apple binaries are signed for security reasons. GPLv3 would require Apple to hand over the sign keys (aka ?TIVO clause?).


    The packager may package software for a platform the upstream developer has not even access to. Clang could produce better code for that platform. If the upstream developer has irrational hatred against Clang, he may never ?bless? Clang although it would be better.
    1.) i said MOSTLY meaning Cocoa which is the part of the OS aPI that normally devs will use to develop apps
    2.) well is logical they do since for example why waste binary space on AMD specifics or Exynos ARM specifics, if you only have access to Intel and A15 hardware? and making memory i don't recall those exists in macport-clang at all, so yes they mostly use their own branch of clang and prlly since they hardware is so static prolly they have many Next BSD/Mach/intel/A15 aggresive optimizations lying around that prolly no one else would use(maybe hackintosh ppl??), etc.
    3.) well licence flame wars, all you say is true and fake at the same time, lets lawyer deal with it
    4.) well clang only support x86 missing the previous topics and some ARM archs so is very unlikely a dev won't have access to that plataform besides packagers making changes downstream is a formula for a disaster, no decent distro should allow non upstream changes in their main distro packages especially in something so delicate as a compiler.

    sure some very weird and specific software could run better using clang right now but the maintenance burden don't worth it but like i said no one is forbidden it in an external repo (ppa like or epel like, etc), so you are free to recompile fedora using clang if you want you just can't add them to the main repo

    Leave a comment:


  • Awesomeness
    replied
    Originally posted by jrch2k8 View Post
    Mac is mostly Objetive C where Linux is GNU/ISO C and C++
    Wrong. Darwin, the underlying OS, is C and C++.

    Originally posted by drag View Post
    The LLVM/Clang/etc that Apple uses will never be the same LLVM/Clang/etc that everybody else uses.
    Can you prove that or is that just some made-up stuff?

    Originally posted by drag View Post
    After all then why the hell would Apple want to run away from GPLv3 code? It's all about the patents that Apple controls, of course.
    Apache License 2 has the same patent grants as GPLv3. Apple releases lots of software under Apache License.
    Before you make such assumptions, try to think, please. Apple binaries are signed for security reasons. GPLv3 would require Apple to hand over the sign keys (aka ?TIVO clause?).

    Originally posted by drag View Post
    Because the packager is not in a position to know what is best for the software.
    The packager may package software for a platform the upstream developer has not even access to. Clang could produce better code for that platform. If the upstream developer has irrational hatred against Clang, he may never ?bless? Clang although it would be better.

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by drag View Post
    A couple side points:
    * The LLVM/Clang/etc that Apple uses will never be the same LLVM/Clang/etc that everybody else uses.
    * Also if you use LLVM/Clang/etc you can run into situations were things that are legal for Apple to do is illegal for you to do because of Apple's licensing agreements.

    After all then why the hell would Apple want to run away from GPLv3 code? It's all about the patents that Apple controls, of course.




    Because the packager is not in a position to know what is best for the software. They are the packager, not the developer. In addition the use of alternative toolchains has a cascading effect on the rest of the system. In the end it will create maintenance headaches and other unnecessary crap that everybody else will have to deal with.

    If the package maintainer wants to use LLVM then the correct way to approach it would be to get involved in upstream development and work with them to port their code base over to using LLVM. THEN the appropriate compiler to use for the application would be LLVM and not GCC, and thus easily meet Fedora's criteria.

    That is the correct approach. If you are going to fuck around with alternate configs and compilers and all sorts of other development decisions then the appropriate place to do that is with the developers, upstream. Not the package making level.
    100% true and apple has their private branch of clang/llvm for their use only not just cuz the issues drag mentioned but the fact of they have their propietary Next/Os X unix specifics embedded in that codebase

    Leave a comment:


  • drag
    replied
    A couple side points:
    * The LLVM/Clang/etc that Apple uses will never be the same LLVM/Clang/etc that everybody else uses.
    * Also if you use LLVM/Clang/etc you can run into situations were things that are legal for Apple to do is illegal for you to do because of Apple's licensing agreements.

    After all then why the hell would Apple want to run away from GPLv3 code? It's all about the patents that Apple controls, of course.


    This is what I do not understand about this policy: Why not let the packager decide which compiler works better for the package?
    Because the packager is not in a position to know what is best for the software. They are the packager, not the developer. In addition the use of alternative toolchains has a cascading effect on the rest of the system. In the end it will create maintenance headaches and other unnecessary crap that everybody else will have to deal with.

    If the package maintainer wants to use LLVM then the correct way to approach it would be to get involved in upstream development and work with them to port their code base over to using LLVM. THEN the appropriate compiler to use for the application would be LLVM and not GCC, and thus easily meet Fedora's criteria.

    That is the correct approach. If you are going to fuck around with alternate configs and compilers and all sorts of other development decisions then the appropriate place to do that is with the developers, upstream. Not the package making level.

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by Awesomeness View Post
    So then they can switch the package back to GCC if Clang actually causes problems.


    Yeah right, that's why Apple uses Clang for its ?not prime time? iPhones and Macs?.
    1.) if that happens still is lot more work than just keep 1 well tested toolchain (which is their point to begin with) assuming the previous maintainer didn't use clang specific optimization which are not supported or cause regressions in gcc which adds to the fun of maintain many toolchains

    2a.) Mac is mostly Objetive C where Linux is GNU/ISO C and C++(except maybe libre/open office)
    2b.) Mac is extremely tied to very specific hardware so they can uber ultra optimize their clang code(reads not neccesatily available since clang in BSD licensed) where Linux run in almost any hardware known in these galaxy and even when you specify a target plataform like x86(and variants) you have to support several vendors (amd/intel/others) specific architectures and extensions/features(AVX/FMA/XoR/cache/etc) efficiently(and Michael has proved again and again that GCC is way faster even using default flags, if you add proper falgs and PGO/LTO that difference tends mostly to get only bigger)

    so even if Apple have their ObjC branch uber optimized for their very specific set of hardware my point is still true Clang is not ready for prime time in the Linux world neither is more efficient or the binaries are faster than GCC and Clang only support a small subset of plataforms compared to GCC.

    again im not saying llvm/clang sucks, i am saying it need to mature a lot more to be a real GCC replacement cuz today is a nice proof of concept with a nice future ahead but is not in the same league as GCC is

    Leave a comment:


  • Awesomeness
    replied
    Originally posted by jrch2k8 View Post
    imagine the anarchic mess resulting of bugs report present in LLVM/Gcc and not present in the other that without account possible abi breaks, longer time to fix bugs or the dude maintaing the package simply got bored and leave the package unmaintained and the next one have to figure out how to solve stuff from clang/llvm since not much ppl is experienced with it unlike gcc
    So then they can switch the package back to GCC if Clang actually causes problems.

    Originally posted by jrch2k8 View Post
    llvm/clang is a nice project but is not prime time ready nor is ready to replace GCC at least for 2 more years
    Yeah right, that's why Apple uses Clang for its ?not prime time? iPhones and Macs?.

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by Awesomeness View Post
    This is what I do not understand about this policy: Why not let the packager decide which compiler works better for the package?
    imagine the anarchic mess resulting of bugs report present in LLVM/Gcc and not present in the other that without account possible abi breaks, longer time to fix bugs or the dude maintaing the package simply got bored and leave the package unmaintained and the next one have to figure out how to solve stuff from clang/llvm since not much ppl is experienced with it unlike gcc.

    beside clang/llvm don't have feature parity with gcc nor offers better performance (i don't mean cute build logs i mean AVX/FMA, PGO, LTO, Graphite, OpenMP(<--for god sakes), etc).

    beside this is a policy for main distro packagers it doesn't mean you can download clang and compile your X favorite app with it and publish in your X prefered Repo.

    llvm/clang is a nice project but is not prime time ready nor is ready to replace GCC at least for 2 more years

    Leave a comment:


  • Awesomeness
    replied
    Originally posted by XorEaxEax View Post
    Fedora will ship GCC while allowing anyone to use Clang/LLVM and also use it for packages should they require it
    This is what I do not understand about this policy: Why not let the packager decide which compiler works better for the package?

    Leave a comment:


  • XorEaxEax
    replied
    I have no idea what the purpose of the monogamy/cheating quip was, other than to put some sort of spin on this, but really it's the same thing as with FreeBSD, only that Fedora will ship GCC while allowing anyone to use Clang/LLVM and also use it for packages should they require it and FreeBSD will ship Clang/LLVM while allowing anyone to use GCC, it's right there in ports.

    Also I can't see any reasons why Fedora would switch to Clang/LLVM, it doesn't even compile the Linux kernel. Furthermore it fails at compiling lots of other key packages like LibreOffice etc, not to mention supporting less languages and less hardware targets. FreeBSD switching official compiler to Clang/LLVM on the other hand made perfect sense as they were stuck with 5 year old GCC 4.2 due to their corporate sponsors not accepting GPLv3.

    Leave a comment:


  • Hirager
    replied
    Originally posted by droidhacker View Post
    Has nobody noticed that this nonsense is all about licensing?
    LLVM is licensed basically BSD, which is why BSD's will prefer it -- it allows for anti-competitve use.
    GCC is GPL.
    It would be funny, if GCC took code from LLVM. Can you imagine this irony?

    Leave a comment:

Working...
X