• If it finds an architecture-specific program it will use that
• If the target architecture is sufficiently close to the host architecture and it finds a host program, it will use that
• Otherwise error out. If it can figure out a way to help the user install a proper binutils it will print that

You can list the available binary formats with objdump -i

(BTW: it looks like a gas-only build is not as easy as I hoped, so I will look into emily's suggestion of building gas for each architecture in binutils-unwrapped-all-targets)

In reply to @emilazy:matrix.org
apparently .ci is expensive

So your suggestion for e.g. finding readelf is to:

• Look for a target specific readelf
• Look for a host specific readelf when target is sufficiently close to host
• Look for any readelf. If one is found, look for a objdump that looks to come from a similar place. If that is found, parse the output of objdump -i to see if your target architecture is in there. If it is, return that readelf
• Otherwise do the fallback of trying to guide the user to an install command

Or am I missing something?

Well, I wouldn't have separate "looking" and "running" steps. If running it fails with ENOENT, you didn't find it. My step three would be "run objdump -i and see if the target architecture is in there. If it is, run readelf.

Well, I wouldn't have separate "looking" and "running" steps. If running it fails with ENOENT, you didn't find it. My step three would be "run objdump -i and see if the target architecture is in there. If it is, run readelf."

The thing I'm trying to figure out is whether it's reasonable to just make install multiple times into the same prefix, with different configurations.