On Wed, Jan 20, 2021 at 8:58 AM Sébastien Hinderer <sebastien.hinde...@inria.fr> wrote: > > I am in charge of making cross-compilation possible for the OCaml > language, given that the compiler's build system uses autoconf. The > compiler is written in OCaml itself and has a runtime written in C. > > To start experimenting, I am trying to build a Linux to Windows64(MINGW) > cross-compiler. So the compiler's build and host system types are Linux > 64 and the target type is Windows64(MinGW). > > Since the compiler itself is written in OCaml, we also assume that the > Linux box has a working "straight" Linux OCaml compiler installed. > > I am trying to figure out in which way the build system needs to be > modified to support such a scheme.
Let me make sure I understand exactly what you're trying to do. You want to build a cross-compiler *of OCaml*, hosted on Linux, targeting mingw32. You already have a cross-compiler *of C* hosted on Linux and targeting mingw32, which should be used to compile the parts of the OCaml runtime that are written in C. > ./configure \ > --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu \ > --target=x86_64-w64-mingw32 Assuming this is the configure script for the OCaml implementation, this is abstractly the correct way to invoke it to make the cross compiler you want. > Since this invocation does not detect the C compiler properly Can you be more specific about what you mean by this? Which C compiler did it select and why was that wrong? > I switched to: > > ./configure \ > --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu \ > --target=x86_64-w64-mingw32 \ > CC=x86_64-w64-mingw32-gcc > > But that does not quite work because, since build and host system > types are equal, autoconf assumes we are not in cross-compiling mode > and thus tries to run the test programs it compiles, which is > actually not possible. I assume that what's wrong here is that > autoconf expects CC to point to a C compiler that runs on the build > system and produces code that runs on the host system and my > definition of CC breaks this assumption. Yes, exactly. This is the Right Thing in the common case, even when you are cross-compiling, because the common case is that you're not building a cross-compiler at all (so --target isn't being used) and, when you're cross-compiling, you don't *also* need a native compiler. ax_prog_cc_for_build.m4 handles the second most common case, where cross compilations need a native compiler as well as a cross-compiler: for instance, because there are compiled-code programs that need to run as part of the build. (It has some problems, but they're mostly problems for us Autoconf maintainers, not for you. ;-) Your situation is even more unusual: you are building a cross-compiler for language A, and you need a cross-compiler for language B in order to do so. I'm not aware of any off-the-shelf macro libraries that handle this, just because building cross-compilers is itself quite unusual. Most of the existing support for --target in Autoconf was tailored to the needs of GCC, and GCC handles this particular problem by *including* a C compiler -- if you configure GCC with --target=x86_64-w64-mingw32 --enable-languages=fortran (for instance) it will insist on also building the C cross-compiler that it will need to compile the Fortran runtime. > So, should I perhaps introduce a second variable to designate a > compiler that runs on the build system but produces code for the > target system, with a name like TARGETCC? Yes, I think that's right. I'd recommend you be consistent with the naming convention used by ax_prog_cc_for_build.m4 and call the variable CC_FOR_TARGET. You should automatically deduce a default value for this variable from the --target option, in the same way that AC_CHECK_TOOL uses the value of the --host option. You are also probably going to need to change all of your existing compilation checks -- which I presume are intended to probe characteristics of the *target* C runtime? -- to use CC_FOR_TARGET instead of CC. This is going to be awkward. We would be glad to work with you on improvements to Autoconf's infrastructure to make this job easier. And since you say autoconf "tries to run the test programs it compiles", that suggests you're using AC_RUN_IFELSE, which just plain doesn't work when cross-compiling; you will also need to find a way to probe the target C runtime *without* running test programs. For inspiration I suggest looking at _AC_COMPUTE_INT_COMPILE works -- https://git.savannah.gnu.org/cgit/autoconf.git/tree/lib/autoconf/general.m4#n3274 . > Or, since we will also need a C compiler running on host and producing > code for target, would it perhaps be better to introduce a HOSTCC > variable, which can also be used on the buildhost under the hypothesis > given above that build==host? I don't follow -- why do you also need a C compiler running on host and producing code for target? zw
