[MacPorts] #59717: clang >= 3.4: Unable to build/bootstrap on Intel Tiger
MacPorts
noreply at macports.org
Mon Feb 3 15:07:43 UTC 2020
#59717: clang >= 3.4: Unable to build/bootstrap on Intel Tiger
-------------------------------------------------+-------------------------
Reporter: dgelessus | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version:
Resolution: | Keywords: tiger i386
Port: libcxx llvm-3.4 clang-3.4 llvm-3.7 |
clang-3.7 |
-------------------------------------------------+-------------------------
Description changed by dgelessus:
Old description:
> It is currently not possible to build clang-3.4 or newer on Intel Tiger.
> As a result, any ports that require C++11 cannot be built on Tiger,
> because MacPorts selects a recent clang (currently 9.0) when looking for
> a C++11-capable compiler.
>
> This issue is somewhat complex because a lot of bootstrapping is
> involved, and multiple ports in the bootstrap process don't work properly
> on Tiger. The (simplified) bootstrap dependency chain looks like this:
>
> * Xcode 2.5 gcc
> * apple-gcc42
> * clang-3.4
> * icu
> * libxml2
> * libcxx
> * clang-3.7
> * newer clang (e. g. 9.0)
>
> So far I've run into the following individual issues in the chain:
>
> * clang-3.4 requires libxml2 to build, which requires icu. icu requries a
> C++11 compiler, and MacPorts selects clang-3.4 here, which leads to a
> circular dependency.
> * The clang-3.4 Portfile already has a special case to handle this
> issue, but it doesn't get triggered on Tiger, because the cxx_stdlib is
> set to libstdcxx and not libcxx.
> * I've submitted a fix for this as [https://github.com/macports
> /macports-ports/pull/5771 PR 5771].
> * llvm/clang-3.7 always wants libcxx as its C++ stdlib, but the libcxx
> port doesn't support Tiger.
> * 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.)
> * 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.
> * 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.
> * This is caused by a bug in MacPorts base, which has been reported in
> #59584.
> * 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.
> * llvm-3.7 references a couple of macros that don't exist on Tiger.
> * This only requires some very minor patches, which I can submit once
> I've tested them.
> * 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.
> * This appears to be a similar issue to #54836 and #59157.
> * There may be more issues after this; I'm currently working on getting
> clang-3.7 fully built.
>
> I'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.
>
> Also I'm not sure what the best solutions are for some of the issues, or
> if it even makes sense to use clang (rather than gcc) as the C++11
> compiler on Tiger. Any opinions and suggestions are welcome.
New description:
It is currently not possible to build clang-3.4 or newer on Intel Tiger.
As a result, any ports that require C++11 cannot be built on Tiger,
because MacPorts selects a recent clang (currently 9.0) when looking for a
C++11-capable compiler.
This issue is somewhat complex because a lot of bootstrapping is involved,
and multiple ports in the bootstrap process don't work properly on Tiger.
The (simplified) bootstrap dependency chain looks like this:
* Xcode 2.5 gcc
* apple-gcc42
* clang-3.4
* libcxx
* clang-3.7
* newer clang (e. g. 9.0)
So far I've run into the following individual issues in the chain:
* (no longer applies) clang-3.4 requires libxml2 to build, which requires
icu. icu requries a C++11 compiler, and MacPorts selects clang-3.4 here,
which leads to a circular dependency.
* The clang-3.4 Portfile already has a special case to handle this
issue, but it doesn't get triggered on Tiger, because the cxx_stdlib is
set to libstdcxx and not libcxx.
* I've submitted a fix for this as [https://github.com/macports
/macports-ports/pull/5771 PR 5771].
* This has been fixed by @kencu in [https://github.com/macports
/macports-ports/commit/57b34213865ed6dd99e22c61f3721232ffccf2f9 commit
57b3421], by disabling the parts of clang-3.4 and clang-3.7 that require
libxml2.
* llvm/clang-3.7 always wants libcxx as its C++ stdlib, but the libcxx
port doesn't support Tiger.
* 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.)
* 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.
* 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.
* This is caused by a bug in MacPorts base, which has been reported in
#59584.
* 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.
* llvm-3.7 references a couple of macros that don't exist on Tiger.
* This only requires some very minor patches, which I can submit once
I've tested them.
* 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.
* This appears to be a similar issue to #54836 and #59157.
* There may be more issues after this; I'm currently working on getting
clang-3.7 fully built.
I'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.
Also I'm not sure what the best solutions are for some of the issues, or
if it even makes sense to use clang (rather than gcc) as the C++11
compiler on Tiger. Any opinions and suggestions are welcome.
--
--
Ticket URL: <https://trac.macports.org/ticket/59717#comment:16>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list