Thread overview
[Issue 19553] runnable/cpp_stdlib.d fails on NixOS
Jan 05, 2019
Thomas Mader
Jan 05, 2019
Thomas Mader
Jan 06, 2019
Thomas Mader
Jan 11, 2019
Thomas Mader
Jan 11, 2019
Thomas Mader
Jan 11, 2019
Thomas Mader
Jan 11, 2019
Thomas Mader
January 05, 2019
https://issues.dlang.org/show_bug.cgi?id=19553

--- Comment #1 from Thomas Mader <thomas.mader@gmail.com> ---
Created attachment 1723
  --> https://issues.dlang.org/attachment.cgi?id=1723&action=edit
cpp_stdlib.cpp.o

--
January 05, 2019
https://issues.dlang.org/show_bug.cgi?id=19553

Thomas Mader <thomas.mader@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pro.mathias.lang@gmail.com

--- Comment #2 from Thomas Mader <thomas.mader@gmail.com> ---
cc Mathias Lang as he added this test to dmd testsuite and might know what's going on.

--
January 06, 2019
https://issues.dlang.org/show_bug.cgi?id=19553

--- Comment #3 from Thomas Mader <thomas.mader@gmail.com> ---
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.

--
January 11, 2019
https://issues.dlang.org/show_bug.cgi?id=19553

--- Comment #4 from Thomas Mader <thomas.mader@gmail.com> ---
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.

--
January 11, 2019
https://issues.dlang.org/show_bug.cgi?id=19553

--- Comment #4 from Thomas Mader <thomas.mader@gmail.com> ---
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.

--
January 11, 2019
https://issues.dlang.org/show_bug.cgi?id=19553

--- Comment #5 from Thomas Mader <thomas.mader@gmail.com> ---
A better and easier solution is to just clear the environment from the already defined flags in the Makefile or the test runner script.

--
January 11, 2019
https://issues.dlang.org/show_bug.cgi?id=19553

Thomas Mader <thomas.mader@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #6 from Thomas Mader <thomas.mader@gmail.com> ---
(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.

--