Fallback to append if objcopy is not available on Linux

[nehaljwani]

No description provided.

[bwoodsend]

There's also a reference to objdump here.

If we were to do this I'd rather see binutils eliminated completely than have it conditionally used giving us another permutation to test. But I don't see how this can not become a regression of #1812.

[rokm]

The objdump and objcopy requirements on linux are documented in README, too.

I'd also prefer to deal with only single executable layout (the one where CArchive is stored in ELF section, even if there weren't for #1812).

But perhaps we can look into alternatives such as the ELF manipulation libraries mentioned in the linked conda issue (bonus points if that allows us to deal with rpath as well).

[nehaljwani]

The utilities from binutils are quite robust and battle-tested for different architectures. So depending on them for querying & manipulating ELF binaries makes a lot of sense.

I couldn't find a python library that understands and is able to manipulate ELF that well. The closest one that I could find is lief (no major release yet). It is already used by conda-build. I have opened a PR at #5996 to show that one can indeed get rid of binutils. That being said, the CI on GitHub doesn't seem to cover all architectures and *nixes, so we wouldn't know if we'll be breaking anyone unknowingly.

I would like know your thoughts on a different proposal: Add a CLI option for explicitly using the EOF append method and make the option an opt-in so that the user knows what they are getting into. And they can choose that if installing binutils is not an option. That way there is no automatic 'fallback' and wouldn't lead to any regressions.

[bwoodsend]

The lief option sounds pretty tempting. I'm giving it a trial run on some of the less common platforms which we don't or can't test on CI. So far I've found that it makes installation on musl Linux ugly because PyPI doesn't support musl wheels so lief has to be built from source. This drags in CMake, make and g++ and takes a very long time to compile (been going 30 minutes now - still not done yet...).

Honestly, this feels very extreme just to eliminate the dependency on something as standard as binutils. This comment, which seems to be the only motivation for it, doesn't feel very compelling.

[rokm]

I would like know your thoughts on a different proposal: Add a CLI option for explicitly using the EOF append method and make the option an opt-in so that the user knows what they are getting into. And they can choose that if installing binutils is not an option. That way there is no automatic 'fallback' and wouldn't lead to any regressions.

I'd really prefer not to go down that road... having such an option implies that such configuration is supported/endorsed and brings us back to having to support two different executable layout options for linux. Is installing binutils really such a problem in a linux-based development environment?

If someone really wanted to do EOF-appended builds, I'd prefer they patched their PyInstaller, and take full responsibility for it.