Status of mingw64 support
elandorr opened this issue · comments
Hi there,
what's the gist of official mingw64 support? I read MSYS2 hacked it together, but I don't have time to figure out how exactly.
Building individual files manually via the 'clean' winlibs.com chain works fine.
Microsoft now forces, literally, forces a gigantic spyware perma-online installer just to get the basic compiler. It is now completely useless and will never disgrace any system I deal with again.
Mingw works great, but integration with distutils is needed to not go mad. I don't know if this is a big change for you guys, or a simple config flip. If it is the latter, please tell.
Thank you
Hi elandorr. I'm the maintainer, but I'm unaware of the status you seek. If it is supported, you'll need to rely on the source or the community for support. I welcome you to explore the space and develop the expertise needed to investigate/implement the necessary support.
I did search through the issues, and it does appear as if there are others interested in MINGW support, but most around 32-bit. Maybe some of those users would have interest in working on this issue.
Microsoft now forces, literally, forces a gigantic spyware perma-online installer just to get the basic compiler. It is now completely useless and will never disgrace any system I deal with again.
I understand your frustration, but please be aware that the Python Community Code of Conduct asks everyone to be respectful of others, which includes developers at Microsoft who have developed the compiler solutions some of whom might be here and those in the PyPA who have rallied their support behind the official compiler. You of course are not required to accept those approaches, but do please try to avoid using hyperbolic defamatory statements ("literally forces", "completely useless).
I'm unaware of the status you seek.
Given you're the maintainer that is a bit surprising, the internet is full of threads on this issue. Currently, you are forced, and yes, that word is appropriate, to use Microsoft's spyware. It's textbook definition spyware. Trying to use MinGW as instructed in the various documentations floating around fails, especially on x64.
This is outdated and non-functional:
https://wiki.python.org/moin/WindowsCompilers#GCC_-_MinGW-w64_.28x86.2C_x64.29
https://cython.readthedocs.io/en/latest/src/tutorial/appendix.html
A more recent issue right in your own tracker:
#34
You yourself were even active in one thread just a few months ago:
#78
I welcome you to explore the space and develop the expertise needed to investigate/implement the necessary support.
That's a very odd way of saying 'go hackjob it yourself'. I already did that for one-off compiles, but that's not scalable, and anything but clean. You need many projects in ordinary life and can't go on month long hunts to fix a single build. Or study one particular build system for months of the half dozen you typically deal with.
Years later, when you or someone else needs to look at that particular bit again, you're also causing huge delays for nothing as you have to keep track of all the hacks you were forced to create, and instruct people.
Judging from history, MinGW was well-supported for a while, so it's nothing new.
which includes developers at Microsoft who have developed the compiler solutions some of whom might be here
The wage slaves are obviously not to blame, they're just employees. I doubt your ordinary Microsoft coder has any desire to be a part of Microsoft's massively abusive business tactics. I doubt they're proud of their employer being in constant legal trouble over the abuse either, but they have to buy food, so they are forced to work on whatever they're ordered to.
and those in the PyPA who have rallied their support behind the official compiler
Their only redeeming situation is if they're old enough to have expressed such support before Microsoft started forcing people as they do now. A decade+ ago, you could get an offline copy just fine. Maybe even in 2015.
It would still be a move against the FOSS community, of which I'd consider Python to be a part of, but still better than forcing users like today.
but do please try to avoid using hyperbolic defamatory statements ("literally forces", "completely useless).
These are neither hyperbole nor defamatory.
'literally forces' - exactly what it says. You are forced to install spyware, there is no way around it. There isn't even a way to reverse-engineer it, as it is literally forced online abuse. Not that reverse-engineering would be reasonable by any means.
You cannot reverse engineer your way around a forced non-consensual network connection that holds the data you need to accomplish a basic task.
'completely useless' - exactly what it says. You cannot use an ordinary package for your work, making the entire product useless. You are forced to comply with the abuse or not use a (community made) package at all.
It's also abusive to play apologetic for a billion dollar abuse machine. Even entire governments acknowledge their methods as outright criminal. Even the EU, which itself is involved in countless scams, acknowledges Microsoft's shady practices. And regularly fines them, to no avail. Microsoft decides it's more profitable to keep paying fines and keep continuing their abusive practices. The German security agency even officially published several reports on Microsoft's spyware in particular. (Available in English)
No, the individual dev is obviously not at fault. But that doesn't mean we should be playing along and furthering the destruction of a once-free ecosystem built with love.
As said in the initial post, MSYS2 hackjobbed their way around it before (https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-python), but all of that seems to have stopped:
And I have no time to become a hackjob-maintainer myself and coordinate around one tool of hundreds one requires.
Which leaves you being forced to use spyware as the only reproducible option. To even build a single ordinary package with a standard process that worked for a long time, you are now required to:
- Download a stub which literally (yes, literally, straight up copy) behaves like your average trojan dropper.
- Allow said trojan dropper to create dozens if not hundreds of connections that you can never filter in any human way.
2a. Microsoft's spyware even behaves like real life criminal trojans, with apparent obfuscation, constant changes no matter if you consented, host block circumvention, among other ways. The government report had some suggestions on how to stop some of it on Windows, but for developer tools no reproducible process exists. Even for Window itself, it's a Sisyphus effort. - Let it download many GiB of unwanted and unasked for further spyware, which also commits number 2 itself.
- Live with unwanted and non-consensual network activity on a permanent basis, as there is no way to reliably get rid of it.
If Microsoft still has not beaten you into submission and turned you into a good little yes-saying robot, you might research disabling services, or blocking particular hosts. Then you realize it's far too many, they constantly shift on updates and re-enable what you deliberately declined, and outright ignore user consent.
The only option to get the required toolchain offline is piracy as of today. Which is not an option for official usage, and not exactly trustworthy either, as you never know what else might've been added. It's also enormously bloated, as nobody pirates just the minimum required files, but only the entire multi-dozen GiB studio.
I've done the research, as have many others (some great experiments on SO). As of today, you are forced to allow spyware, or you cannot use basic distutils builds. Period.
My inquiry is about the current status of the threads I linked; how the maintainers suggest remedying this without resorting to unmaintained hacks. I made a little hack based off information I found that works for one-off compiles, but that's not a permanent solution and in my case only works for one off cython which wouldn't require distutils to begin with, once you figured out the required flags (undocumented, but fortunately shared in some random SO post).
I also have to decidedly reject the notion of 'hackjobbing it myself'. This is why we have packages and maintainers who know said packages. If you start reinventing the wheel for every project and each of the thousands of packages your work/life/digital life depends on, you'll never finish anything. It's not the job of developers to dig into often decades-old threads and create patches for problems that should never have existed at all. At that point, you might as well create TempleOS in a Herculean effort.
I just needed to build a simple package and hoped you'd have a trivial official method while we wait for it to be fixed cleanly for all…
Have a great week nonetheless!
May all your code compile and your network connections be deliberate and consensual...
Yeah, I got sidetracked a bit on that topic.. but we still plan to get vanilla distutils/setuptools working in MSYS2.
[more gripes about Microsoft]
Perhaps I was unclear. Please refrain from using this forum as a sounding board to gripe about others (companies or whatever). Stick to the topic of what distutils can or can't do for its users. If you wish to vent about other topics, I suggest you take that elsewhere like a blog or reddit. Thanks.
That's a very odd way of saying 'go hackjob it yourself'.
It's odd because that's not what I'm trying to say. I'm asking those who are invested and interested in a feature to take responsibility for owning the design and implementation. Other options are to create a bounty or negotiate some funding or convince someone else to get it done.
I volunteer my time to ensure that the project is making progress in its key objectives (right now to ensure a transition from distutils in stdlib) and to support community contributions. If you're not capable or willing to learn the software and implement a robust design, then I agree, it may not be worth your time. If on the other hand, you'd like to invest some time and come up with a reasonably sound design, I'll donate my time to critique and refine the solution, roll it out to users, respond to regressions, and maintain the software going forward.