On Nov 20, 2019, at 14:55, Ken Cunningham wrote:
> On 2019-11-20, at 12:48 PM, Ryan Schmidt wrote:
>
>> There were also a fair number of issues caused by ports that do not properly
>> propagate the -stdlib flag to the build system.
>>
>
> Ah -- I had hoped to fix most of that by modifying clang to add
> "-stdlib=libc++" if not otherwise specified, just like it is done for 10.9+
> -- that's the "+defaultlibcxx" variant that is supposed to be enabled for all
> these clangs 5+.
>
> I didn't add that variant to clang-3.4 or 3.7 though -- perhaps there are
> issues back there with those ones.
Well there's certainly an issue for Xcode clang, which is not aware of your
modifications to MacPorts clangs.
https://trac.macports.org/ticket/59104
You say there that modifying the ports to pass the correct flags to the build
system is the correct thing to do, but that it is too much work and that we
should blacklist the affected Xcode compilers. It should come as no surprise
that I don't find that to be reasonable. Ports *should* use the flags MacPorts
tells them to use. Ports that don't do this will encounter any number of
problems accommodating the various features MacPorts claims to support today
(building for alternate architectures, building universal, libraries being
relocatable via install_name_tool) as well as new features MacPorts might
introduce in the future. Failure to build with alternate C++ libraries is
merely one of the problems that might be encountered. Rather than sweeping this
problem under the rug by blacklisting older compilers that haven't done
anything wrong, please fix ports to use the right flags so that *all* the
issues caused by not using the right flags can be fixed, rather than just
fixing one of them.
