Changes between Version 16 and Version 17 of Ticket #59717


Ignore:
Timestamp:
Feb 8, 2020, 9:23:02 PM (4 years ago)
Author:
dgelessus (dgelessus)
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #59717 – Description

    v16 v17  
    88* libcxx
    99* clang-3.7
     10* icu
     11* libxml2
     12* cmake
    1013* newer clang (e. g. 9.0)
    1114
    … …  
    1922  * I've attempted to make libcxx build on Tiger in [https://github.com/dgelessus/macports-ports/tree/tiger_libcxx_no_pr a branch of my fork]. This isn't tested very well yet. (I've previously submitted this as [https://github.com/macports/macports-ports/pull/5783 PR 5783], but these changes likely won't be merged into the main ports tree, to avoid breaking newer systems.)
    2023  * Perhaps an alternative fix would be to make clang use libstdcxx instead of libcxx on Tiger. I haven't looked into this further yet, but @kencu has [https://github.com/kencu/TigerPorts/tree/master/lang/llvm-3.8 a customized llvm/clang-3.8 port that uses libstdcxx], so it seems to be possible.
    21 * llvm-3.7's configure script tries to call clang-3.4 with the option -stdlib=macports-libstdc++, which that version of the clang port doesn't support. This option is patched in by MacPorts for clang-5.0 and newer with the +libstdcxx variant (which is enabled by default). clang ports older than 5.0 (including 3.4) don't have a +libstdcxx variant.
    22   * This is caused by a bug in MacPorts base, which has been reported in #59584.
    23   * As a workaround, the +libstdcxx patch from clang-5.0 can be applied to clang-3.4 (with minor modifications). This won't result in proper macports-libstdc++ support (because clang before 3.8 doesn't support compiling C++11 code against libstdc++), but it is enough to make the incorrect call from the configure script not fail.
    2424* llvm-3.7 references a couple of macros that don't exist on Tiger.
    25   * This only requires some very minor patches, which I can submit once I've tested them.
     25  * This only requires some very minor patches, which can be found in [https://github.com/dgelessus/macports-ports/tree/llvm_3_7_tiger my fork's llvm_3_7_tiger branch].
    2626* The clang-3.7 build fails to build the compiler-rt libraries for the clang_darwin target (the clang_macho_embedded ones get built properly). make thinks that there is nothing to be done for the clang_darwin target, so no libraries are built, which causes later parts of the build (that expect the libraries to exist) to fail.
    2727  * This appears to be a similar issue to #54836 and #59157.
    28 * There may be more issues after this; I'm currently working on getting clang-3.7 fully built.
     28  * This is also fixed in [https://github.com/dgelessus/macports-ports/tree/llvm_3_7_tiger my fork's llvm_3_7_tiger branch].
     29* The configure script of icu tries to call clang-3.4 with the option -stdlib=macports-libstdc++, even though icu will be built against libc++ (via the clang_dependency 1.0 portgroup). This option is patched in by MacPorts for clang-5.0 and newer with the +libstdcxx variant (which is enabled by default). clang ports older than 5.0 (including 3.4) don't have a +libstdcxx variant and do not support -stdlib=macports-libstdc++.
     30  * The incorrect compiler call is caused by a bug in MacPorts base, which has been reported in #59584.
     31  * As a workaround, the +libstdcxx patch from clang-5.0 can be applied to clang-3.4 (with minor modifications). This won't result in proper macports-libstdc++ support (because clang before 3.8 doesn't support compiling C++11 code against libstdc++), but it is enough to make the incorrect call from the configure script not fail.
    2932
    3033I've already discussed some of these issues separately on IRC and GitHub (thanks to @jmroot and @kencu for the help so far!). This ticket is meant to be an overview of how the issues are related, as the issues further down the list usually can't be observed without first fixing/working around the previous issues.