Changes between Version 4 and Version 5 of Ticket #55709, comment 7


Ignore:
Timestamp:
Jan 18, 2018, 3:01:36 PM (6 years ago)
Author:
kencu (Ken)
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #55709, comment 7

    v4 v5  
    33potmj currently has his `universal_archs` set to `i386 ppc x86_64` and this is problematic when building with clang. potmj ran into this issue, and has blown up his toolchain trying to get around it. He's now trying to build `libcxx` with gcc-4.2, which will never work with the toolchain the way Jeremy has it written.
    44
    5 Jeremy uses the `buildit` scripts to prevent the requirement for `cmake` which is a circular dependency on older systems the way MacPorts is set up. You have found out that you can build `libcxx` using the `cmake` build. That works for you on linux because building c++11 capable versions of gcc does not depend on cmake, and going that route, there is no circular dependency issue. It would work for us on MacPorts too, should we decide to set up the build that way. But we are not going to build `cmake` with `gcc` on MacPorts for 100 reasons we all know well. We are going to use the `buildit` script, and the `buildit` script is not presently `gcc`-friendly.
     5Jeremy uses the `buildit` scripts to prevent the requirement for `cmake` which is a circular dependency on older systems the way MacPorts is set up. You have found out that you can build `libcxx` using the `cmake` build. That works for you on linux because building c++11 capable versions of gcc does not depend on cmake, and going that route, there is no circular dependency issue. It would work for us on MacPorts too, should we decide to set up the build that way. But we are not going to build `cmake` with `gcc` on MacPorts for 100 reasons we all know well. We are going to build `libcxx` with the `buildit` script, and the `buildit` script is not presently `gcc`-friendly.
    66
    77So potmj can either go through tremendous hoops that probably only 5 or 6 of us would understand to make this work with gcc for no purpose at all, or he can simply change his universal_archs to `i386 x86_64` and then everything will be fine again (once he gets back on the train with his toolchain, and re-enables clang as his default compiler).