Linker used by GCC

[ocaisa]

[ocaisa@gpunode1 gpu_support]$ which gcc
/cvmfs/pilot.eessi-hpc.org/versions/2021.12/software/linux/x86_64/amd/zen2/software/GCCcore/10.3.0/bin/gcc
[ocaisa@gpunode1 gpu_support]$ gcc -print-prog-name=ld
ld

Doesn't this mean that GCC will just use whatever linker is in the path when compiling code? This would mean that if we build software when we are not in a prefix shell, it will not default to the prefix linker. This is ok for us perhaps since we (hopefully) ensure that we do use a prefix shell, for users building on top of EESSI though, this could be a major issue.

[bedroge]

I think the idea was to have these wrappers in place (in the GCCcore module?) that will make sure that the right ld is being used (and rpath is enabled)? This was one of the hackathon topics https://hackmd.io/sLBLV7RDQdmyYfh1rYHGSQ, but I guess it still needs some more work (there are some links in the hackmd to open issues / pull requests).

[ocaisa]

It looks like you could configure GCC to use a specific default linker with

--with-ld=pathname

[amadio]

I recommend just configuring GCC to use the compat layer's linker (GCC from compat layer should already do that).

[ocaisa]

We should probably also consider --with-as=pathname...and probably look at how GCC is configured in the compat layer to see if there are other things we should add.

[amadio]

So, I had a somewhat deeper look into this. The configuration of GCC happens in toolchain_src_configure in toolchain.eclass. If it's not a cross compiler, then just the prefix is used (${EPREFIX}/usr), but the search path for programs for gcc resolves usually to ${EPREFIX}/usr/${CTARGET}/bin, which is where ar, ld, etc exist as symlinks to the real tools installed by binutils. Then where the links point to is controlled by eselect binutils (or binutils-config, same thing). I don't know what would be the best thing to do in your compatibility layer, but if you use simply ${EPREFIX}/usr/bin/ar and same for other tools, then which binutils gets used is still controlled by eselect binutils, which you can set as you wish for all compilers of the whole stack. I hope that helps you in making a decision.

[casparvl]

I think @bedroge is right. There was a hackathon item to not only have EasyBuild use rpath wrappers itself, but also install them with the compilers. See https://github.com/easybuilders/easybuild-framework/pull/4003 I cannot fully oversee if that would solve this issue, but I think so: I believe the 'real' linker (which would be the one from the compat layer) would be hardcoded into the wrapper at install time, but I'm not 100% sure. Loading the GCC module would then load the ld wrapper as well, which then knows how to find the compat ld.

Again, I'm a bit fuzzy on the details and we would really need to check that this is how it (will) work. The PR is also still in progress in EasyBuild, and it was also brought up there if it makes sense to install the ld wrappers with GCC: it should really be installed with binutils probably. But in that case, it doesn't help EESSI, since we filter binutils as a dependency (I think?).

[stderr-enst]

@casparvl thanks for commenting on the PR and highlighting this EESSI issue! I started the hackaton item and I've been really inactive on the PRs, since this always drops behind other work priorities. :(

To iterate a bit on the PR/Issues:

• Motivation: automatic wrappers could help when building user code with GCC modules in an RPATH stack. Users wouldn't have to think so much about what the RPATH business means, if they build their stuff with EESSI shipped compiler modules.
• I've hacked together a quick proof of concept that installs wrapper scripts when loading the compiler module (the open EasyBuild PRs/Issues). This is still WIP so the next step would be to clean up everything and put things where they should go.
• I should take the time to disentangle compiler and linker wrappers. So ld wrappers should probably move to binutils instead of dealing with them in GCC/GCCcore.

I think the wrapper approach should address the ld-issue mentioned here, but I'm not 100% sure myself. I also want to think about the --with-ld=pathname flag for a while.

In any case, I'll try to make some time to tidy things up and tie up loose ends before the 1yr anniversary...