Re: Bug#962675: can cdbfasta be marked Multi-Arch: foreign?

[Helmut Grohne <helmut@subdivi.de>]

Hi Andreas,

I'm sorry, I seem to have missed this reply earlier. Thanks for your
ping.

On Sat, Jun 13, 2020 at 12:46:28PM +0200, Andreas Tille wrote:
> On Thu, Jun 11, 2020 at 10:45:13PM +0200, Andreas Tille wrote:
> > > microbiomeutil fails to cross build from source, because it fails
> > > running cdbfasta with an "Exec format error".
> 
> I've just uploaded cdbfasta_1.00+git20181005.014498c+dfsg-1.
> You did not specified the exact error of microbiomeutil, but if
> you would specify the very command line we could add this to
> autopkgtest of the package (in case this might help).

The precise command is quite irrelevant. Any invocation of cdbfasta
fails in the same way. The error happens before any actual code from the
executable is run. Due to not being marked Multi-Arch something, the
host architecture cdbfasta is installed and any ELF executable for the
host architecture fails in roughly the same way. Either one gets a
direct "Exec format error" or the shell tries running the ELF binary as
a shell script. The problem is that we are trying to run a host
architecture binary.

The question now is: Does a build architecture cdbfasta behave exactly
the same way as a host architecture cdbfasta if the host architecture
one were actually runnable (e.g. using qemu)?

You can rephrase this question as:
| Is there any other way of interacting with cdbfasta or cdbyank where the
| processor architecture would matter?

To which you answered "I have no idea about these questions."

This seems to be kind of a show stopper to making progress here. We need
someone who has a good understanding of what this software does.

> Please check again since from my naive point of view the package
> should not cause any issues.

Any package which is not Multi-Arch tagged and ships ELF binaries in
$PATH can be a problem to cross building. cdbfasta is.

(Possibly though the issue is infeasible to fix and we may end up
closing the bug as wontfix. I don't think we're there yet.)

Helmut