Bug 19553 – runnable/cpp_stdlib.d fails on NixOS

Created attachment 1722 cpp_stdlib_0.o Here is what I get when running the testsuite after compiling dmd 2.084.0 on NixOS. ... runnable/integrate.d -fPIC () ... runnable/cpp_stdlib.d -fPIC -L-lstdc++ (-inline -release -g -O) Test runnable/cpp_stdlib.d failed. The logged output: /build/dmd/generated/linux/release/64/dmd -conf= -m64 -Irunnable -fPIC -L-lstdc++ -odtest_results/runnable -oftest_results/runnable/cpp_stdlib_0 runnable/cpp_stdlib.d test_results/runnable/cpp_stdlib.cpp.o test_results/runnable/cpp_stdlib_0.o: In function `_Dmain': runnable/cpp_stdlib.d:(.text._Dmain[_Dmain]+0x31): undefined reference to `int& identity<int>(int&)' runnable/cpp_stdlib.d:(.text._Dmain[_Dmain]+0x50): undefined reference to `float& identity<float>(float&)' runnable/cpp_stdlib.d:(.text._Dmain[_Dmain]+0x7d): undefined reference to `int** identityPP<int>(int**)' runnable/cpp_stdlib.d:(.text._Dmain[_Dmain]+0xa0): undefined reference to `float** identityPP<float>(float**)' runnable/cpp_stdlib.d:(.text._Dmain[_Dmain]+0xc8): undefined reference to `std::vector<int, std::allocator<int> >* getVector<int>(unsigned long, int const*)' runnable/cpp_stdlib.d:(.text._Dmain[_Dmain]+0x10f): undefined reference to `std::vector<float, std::allocator<float> >* getVector<float>(unsigned long, float const*)' runnable/cpp_stdlib.d:(.text._Dmain[_Dmain]+0x179): undefined reference to `std::array<int, 4ul>* getArray<int, 4ul>(int const*)' runnable/cpp_stdlib.d:(.text._Dmain[_Dmain]+0x1d1): undefined reference to `std::array<float, 4ul>* getArray<float, 4ul>(float const*)' collect2: error: ld returned 1 exit status Error: linker exited with status 1 ============================== Test runnable/cpp_stdlib.d failed: expected rc == 0, exited with rc == 1 make[1]: *** [Makefile:133: test_results/runnable/cpp_stdlib.d.out] Error 1

Created attachment 1723 cpp_stdlib.cpp.o

cc Mathias Lang as he added this test to dmd testsuite and might know what's going on.

The problem is that NixOS is using some flags for hardening on gcc. The problematic flag is '-O2' which is used in conjunction with '-D_FORTIFY_SOURCE=2'. If this is used when compiling extra-files/cpp_stdlib.cpp or extra-files/cppb.cpp a lot of symbols are missing in the resulting object file. The question now is if it is possible somehow to make sure that no hidden flags are passed to those tests so that such problems can not occur.

One solution might be to add specializations for template function declarations so the optimization flag to the C++ compiler does not strip away those symbols. The problem is a minor one as nearly no one will ever get into such troubles. Normally you are aware of the flags you are giving to the compiler but many distributions use hardening flags so I think the problem might also occur if the testsuite is run within other distribution packaging contexts as well. If it is considered a needed and practical solution I could try to make a PR.

A better and easier solution is to just clear the environment from the already defined flags in the Makefile or the test runner script.

(In reply to Thomas Mader from comment #5) > A better and easier solution is to just clear the environment from the > already defined flags in the Makefile or the test runner script. Just realized that the CXXFLAGS is not passed/used in the testrunner, the flags are directly in the gcc wrapper of NixOS so there is nothing dlang can do about it. The only solution I see is to add specializations but that has the drawback that people will not remember to do that when adding new tests. That and the fact that it is just a minor issue tells me that it is better to close this issue.