test functionality of gold linker on full set of link libraries

[kronbichler]

Due to a recent post on the mailing lists,
https://groups.google.com/forum/#!topic/dealii/JxUOyd_4eFM
I checked the behavior of OpenMPI on Ubuntu 16.04 on the following trivial test file test.cc:

int main() {}

I tried to compile this with the settings detected by the deal.II configuration and it gives me a linker error as reported by Pete Griffin. The important part is the gold linker:

$ mpicxx -fuse-ld=gold test.cc
/usr/lib/openmpi/lib/libmpi_cxx.so: error: undefined reference to 'opal_list_item_t_class'
/usr/lib/openmpi/lib/libmpi_cxx.so: error: undefined reference to 'opal_class_initialize'
collect2: error: ld returned 1 exit status

The file links fine the the bfd linker (i.e., without the -fuse-ld=gold flag). While this clearly is a bug in the OpenMPI implementation shipped by Ubuntu, I think that our build system is to blame as well. We use a non-standard tool (the gold linker) and should ensure that it really works with the _final_ configuration selected by the user. As far as I can tell, we need to put the test for the gold linker not early in the configuration process as we currently do (cmake/checks/check_01_compiler_features.cmake), but check with the final set of link directories after detection of all third party libraries. @tamiko do you have another suggestion?

[tamiko]

@kronbichler I dislike the idea to set up the toolchain after the feature configuration. We will run into problems where we assume that the toolchain is properly configured prior to feature configuration.

What we can add is a separate check similar to the sanity check in setup_compiler_flags.cmake that tries once more to compile and link int main(){}. Unfortunately, there is little more than to error out at this point.

With respect to -fuse-ld=gold - if we really have a problem on Ubuntu with this flag, we should simply not try to set it automatically.

Other opinions?

[tamiko]

Alternatively, we could make the mpi detection stricter and refuse to pick up a faulty OpenMPI (that does not work with our set of compiler/linker flags).

[kronbichler]

On a second thought, I agree that feature configuration needs to be done before the toolchain. But as we observe in this case the two are somewhat interdependent.

What we can add is a separate check similar to the sanity check in setup_compiler_flags.cmake that tries once more to compile and link int main(){}. Unfortunately, there is little more than to error out at this point.

I definitely support the idea of trying to compile main(){} at the end of configuration. I ran into problems with the link interface more than once and right now you only get to see it after 20 minutes of compilation when building the first executable. Getting an error message straight away would be much appreciated.

Regarding this particular problem: I like the gold linker especially on the machines that run the regression tests, so keeping it the default would have some value. At the same time, everyone who is affected by the link timings probably knows how to set the flag manually in DEAL_II_LINKER_FLAGS, so we might be more conservative here...

Anyway, I agree that the best we can do at this point is to check that linking works both when detecting the MPI compiler and at the end of the configuration. No chance to detect that it is due to the gold linker on that particular set up and disable that one.

[tamiko]

@kronbichler Please test #2823.