Dear Maintainer,

Since bioawk seems to execute dksbuild in order to generate data in fokker.dks which is not allowed during cross build
it could be simply built with build compiler

Since fokker.dks binary is not being installed, such a compilation would
not give any exec format problems. And building it via build compiler
does not seem a problem

I'm attaching my patch along, and will commit to salsa if it looks good.

Hi Nilesh,

As far as I can see, dksbuild.cc produces a binary format. You can
easily spot that by searching for fread and fwrite. This format is
composed of structures that happen to contain elements of type unsigned
long int. The size of this type is architecture-dependent. Unless I am
mistaken, the output becomes dependent on the bits of the architecture.

If you download triplane for various architectures and compare
/usr/share/games/triplane/fokker.dks, you'll spot that e.g. amd64 vs
i386 differs, but amd64 vs arm64 does not. Also s390x (which is big
endian) yields yet a different result.

NACK.

Also shipping the file in /usr/share is a lie. It's
architecture-dependent and therefore should go to /usr/lib. Better still
would be using an architecture-independent file format.

Helmut

Hi,

Yes I think that is correct. The data could be inside the executable
nowadays since the original reasons for keeping it separate have
disappeared.

/usr/share is indeed probably a separate bug. I don't think we (speaking
as upstream here) are keen on changing the data format though as this is
an original game from 1990s and is essentially in a maintenance-only mode.

Right.

ACK, this is probably because of my poor testing there. Admittedly, I
did not test extensively.

Thanks for the review!

Righty

Nilesh