search

dealii / dealii

The development repository for the deal.II finite element library
https://www.dealii.org
Other
1.33k stars 738 forks source link

CMake: remove automatic setup of ld.gold which is unmaintained and leads to user-visible warnings #15320

Open SomePersonSomeWhereInTheWorld opened 1 year ago

SomePersonSomeWhereInTheWorld commented 1 year ago

Running the make command on any of the example steps, e.g., step-5, this warning appears:

/usr/bin/ld.gold: warning: /usr/lib64/libc_nonshared.a(elf-init.oS): unknown program property type 0xc0000000 in .note.gnu.property section
/usr/bin/ld.gold: warning: /usr/lib64/libc_nonshared.a(elf-init.oS): unknown program property type 0xc0000001 in .note.gnu.property section

Supposedly binutils 2.35 fixes it. However RHEL 8 is stuck with version 2.30 as the newer version requires:

  - nothing provides libc.so.6(GLIBC_2.34)(64bit) needed by binutils-2.35.2-39.el9.x86_64
  - nothing provides libstdc++.so.6(GLIBCXX_3.4.29)(64bit) needed by binutils-2.35.2-39.el9.x86_64

Perhaps there's a way to use a container to provide this, or it's not worth the effort for a warning? Any other suggestions? This is with 9.4.2-r3.

drwells commented 1 year ago

It would be good to fix this but I'm not sure we can. Does this warning message appear when you compile and link other C++ programs on this computer?

SomePersonSomeWhereInTheWorld commented 1 year ago

It would be good to fix this but I'm not sure we can. Does this warning message appear when you compile and link other C++ programs on this computer?

No, just on the make command for the examples/steps.

drwells commented 1 year ago

I don't think any of us know how to solve this issue - I strongly suspect that the problem is outside of our control. My best guess is that one of our dependencies relies on those symbols.

SomePersonSomeWhereInTheWorld commented 1 year ago

I don't think any of us know how to solve this issue - I strongly suspect that the problem is outside of our control. My best guess is that one of our dependencies relies on those symbols.

Since it's a warning perhaps some FAQ or something in the docs?

I suppose there could be a way to run it in a container with the newer version.

tamiko commented 1 year ago

The problem is simply the fact that the ld.gold linker is deprecated and unmaintained. It does not support this .not.gnu.property extension, hence the warning.

ld.gold has been removed from upstream binutils, so we should consider dropping our automatic setup for ld.gold as well in the near future.

@RobbieTheK Can you try to either install ld.lld or ld.mold? If you reconfigure and recompile deal.II afterwards you can check in detailed.log that one of those linkers has been set up. You should see something like -fuse-ld=lld, or -fuse-ld=mold. You can also force ld.gold to be ignored by setting -DDEAL_II_COMPILER_HAS_FUSE_LD_GOLD=false. But a fair warning that your link time will be long if you don't install ld.lld, or ld.mold.

tjhei commented 1 year ago

ld.gold has been removed from upstream binutils, so we should consider dropping our automatic setup for ld.gold as well in the near future.

I agree. Gold had problems linking MPI builds on Ubuntu LTS for many years for example and that alone has caused quite a bit of a headache (see the many workarounds we have in our cmake configuration). mold is also significantly faster. On the other hand, gold is still quite a bit faster than bfd: https://github.com/dealii/dealii/pull/14806#issuecomment-1432244645

drwells commented 1 year ago

Looks like my knowledge of linkers is very out-of-date!

If gold is deprecated then what is GNU going to be shipping in the near future - just BFD?

tamiko commented 1 year ago

@drwells It seems so.

bangerth commented 1 year ago

Wow, that's frustrating. I didn't realize that they never got gold to be a complete replacement. It is so much faster than ld.bfd that it's hard to believe they give up on it.

Are ld.lld and ld.mold known to be feature complete replacements?

SomePersonSomeWhereInTheWorld commented 1 year ago

@RobbieTheK Can you try to either install ld.lld or ld.mold? If you reconfigure and recompile deal.II afterwards you can check in detailed.log that one of those linkers has been set up. You should see something like -fuse-ld=lld, or -fuse-ld=mold. You can also force ld.gold to be ignored by setting -DDEAL_II_COMPILER_HAS_FUSE_LD_GOLD=false.

Unfortunately this upgrades other dependencies that has caused issues upgrading in the past:

============================================================================================================================
 Package                Arch       Version                                       Repository                            Size
============================================================================================================================
Installing:
 lld                    x86_64     14.0.6-1.module+el8.7.0+15816+ec020e8f        rhel-8-for-x86_64-appstream-rpms      29 k
Upgrading:
 libdrm                 x86_64     2.4.111-1.el8                                 rhel-8-for-x86_64-appstream-rpms     163 k
 libdrm-devel           x86_64     2.4.111-1.el8                                 rhel-8-for-x86_64-appstream-rpms     167 k
 llvm-libs              x86_64     14.0.6-1.module+el8.7.0+15816+ec020e8f        rhel-8-for-x86_64-appstream-rpms      25 M
 mesa-libGL             x86_64     22.1.5-2.el8                                  rhel-8-for-x86_64-appstream-rpms     187 k
 mesa-libGL-devel       x86_64     22.1.5-2.el8                                  rhel-8-for-x86_64-appstream-rpms      52 k
 mesa-libOSMesa         x86_64     22.1.5-2.el8                                  rhel-8-for-x86_64-appstream-rpms     3.3 M
 mesa-libglapi          x86_64     22.1.5-2.el8                                  rhel-8-for-x86_64-appstream-rpms      66 k
Installing dependencies:
 libpciaccess-devel     x86_64     0.14-1.el8                                    rhel-8-for-x86_64-appstream-rpms      19 k
 lld-libs               x86_64     14.0.6-1.module+el8.7.0+15816+ec020e8f        rhel-8-for-x86_64-appstream-rpms     1.7 M
 valgrind               x86_64     1:3.19.0-1.el8                                rhel-8-for-x86_64-appstream-rpms      11 M
 valgrind-devel         x86_64     1:3.19.0-1.el8                                rhel-8-for-x86_64-appstream-rpms      94 k
Enabling module streams:
 llvm-toolset                      rhel8                                                                                   

Transaction Summary
============================================================================================================================
Install  5 Packages
Upgrade  7 Packages

But a fair warning that your link time will be long if you don't install ld.lld, or ld.mold.

Boy does it ever take a long time!

bangerth commented 1 year ago

Yes, the BFD linker is the bottleneck for many of us doing incremental builds on machines with many cores, because the BFD linker is not parallelized :-(

tamiko commented 1 year ago

@RobbieTheK You could compile and install ld.mold locally. Before you're doing this, what compiler are you using (just to check that it actually supports mold)?

SomePersonSomeWhereInTheWorld commented 1 year ago

@RobbieTheK You could compile and install ld.mold locally. Before you're doing this, what compiler are you using (just to check that it actually supports mold)?

It's a HPC cluster so several are available as modules, e.g., multiple version of gcc, gfortran, mpicc, et al.

Is the juice worth the squeeze for a warning?

tamiko commented 1 year ago

@RobbieTheK Probably not. As long as everything works you can also just live with this warning.