After a bit of research, I found what appears to be the source for these scripts at
https://build.opensuse.org/package/view_file/openSUSE:Factory/mingw32-filesystem/macros.mingw32 There is quite a bit of code there, so I don't claim to understand all of it, but what I have seen confirms my suspicions. For example, code such as PKG_CONFIG_PATH=%{_mingw32_ ..... [ on line 105 ] seems to be forcing pkg-config to use the mingw32 binaries thus overiding what we have set. Similarly for the --host= option (line 153) I suppose this might be what the mingw developers "want" - that all code on the planet is built using mingw -- but our goals are different. What we want is for everyone to be able to build PSPP for any platform (including mingw). To do this, we need the primary build to be cross compiled, but also a small native build as part of the process. What these mingw32- scripts seem to be doing is forcing *everything* to be cross built using mingw. Now this brute force approach happened to have worked fine until recently, because we had no requirement for an auxilliary native build. But now that requirement has changed, and so overriding things the way mingw32-* does is no longer going to work. Trying to do so is going to result in breakage. So I stand by my original opinion: Using mingw32-* is not an appropropriate way to cross-build PSPP. The appropriate way is documented in INSTALL - one does: <path-to-src>/configure --host=<cpu>-<vendor>-<os> ... [possibly other options according to where your mingw libraries are installed] That is what I have been doing repeatedly for the last few weeks without anything breaking. It is the way I would suggest to anyone else. If anything is unclear or incomplete in INSTALL, then please file a bug and we will fix it. If there is enough interest, we could also include a small wrapper script to configure and build a cross built PSPP on some very popular platforms. Regards, John On Tue, Jan 05, 2021 at 06:42:14PM +0100, Harry Thijssen wrote: Hi You can do a fresh install of openSUSE and run the included procedure to install the needed MingW environment and most of the needed dependencies. mingw-configure and mingw-make will be installed in that process. The way it is used is calling mingw32-configure instead of ./configure mingw32-make instead of make the same for mingw64. Stay safe . Op ma 4 jan. 2021 om 12:18 schreef John Darrington < j...@darrington.wattle.id.au>: > All I can say is that I have performed cross build targeting mingw many, > many, > many times in the last few weeks using the standard method of building, > and I > have not encountered any serious issues. Certainly nothing like the ones > that > both you and Fritz have encountered using these wrappers. > > So it seems reasonable to me, to suspect that these wrappers are relevant > to > the problem. I don't have these wrappers. If someone can give me access > to > them, then perhaps I can try to pinpoint the problem a little more > precisely. > > Until then, I would urge anyone trying to cross build for mingw (or any > other > platform) to use the standard method described in the INSTALL file, since > that > is what we recommend and what has always worked, and is the GNU standard. > > J' > > > On Mon, Jan 04, 2021 at 11:27:56AM +0100, Harry Thijssen wrote: > > It seems a bit bold to me to state that the developers of Mingw on > openSUSE > release macros for calling Mingw with incorrect flags. Especially as > this > always worked. > > The current situation is that the source of PSPP and the routines of > Mingw, > as released on openSUSE, are incompatible. I don't know if this can > be > solved and I am far from sure I can solve it. Especially as the > configure > for cross-compiling triggers a native build looks to me as a problem. > > I would prefer the option as Fritz suggested or a pre-condition of a > native > current PSPP build which can be called for cross-compiling. > > I think these problems will disappear, if the pspp is built in the way > > recommended in the > > INSTALL file. Just make sure the build and source directories are > not the > > same. > > > > If someone wants to work on this, I am happy to support him/here with > my OA > knowledge. > > Stay safe >
