Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: Fedora To Remain Monogamist Towards GCC

  1. #11
    Join Date
    Jun 2009
    Posts
    1,121

    Default

    Quote 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

  2. #12
    Join Date
    Dec 2010
    Posts
    1,119

    Default

    Quote 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.

    Quote 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….

  3. #13
    Join Date
    Jun 2009
    Posts
    1,121

    Default

    Quote 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

  4. #14
    Join Date
    Sep 2006
    Posts
    714

    Default

    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.

  5. #15
    Join Date
    Jun 2009
    Posts
    1,121

    Default

    Quote 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

  6. #16
    Join Date
    Dec 2010
    Posts
    1,119

    Default

    Quote 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++.

    Quote 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?

    Quote 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”).

    Quote 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.

  7. #17
    Join Date
    Jun 2009
    Posts
    1,121

    Default

    Quote 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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •