> From: Keith Marshall <keith****@users*****> > Date: Sat, 18 Jul 2020 21:32:02 +0100 > > Requiring Python is also a problem, because I cannot redistribute it; > (the upstream build is done with MSVC, so depends on non-free Microsoft > DLLs, which I don't have a licence to redistribute, and I don't have the > energy to embark on, or to maintain, a MinGW build). If I do produce a > Python dependent build, then the onus would be on users to furnish the > Python installation for themselves, so they would have to jump through > that hoop anyway. (I do note that your ezwinport imposes this burden). > > What I might consider is to provide a python-independent build, for > those who want a free-standing MinGW build, and an additional (optional > alternative) python-dependent build, for those who may prefer it, and > thus accept the onus of installing python for themselves. I do the latter in my ports. I think offering 2 builds as you say is a good solution. > > The old MinGW site has expat, can't that be used? > > I can easily build an up-to-date expat. However, the latest release > gratuitously requires Microsoft's rand_s() function, which requires > Vista, or later, (or WinXP with non-free MSVCR80.DLL, or later). I have > a solution for this, (based on CryptGenRandom(), and thus supported all > the way back to Win95-OSR2, or WinNT4), but it will require an update to > mingwrt, and thus would need a WSL-5.4.1 release; (it would be a trivial > change, requiring no more than public exposure of an existing function, > which is currently implemented internally, with static linkage). FWIW, I'm using that old expat from MinGW in my builds.
Fork