[llvm-dev] Using C++14 code in LLVM

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 4 08:53:23 PDT 2016


On 4 October 2016 at 16:42, David Chisnall via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> That doesn’t really help.  Moving to a new c++ standard typically means moving to a new C++ standard library.  For me, two years ago, this involved having to build gcc and libstd++ from scratch to get a working toolchain.  Once this is done, I needed to futz with LD_LIBRARY_PATH to make sure that the code run by my students found the correct libstdc++ (note: a new libc++ would hit the same problems, though occasionally a new libstdc++ depends on a new glibc, which causes vastly more pain).

Changing tools, C or C++ libraries in a system is something that no
regular distro does because it is not tested in any way by anyone
ever.

GCC developers, maintainers and testers test with the "expected" setup
(gcc / binutils / glibc versions locked), and distros pay special
attention to those setups, and additionally validate their own
versions. *ANY* other combination is anyone's guess if it will
compile, run or give the correct results.

Relying on unsupported behaviour (worse still, recommending it), is
irresponsible, to say the least.


> The bump in cmake requirements was only slightly painful.  A bump in lib[std]c++ requirements is a lot worse.  Please don’t do it unless there is a *really* compelling reason to do so.

There is no reason compelling enough to send users and developers into
uncharted territory.

We're spending a lot of time adding the stable Linaro GCC toolchain to
the pool of validated sysroots, but only for ARM and AArch64, which is
where they are validated by our GCC engineers. If anyone else wants to
use it, they'd have to validate on their own, and then, I wouldn't be
able to recommend it myself to anyone else. Trying to make this scale
will never work.

cheers,
--renato


More information about the llvm-dev mailing list