-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linker used by GCC #185
Comments
I think the idea was to have these wrappers in place (in the |
It looks like you could configure GCC to use a specific default linker with
|
I recommend just configuring GCC to use the compat layer's linker (GCC from compat layer should already do that). |
We should probably also consider |
So, I had a somewhat deeper look into this. The configuration of GCC happens in toolchain_src_configure in |
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 easybuilders/easybuild-framework#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 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 |
@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:
I think the wrapper approach should address the In any case, I'll try to make some time to tidy things up and tie up loose ends before the 1yr anniversary... |
{2023.06}[foss/2022a] add bio packages - set 3
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.
The text was updated successfully, but these errors were encountered: