Ludovic Courtès <l...@gnu.org> schrieb: > Volker Grabsch <v...@notjusthosting.com> writes: > > > The "gen-scmconfig" script includes a mix of native and > > cross headers, which goes horribly wrong when performing > > win32 cross compiling. > > What happens exactly?
I don't think that the exact error messages are relevant here (some conflicting definitions of various symbols and types, resulting in various compiling errors), because this is a general thing: You can't expect such a mix of headers to work properly. More concretely, when building "gen-scmconfig" with the native compiler, you can only expect the native headers to be available, not the cross headers. Well, the cross headers _are_ available, but only because you add their include paths via "-I", which is certainly not a sensible thing to do: You force the native compiler to include headers written to be used by the cross compiler. You simply can't expect that to work. Don't #include cross headers in a native build. > > Is it really necessary to #include > > the "uniconv.h" from the cross system and to provide corresponding > > SCM_ICONVEH_* constants? > > The idea is to avoid including libunistring headers in public Guile > headers, so that the dependency on libunistring isn’t visible from the > outside. > > Perhaps we could extract the values in some other way, but I’d like to > make sure I understand the problem before attempting something. I hope my explainations above help to make the issues more clear. BTW, you can easily reproduce the issues by installing "Mingw-cross-env" on your system, if you like. http://mingw-cross-env.nongnu.org/#tutorial Greets, Volker -- Volker Grabsch ---<<(())>>--- Administrator NotJustHosting GbR