Bug 209467
| Summary: | devel/llvm37: clang++37 behaves differently on 9.3 and 10.3 | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Yuri Victorovich <yuri> |
| Component: | Individual Port(s) | Assignee: | Brooks Davis <brooks> |
| Status: | Closed Works As Intended | ||
| Severity: | Affects Only Me | CC: | jbeich |
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(brooks) |
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
clang-3.7.1 on Arch doesn't produce an error (like on FreeBSD 10.3) You cannot compile for C++11 on a 9.x installation, because clang will use libstdc++ by default there, and the version of libstdc++ in the 9.x base system is not C++11 compatible. To be able to use C++11, you must install libc++ first, using for example: export CC=clang export CXX=clang++ cd /usr/src/lib/libcxxrt make obj make depend make make install cd /usr/src/lib/libc++ make obj make depend make make install Alternatively, rebuild world with these settings in /etc/src.conf: WITH_CLANG_IS_CC=y WITH_LIBCPLUSPLUS=y On FreeBSD 10.x, clang and libc++ are the defaults, and C++11 can be used out of the box. Okay, but what to do if the code in some port requires c++11? Like I just tried devel/bazel and couldn't build it on 9. For now, the only way is to mark such programs broken on 9. It should theoretically be possible to build a working c++11 environment on 9, but for now there isn't on in ports. The 9 series has less than 8 months of support left and I expect to see considerable attrition of ports support over that time as C++11 becomes more common. clang also supports --gcc-toolchain=/path/to/gcc-prefix but it doesn't seem to work with our lang/gcc* ports. So, using more recent libstdc++ is going to be tricky: -nostdinc++ -isystem/foo -isystem/bar This is probably why FAVORITE_COMPILER=clang is a nop. (In reply to yuri from comment #3) > what to do if the code in some port requires c++11? Define USES=compiler:c++11-lib which would use lang/gcc* on 9.x. Note, C++11 is often broken without CPPFLAGS+= -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_C99_MATH_TR1 \ -D_DECLARE_C99_LDBL_MATH # bug 193528 workaround Thanks Jan, I didn't realize that clang is broken like that on 9. I will just label the problematic ports as BROKEN on 9, as you suggested. Have a good day, Yuri Now I see another problem of the same kind: clang36-3.6.2 fails to compile the port net-im/ring-daemon on 10.1-RELEASE-p9 amd64 and succeeds on 10.3 amd64.
Error message:
> configurationmanager.cpp:164:12: error: chosen constructor is explicit in copy-initialization
> return {};
- and many other similar ones.
This port has USES=compiler:c++14-lang.
FreeBSD 9 will never support C++11 programs in a default configuration. |
Using the same package, clang++NN successfully compiles test.cc on 10.3 and fails on 9.3. This is true for clang++34, clang++37 and probably for all of clang++NN. This is also true for clang-3.4.1 in the bases of 9.3 and 10.3. The same version of compiler should compile the same standalone C/C++ code the same way, regardless of the OS version. --program test.cc--- #include <limits> int main() { const int vmax = std::numeric_limits<int>::max(); static_assert(vmax>0, ""); } ---command--- clang++37 -std=c++11 -c test.cc ---error on 9.3--- test.cc:6:17: error: static_assert expression is not an integral constant expression static_assert(vmax>0, ""); ^~~~~~ test.cc:6:17: note: initializer of 'vmax' is not a constant expression test.cc:5:13: note: declared here const int vmax = std::numeric_limits<int>::max(); ^ 1 error generated.