The problem is described here
https://groups.google.com/forum/?hl=en#!topic/dealii/eG75p2TVNNQ
Installing development version of deal.II using spack is not working as cmake is tuck at
Performing Test DEAL_II_HAVE_USABLE_FLAGS_DEBUG
@davydden
a quick summary: 8.4.2 was working fine with the complete set of dependencies, whereas current master version fails at the last step of CMake configre where we try to build a simple int main(){ return0;}, see https://github.com/dealii/dealii/blob/master/cmake/macros/macro_check_compiler_setup.cmake.
To get to the source, it was suggested to remove flags one by one from
/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/openmpi-2.0.1-asdjmd22cnyktv2athcx3ouhrozknk22/bin/mpic++
-DDEAL_II_HAVE_USABLE_FLAGS_DEBUG -pedantic -fPIC -Wall -Wextra
-Wpointer-arith -Wwrite-strings -Wsynth -Wsign-compare -Wswitch
-Woverloaded-virtual -Wno-long-long -Wno-placement-new
-Wno-deprecated-declarations -Wno-literal-suffix -fopenmp-simd -std=c++14
-Wno-unused-local-typedefs -Og -ggdb -Wa,--compress-debug-sections
CMakeFiles/cmTC_4e156.dir/src.cxx.o -o cmTC_4e156 ......
to see which one makes ld to hang.
@cpraveen DEAL_II_HAVE_USABLE_FLAGS_* is a simple test at the end of the configure stage that ensures that compilation and linkage with the given compiler flags and libraries works as expected.
From the discussion on the mailing list I have the suspicion that something is broken in your toolchain.
Since I am able to build
spack install [email protected]
I installed all dependencies
spack install --only dependencies [email protected]
created a file system view, did a git clone of dealii and try to configure. This is again stuck at the same test.
@cpraveen Can you please attach the full detailed.log?
From the discussion on the mailing list I have the suspicion that something is broken in your toolchain.
from @cpraveen confirmation above that 8.4.2 works OOB, it looks like this is not the case.
yes, I tried [email protected] just now from spack and it builds.
@tamiko I dont yet have a detailed.log file since cmake has not finished.
@davydden Maybe linkage is broken if you try to link in some funny libraries in the link chain of trilinos if you happen to not use any external symbol? Maybe the problem is not present in 8.4.2 because we build up the library dependencies differently?
@cpraveen Please do the following and report the result: Comment out lines 86 to 104 in cmake/setup_finalize.cmake that are responsible for the DEAL_II_HAVE_USABLE_FLAGS_* and try to configure and compile. After that you will have a detailed.log.
created a file system view, did a git clone of dealii and try to configure. This is again stuck at the same test.
for those who are not familiar with Spack, this will symlink all dependencies into a single folder so that it's easier to point to them when doing manual configuration. Important point here is that the toolchain is exactly the same as that used by spack install [email protected], which works! To me, it rules out the possible issue of a broken toolchain.
@tamiko :
Maybe the problem is not present in 8.4.2 because we build up the library dependencies differently?
no, they are not build differently. He used exactly the same toolchain that works for 8.4.2 to manually configure from git-checkouted out deal.II.
@davydden We have over 2320 lines of changed CMake stuff between v8.4.2 and current master. I remember changing quite a few of the find*.cmake packages. This will very likely result in a final compiler and linker invocation with different position of libraries and options.
It is very obscure that a simple compilation of
int main(){return 0;}
with our final set of compiler flags and link interface fails.
@cpraveen I would be very interested in both detailed.log files. The one for 8.4.2 and the one for current master. So in summary:
That will help a lot :-)
We have over 2320 lines of changed CMake stuff between v8.4.2 and current master. I remember changing quite a few of the find*.cmake packages. This will very likely result in a final compiler and linker invocation with different position of libraries and options
I agree with that.
I would be very interested in both detailed.log files. The one for 8.4.2 and the one for current master.
indeed. One could then diff the two to see what is different (be it compiler flags or order of the external libraries).
@cpraveen you can build 8.4.2 by checking out dealii-8.4 branch.
I checkout dealii-8.4 and ran cmake, it works with all the tests.
For dealii-master, I commented the tests as indicated by @tamiko
I am attaching both files.
@tamiko looks like there is a bug somewhere in our CMake scripts to find PETSc and SLEPc. For example in 8.4.2
SLEPC_LIBRARIES = /home/soft/lib/libslepc.so;/home/soft/lib/libpetsc.so
Whereas master has
SLEPC_LIBRARIES = /home/soft/lib/libslepc.so;/home/soft/lib/libpetsc.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/superlu-dist-5.1.1-xihvet3a2ezqf7eeqfg2kviloz32x4f5/lib/libsuperlu_dist.a;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/mumps-5.0.2-v3hfznlis3pv6cspzvq7dkklar3retvd/lib/libcmumps.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/mumps-5.0.2-v3hfznlis3pv6cspzvq7dkklar3retvd/lib/libdmumps.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/mumps-5.0.2-v3hfznlis3pv6cspzvq7dkklar3retvd/lib/libsmumps.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/mumps-5.0.2-v3hfznlis3pv6cspzvq7dkklar3retvd/lib/libzmumps.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/mumps-5.0.2-v3hfznlis3pv6cspzvq7dkklar3retvd/lib/libmumps_common.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/mumps-5.0.2-v3hfznlis3pv6cspzvq7dkklar3retvd/lib/libpord.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/parmetis-4.0.3-yp7iq7w2r2keb2lytcxb5n54wwjnmaob/lib/libparmetis.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/metis-5.1.0-w3r3pbpupdm7azqv67qspwv3lxnfkfcq/lib/libmetis.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/hypre-2.11.1-pqx3ju2shp4ijbrsglxhkoad4lnvea3h/lib64/libHYPRE.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/netlib-scalapack-2.0.2-hla7ude2ajky735eblwpjstlvvoxy7zr/lib/libscalapack.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/openblas-0.2.19-srysnt5ecruthexph3huhxjxxzygf2c2/lib/libopenblas.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/hwloc-1.11.4-7osold4o3nkppdzghwo5fjlgmxpsqb4h/lib64/libhwloc.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/hdf5-1.10.0-patch1-zmqjev5dqjqk7otblop2qrjea67zhntf/lib64/libhdf5hl_fortran.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/hdf5-1.10.0-patch1-zmqjev5dqjqk7otblop2qrjea67zhntf/lib64/libhdf5_fortran.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/hdf5-1.10.0-patch1-zmqjev5dqjqk7otblop2qrjea67zhntf/lib64/libhdf5_hl.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/hdf5-1.10.0-patch1-zmqjev5dqjqk7otblop2qrjea67zhntf/lib64/libhdf5.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/openmpi-2.0.1-asdjmd22cnyktv2athcx3ouhrozknk22/lib64/libmpi_usempif08.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/openmpi-2.0.1-asdjmd22cnyktv2athcx3ouhrozknk22/lib64/libmpi_usempi_ignore_tkr.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/openmpi-2.0.1-asdjmd22cnyktv2athcx3ouhrozknk22/lib64/libmpi_mpifh.so;gfortran;quadmath;m;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/openmpi-2.0.1-asdjmd22cnyktv2athcx3ouhrozknk22/lib64/libmpi_cxx.so;/home/spack/opt/spack/linux-opensuse20161217-x86_64/gcc-6/openmpi-2.0.1-asdjmd22cnyktv2athcx3ouhrozknk22/lib64/libmpi.so;pthread;dl
Same issues with PETSC_LIBRARIES. The rest of the diff looks reasonable.
p.s. I looked at FindPETSC.cmake, and don't see any changes that could lead to this.
@tamiko I am able to build dealii master :-)
@cpraveen I just wanted to say thanks for sticking this out and doing your best to help us get to the bottom of this. Its obviously been a bit tedious but there was clearly no other way to source the problem, especially given that none of us encounter this bug. Thanks also for communicating and reporting back as quickly as you did. Much appreciated!
on my mac PETSC_LIBRARIES and SLEPC_LIBRARIES are also gigantic with the current master:
PETSC_LIBRARIES = /Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/petsc-3.7.4-bghpsqhvkkm5k4o3inqus5pntathekbw/lib/libpetsc.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/superlu-dist-5.1.1-asq3w2bxlt2pxednom37ofp7keda6enq/lib/libsuperlu_dist.a;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/mumps-5.0.2-mvao5nagctwbqkgvozs7ymuwvqqe64ji/lib/libcmumps.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/mumps-5.0.2-mvao5nagctwbqkgvozs7ymuwvqqe64ji/lib/libdmumps.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/mumps-5.0.2-mvao5nagctwbqkgvozs7ymuwvqqe64ji/lib/libsmumps.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/mumps-5.0.2-mvao5nagctwbqkgvozs7ymuwvqqe64ji/lib/libzmumps.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/mumps-5.0.2-mvao5nagctwbqkgvozs7ymuwvqqe64ji/lib/libmumps_common.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/mumps-5.0.2-mvao5nagctwbqkgvozs7ymuwvqqe64ji/lib/libpord.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/parmetis-4.0.3-2wmuvqc3wbm5ucuybjjpljinuoafbk75/lib/libparmetis.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/metis-5.1.0-nhlczf7xkf3s7tzhee3fdjh3n5mclrt4/lib/libmetis.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/hypre-2.11.1-vgssr4dj7lndypwehylu4svccl6x6eem/lib/libHYPRE.a;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/netlib-scalapack-2.0.2-37dauqgiav5zcwxfzpvzvojhgoztmtxh/lib/libscalapack.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/openblas-0.2.19-xg7etkjyo7xjnvuojsdc2xoixesxoerh/lib/libopenblas.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/hdf5-1.10.0-patch1-nabnib7myy2do2ds7mmifoxmx7fk2oar/lib/libhdf5hl_fortran.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/hdf5-1.10.0-patch1-nabnib7myy2do2ds7mmifoxmx7fk2oar/lib/libhdf5_fortran.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/hdf5-1.10.0-patch1-nabnib7myy2do2ds7mmifoxmx7fk2oar/lib/libhdf5_hl.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/hdf5-1.10.0-patch1-nabnib7myy2do2ds7mmifoxmx7fk2oar/lib/libhdf5.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/hwloc-1.11.4-lzu3tv2n7s3r73qwgwngid4utt5frjzw/lib/libhwloc.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/openmpi-2.0.1-zgppod67vns7ojjqtw3qqwfid64jcclg/lib/libmpi_usempif08.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/openmpi-2.0.1-zgppod67vns7ojjqtw3qqwfid64jcclg/lib/libmpi_usempi_ignore_tkr.a;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/openmpi-2.0.1-zgppod67vns7ojjqtw3qqwfid64jcclg/lib/libmpi_mpifh.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/gcc-6.2.0-yuzfgyrrvsnlutzrys2hwgbr47km7cql/lib64/libgcc_ext.10.5.dylib;m;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/openmpi-2.0.1-zgppod67vns7ojjqtw3qqwfid64jcclg/lib/libmpi_cxx.dylib;/usr/lib/libc++.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/openmpi-2.0.1-zgppod67vns7ojjqtw3qqwfid64jcclg/lib/libmpi.dylib;/usr/lib/libSystem.dylib;dl
SLEPC_LIBRARIES = /Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/slepc-3.7.3-s7cpk4bcrperxtkpkfzzqgophdiipbqa/lib/libslepc.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/petsc-3.7.4-bghpsqhvkkm5k4o3inqus5pntathekbw/lib/libpetsc.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/superlu-dist-5.1.1-asq3w2bxlt2pxednom37ofp7keda6enq/lib/libsuperlu_dist.a;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/mumps-5.0.2-mvao5nagctwbqkgvozs7ymuwvqqe64ji/lib/libcmumps.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/mumps-5.0.2-mvao5nagctwbqkgvozs7ymuwvqqe64ji/lib/libdmumps.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/mumps-5.0.2-mvao5nagctwbqkgvozs7ymuwvqqe64ji/lib/libsmumps.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/mumps-5.0.2-mvao5nagctwbqkgvozs7ymuwvqqe64ji/lib/libzmumps.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/mumps-5.0.2-mvao5nagctwbqkgvozs7ymuwvqqe64ji/lib/libmumps_common.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/mumps-5.0.2-mvao5nagctwbqkgvozs7ymuwvqqe64ji/lib/libpord.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/parmetis-4.0.3-2wmuvqc3wbm5ucuybjjpljinuoafbk75/lib/libparmetis.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/metis-5.1.0-nhlczf7xkf3s7tzhee3fdjh3n5mclrt4/lib/libmetis.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/hypre-2.11.1-vgssr4dj7lndypwehylu4svccl6x6eem/lib/libHYPRE.a;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/netlib-scalapack-2.0.2-37dauqgiav5zcwxfzpvzvojhgoztmtxh/lib/libscalapack.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/openblas-0.2.19-xg7etkjyo7xjnvuojsdc2xoixesxoerh/lib/libopenblas.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/hdf5-1.10.0-patch1-nabnib7myy2do2ds7mmifoxmx7fk2oar/lib/libhdf5hl_fortran.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/hdf5-1.10.0-patch1-nabnib7myy2do2ds7mmifoxmx7fk2oar/lib/libhdf5_fortran.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/hdf5-1.10.0-patch1-nabnib7myy2do2ds7mmifoxmx7fk2oar/lib/libhdf5_hl.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/hdf5-1.10.0-patch1-nabnib7myy2do2ds7mmifoxmx7fk2oar/lib/libhdf5.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/hwloc-1.11.4-lzu3tv2n7s3r73qwgwngid4utt5frjzw/lib/libhwloc.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/openmpi-2.0.1-zgppod67vns7ojjqtw3qqwfid64jcclg/lib/libmpi_usempif08.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/openmpi-2.0.1-zgppod67vns7ojjqtw3qqwfid64jcclg/lib/libmpi_usempi_ignore_tkr.a;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/openmpi-2.0.1-zgppod67vns7ojjqtw3qqwfid64jcclg/lib/libmpi_mpifh.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/gcc-6.2.0-yuzfgyrrvsnlutzrys2hwgbr47km7cql/lib64/libgcc_ext.10.5.dylib;m;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/openmpi-2.0.1-zgppod67vns7ojjqtw3qqwfid64jcclg/lib/libmpi_cxx.dylib;/usr/lib/libc++.dylib;/Users/davydden/spack/opt/spack/darwin-sierra-x86_64/clang-8.0.0-apple/openmpi-2.0.1-zgppod67vns7ojjqtw3qqwfid64jcclg/lib/libmpi.dylib;/usr/lib/libSystem.dylib;dl
^^ Well, I spoke to soon. I correct myself to say that our machines somehow mask the problem :-)
@cpraveen :
I am able to build dealii master :-)
how?
After disabling Test DEAL_II_HAVE_USABLE_FLAGS_DEBUG, cmake finishes and I just build the code. That worked.
After disabling Test DEAL_II_HAVE_USABLE_FLAGS_DEBUG, cmake finishes and I just build the code. That worked.
wow... black magic here... :smile:
Let's wait for @tamiko to comment on these findings.
@jppelteret Thanks for the help. @davydden kept me going. I have a new Precision 7910 with 44 cores since a month, and have been waiting to get my codes running it. Almost there I think.
@cpraveen All credit to @davydden - I know I had nothing to do with it!
@davydden Yes, I vaguely remember that there was a bug in 4.8.2 that for PETSc and SLEPc not the full link interface was picked up.
Specifically, we parse the variable PETSC_WITH_EXTERNAL_LIB in lib/petsc/conf/petscvariables (same for SLEPc) and convert that to a list of libraries. We need the full transitive link interface for linking - so the line itself is not wrong. It is just... huge.
I still suspect something being sketchy with the toolchain (i.e. bsd ld, or gold from binutils).
Such obscure behavior is simply the perfect candidate.
I can imagine, that no one ever tests whether linking against ~100 external libraries without actually using a single external symbol works :->
@cpraveen Can you tell me what linker this is and what linux distribution?
$ ld --version
I will try to reproduce.
@tamiko :
I still suspect something being sketchy with the toolchain (i.e. bsd ld, or gold from binutils).
Yes, eventually it boils down to ld, maybe with specific flags which are also slightly different:
< # DEAL_II_CXX_FLAGS: -pedantic -fPIC -Wall -Wextra -Wpointer-arith -Wwrite-strings -Wsynth -Wsign-compare -Wswitch -Woverloaded-virtual -Wno-long-long -Wno-placement-new -Wno-deprecated-declarations -Wno-literal-suffix -fopenmp-simd -std=c++14
---
> # DEAL_II_CXX_FLAGS: -pedantic -fPIC -Wall -Wextra -Wpointer-arith -Wwrite-strings -Wsynth -Wsign-compare -Wswitch -Woverloaded-virtual -Wno-long-long -Wno-deprecated-declarations -Wno-literal-suffix -fopenmp-simd -std=c++14
namely -Wno-placement-new is added in master. But this looks harmless to me.
I am using OpenSuse Tumbleweed and
$ ld --version
GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.27.0.20161129-2
"make test" was ok.
I also ran step-1 and step-17 (uses petsc), which were fine.
@dealii/dealii I just hit this bug myself on Ubuntu@16, I am voting for temporary disabling DEAL_II_HAVE_USABLE_FLAGS_DEBUG in cmake/setup_finalize.cmake since this makes deal.II no-op compared to the last stable release 8.4.2.
From #3898 :
"""
Oh wow. So, probably a deadlock in the linker triggered by (a) our choice of program int main(){return 0;} and (b) -Wl,-as-needed in combination with (c) a ton of libraries.
"""
From #3898 :
"""
We, ourselves add -Wl,-as-needed to the linker flags. :-)
There is also one important difference. The problematic linker in question is gnu ld, I have -fuse-ld=gold. The difference in timing is remarkable:
$ test-with-ld.bfd-as-needed 31.82s user 0.07s system 98% cpu 32.280 total
$ test-with-ld.bfd-no-as-needed 1.27s user 0.17s system 97% cpu 1.484 total
$ test-with-ld.gold-as-needed 0.33s user 0.06s system 93% cpu 0.412 total
Maybe we simply run into some stupid timeout?
"""
@kronbichler @davydden
Can you two please install ld.gold (why doesn't your binutils already ship it?!) and test whether you can configure with -fuse-ld=gold (automatically set, if the gold linker is available, check detailed.log).
I will make a pull request to disable -Wl,--as-needed for the check.
Can you two please install ld.gold
i have stock Ubuntu 16LTS, frankly i have no idea how to mess around with linkers and binutils.
I will make a pull request to disable -Wl,--as-needed for the check.
:+1:
@davydden Can you quickly check why the check for -fuse-ld=gold fails exactly on your machine? I.e. is there something interesting for the test with -fuse-ld=gold in CMakeError.log?
can only do it on Monday, if I still remember to do so :smile:
Most helpful comment
@jppelteret Thanks for the help. @davydden kept me going. I have a new Precision 7910 with 44 cores since a month, and have been waiting to get my codes running it. Almost there I think.