Hi,
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 .
Fortunately:
On Monday July 08 2019 21:41:30 MacPorts wrote:
> #58682: vlc @3.0.7.1 build failure - failed to configure
> Good news. It looks like replacing {{{${configure.cc} }}} with {{{clang-
> cpp-mp-5.0}}} did the trick. It built and opened perfectly.
> --
> Ticket URL: <https://trac.macports.org/ticket/58682#comment:7>
> MacPorts <https://www.macports.org/>
> 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.
```
R.
