binutils: Only embed zlib if listed as a build dependency

[geimer]

Addresses #1350 in conjunction with easybuilders/easybuild-easyconfigs#8340

This does not address the issue that libz.a is included in libbfd.a when specified as a build dependency. At the moment, I don't believe that this is fixable at all without rewriting parts of the Makefile(s).

[boegel]

@geimer Since we're currently only including zlib as a build dep, this doesn't actually change much for existing easyconfigs (except when people have their own binutils easyconfigs where zlib is a runtime dep already), right?

I'm aware that we're changing that in easybuilders/easybuild-easyconfigs#8340, just trying to make sure I have a good view on this w.r.t. backwards compatibility, since the idea is to include this with EasyBuild v3.9.1...

How much of a problem is it that libz.a is still embedded in libbfd.a?
In other words, if we merge this together with easybuilders/easybuild-easyconfigs#8340, is #1350 actually fixed, or not?

[geimer]

Since we're currently only including zlib as a build dep, this doesn't actually change much for existing easyconfigs (except when people have their own binutils easyconfigs where zlib is a runtime dep already), right?

It should be a drop-in replacement with existing easyconfigs, correct.

How much of a problem is it that libz.a is still embedded in libbfd.a?

With the modified easyconfigs for newer binutils, this should only happen for binutils built with dummy, which is only used for bootstrapping GCCcore and binutils built with that GCCcore (and stuff explicitly using the dummy-built binutils, but these should be rare, no?). Thus it's unlikely to be a huge problem. If you want that also fixed, I currently only see two options: (a) require zlib as an OS dependency for the dummy-built binutils and not embed anything (thus dancing around the conflicts and module switch problems) or (b) mess around in the Makefiles even more. While (b) may be doable, it requires much more investigation, i.e., postponing the fix to some release in the future.

In other words, if we merge this together with easybuilders/easybuild-easyconfigs#8340, is #1350 actually fixed, or not?

With both PRs merged, #1350 should be fixed for everything built on top of GCCcore using the binutils built with that GCCcore, as the latter no longer embeds zlib.

[boegel]

lgtm, will test this extensively both with existing easyconfigs and easybuilders/easybuild-easyconfigs#8340 before merging...

[boegel]

Tested with a range of existing binutils easyconfigs old & new (which still have zlib as a build-only dep), no problems found.
Working test reports for easybuilders/easybuild-easyconfigs#8340 are under way...

[boegel]

No surprises during testing, so going in, thanks @geimer!