configure failure due to toolchain updates?

René J.V. Bertin rjvbertin at
Tue Jul 9 14:22:16 UTC 2019


The recent report of a configure failure in port:VLC on what I think is the latest Mac OS cum Xcode seems to be due to a toolchain change which modifies the way `clang -E` works. The procedure fails because it trips over a failsafe designed for the NeXT OS (!!) where `cc -E` invokes the parser. Curiously, whatever change is behind all this, it also affects port:clang-5 and port:clang-6 .


On Monday July 08 2019 21:41:30 MacPorts wrote:
> #58682: vlc @ build failure - failed to configure
>  Good news. It looks like replacing {{{${} }}} with {{{clang-
>  cpp-mp-5.0}}} did the trick. It built and opened perfectly.
> --
> Ticket URL: <>
> MacPorts <>
> Ports system for the Mac OS

In clear: the procedure will succeed by setting the preprocessor to clang-cpp from the chosen toolchain.

This does beg a few questions:
- Does the system toolchain include a clang-cpp command?
- How about C++ (there is no clang++-cpp or clang-cxxpp)
- is this something that should be set in "base" (via the CPP and/or CXXCPP env. variables)? The preproc. test comes from autoconf (it's in c.m4 to be exact) and is thus bound to fail on other projects as well?!
- alternatively, should c.m4 be patched to exclude that NeXT-specific bit?

Probably unrelated (except to "new toolchains"), but what are the implications of this warning about LLVM 8 that I encountered?

Starting with LLVM 8.0.0, users that wish to link together translation units built
with different versions of libc++'s headers into the same final linked image MUST
define the _LIBCPP_HIDE_FROM_ABI_PER_TU macro to 1 when building those translation
units. Not defining _LIBCPP_HIDE_FROM_ABI_PER_TU to 1 and linking translation units
built with different versions of libc++'s headers together may lead to ODR violations
and ABI issues. On the flipside, code size improvements should be expected for
everyone not defining the macro.


More information about the macports-dev mailing list