Changes between Version 17 and Version 20 of Ticket #59717


Ignore:
Timestamp:
Feb 8, 2020, 10:49:54 PM (5 years ago)
Author:
dgelessus (dgelessus)
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #59717 – Description

    v17 v20  
    2727  * This appears to be a similar issue to #54836 and #59157.
    2828  * 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.
     29* The current version of icu requires C++11, so MacPorts tries to compile it with MacPorts Clang 3.4. However, icu needs to be built against libstdc++ (the default C++ stdlib on Tiger), which is not possible with Clang older than 3.8.
    3230
    3331I'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.