search

rakslice / macemu

Basilisk II and SheepShaver Macintosh emulators
0 stars 0 forks source link

automatically set `dyngen.c` macros correctly for the actual target platform/arch when SheepShaver is being cross-compiled #65

Closed rakslice closed 3 years ago

rakslice commented 3 years ago

The CONFIG_$os and HOST_$arch style macros used in dyngen.c for #ifdefs come with remarks like this one for CONFIG_WIN32:

/* NOTE: we test CONFIG_WIN32 instead of _WIN32 to enabled cross
   compilation */

However in the existing code, they are not being set up correctly for this use; they are being set based on common platform/arch pre-compiler macros present in whatever compiler they are being compiled with, e.g.:

#ifndef CONFIG_WIN32
#if defined(__CYGWIN__) || defined(_WIN32)
#define CONFIG_WIN32 1
#endif
#endif

This is incorrect for the situation.

To be clear, for a particular source file that is actually being cross compiled when cross compiling SS for another arch, this would be correct; the file would compiled with a cross toolchain that is building for the target platform & arch and has built in defines to match as well as a set of target system headers, so using the common platform/arch pre-compiler macros is correct, and no special alternate CONFIG_* macros or whatever are needed in the code itself to handle that case. The comment will be confusing to people for this reason.

However when SheepShaver is being cross-compiled, dyngen.c itself is not being cross-compiled, it is being built to operate on code for the target platform that SheepShaver is being built for, but it runs on the host machine at build time, so is actually being compiled for the host machine where the rest of the compilation is taking place. So, being built with a native host compiler, not a cross compiler, but needing to work with objects and code for the target platform, it needs to not try to use common platform/arch pre-compiler macros from the compiler, which will be about the host platform, as a source of information about the target platform.

At the very least, just having this separate layer of macros would allow someone to manually override them on the compiler command line, and so would allow for cross compilation to be done with just a custom makefile and no further code changes.

However, ideally introspection would be done on the cross-compiler to find its macros, say at configure time, and settings of the HOST_* / CONFIG_* macros would be set appropriately based on that in a separate header, so that when dyngen.c is compiled (with HOST_CC) it has access to those.

I don't know to what degree autoconf already facilitates some or all of this.

rakslice commented 3 years ago

This is not the only cross compilation problem that BII/SS have; it also relies (especially for Unix) on configure-time tests of system behaviour to choose what features to enable at run-time, which of course doesn't work if the target system isn't the local one.

rakslice commented 3 years ago

Also in the case of dyngen.c some care should be taken to avoid a similar problem in headers that it includes (e.g. elf-defs.h)