SDL and MingW (here we go again…) |
Joseph Carter
|
On the docs list, we get the quick feedback for the SDL wiki, and we
got this incredibly not-helpful bit of feedback recently: On Tue, Dec 16, 2014 at 07:45:09AM +0000, Quick Feedback Form wrote:
Oh BTW Sam, can we have a space after that : in the template email? ;)
…I could say many things here about the above lines, but I won't. What I will say is that setting up SDL under MingW is NOT trivial, and indeed I never really succeeded in the endeavor 100%. I am aware that it is far, far simpler to set up a cross-compile environment because of MSYS issues—or that used to be true. I have no idea if it still is. So once again, if someone who has this working can provide some info as to what works for them, I'll be happy to actually take another stab at it and document the resulting setup. My understanding goes something like this: 1. You DO NOT actually have a realistic choice of MingW32 or MingW-w64 at this point if you want stuff to work right. You're getting MingW-w64. 2. Nutshell, get this for Win32: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.2/threads-posix/dwarf/i686-4.9.2-release-posix-dwarf-rt_v3-rev0.7z/download You can't get SEH on Win32 (which would be best case), so the choice of the other two is fairly arbitrary. The crowd seems to be preferring dwarf. Also went with POSIX threads for the same reason. If you have good arguments for other choices, reply and say so. :) This step is skippable if you have no desire to ever build for Win32. 3. If you have Win64, also get this: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.2/threads-posix/seh/x86_64-4.9.2-release-posix-seh-rt_v3-rev0.7z/download On Win64, SEH is the "only" choice really so you can theoretically catch exceptions from Windows' DLLs. POSIX threads chosen again, and again if you have an argument against it, please make it. :) 4. Get MSYS I cannot tell you where to get it from, what version, etc. If someone knows of a distribution of MSYS 2 with a working hg, which is kind of important for SDL, please tell me! 5. Install the compiler(s) and MSYS, set up a console It is possible to install MSYS once and change your path to choose a gcc toolchain for 32/64 bit. If there's a more preferred way to make building both 32 and 64 bit versions of things at the same time easier, I don't know what it is. If you do, tell me. :) With a few things answered (most importantly where to get a decent MSYS setup), I'll be happy to turn those into a more genericized and hopefully future-proof version of this that walks through setting it all up and we can find somewhere to put it, add it to the wiki, whatever. The key question is still MSYS. Joseph _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
SDL and MingW (here we go again…) |
SDL and MingW (here we go again…) |
MrOzBarry
|
Also, just as a note, you don't really need hg working in your MSYS environment, just as long as it works on the native level (and hg supports all mainstream OSes, last I checked).
On Sat, Dec 20, 2014 at 1:47 AM, Jonas Kulla wrote:
|
|||||||||||||||
|
Re: SDL and MingW (here we go again…) |
mr_tawan
|
AFAIK hg is just a set of python script. As long as you have python running in your MSYS environment, it should run without problems. I think you could also install mercurial separately from MSYS and update your PATH environment variable.
FYI: I'm using MSYS2 (with Mingw64 suite) in my main setup. I think it much more easier to manage as it has much better package management (pacman from Arch Linux). Mercurial is available in MSYS2.
|
|||||||||||||||||
|
SDL and MingW (here we go again…) |
Joseph Carter
|
When I last tried it, MSYS2 was in a pretty seriously "not done" state and you pretty much didn't have packages or a package manager yet. You basically wound up with some user's snapshot of everything they cared to make work (with things like Python not necessarily working for anyone else in the resulting directory when unpacked on YOUR system.) This was around the time of the SDL 2.0 release, mind you.
Okay, that resolved which compiler(s) to get, which MSYS, and if MSYS2 is actually using pacman, it even resolved which Python. That just leaves which console alternative (I'll figure that one out, there's only a couple choices and they do coexist well for testing), and tips for building both 32 and 64 bit versions. AFAIK, you don't get anything like gcc-select on Windows, so it's either full name to gcc or path tricks or both. That just leaves a good way to build multi arch. My understanding is that Windows doesn't do it like Linux, and nobody else does it like Apple. If anyone's got tips for a fairly generic build process for both, I'm all ears. For SDL's CMake users (both of you! ), CMake already kinda prefers to build outside the source dir, so it's just a matter of doing the deed in build_ia32 and build_x64 (and maybe ARM?) with the requisite tool chain in sequence. That's an easy script to write. Something similar is trivial for full automakemecrazy setups. Autoconf with DIY makefiles MAY work depending on how many stupid assumptions the Makefile author made. no truly universal solution can exist here, but if I can make the CMake and ../configure solutions work for the 90% of stuff it should work, I think I'll call it complete pending someone else contributing better ideas. NOW, if I go and test and write up this thing, who's willing to host it? Ideally I'd like to shove it into the SDL wiki since that means it won't go away and more people have access to maintain it if something changes like … the maturation of clang for Windows, integration of IDEs that aren't bash and vim for you lazy C++ weenies ( ), etc. Not to mention that putting it in the wiki gives us a path to and category for more newbie dev handholding sort of documentation. I could see a similar guide for iOS being useful in the future, for example. JosephSent via mobile On Dec 23, 2014, at 02:26, mr_tawan wrote:
|
|||||||||||||
|
SDL and MingW (here we go again…) |
Alexander Sabourenkov
Guest
|
MSYS? Is it still alive?
Five years ago I remembered what niche MSYS filled. Ten years ago I even used it. Today - what is the point? All that time wasted on setting it up is worth tens of Linux VMs, maybe thousands. Also - always build out-of-tree - makes cleanup entirely free of side effects. |
|||||||||||
|
SDL and MingW (here we go again…) |
Joseph Carter
|
The point of MSYS(2) is that the most effective cross-platform build
tool ever written for gcc-alike compilers is still autoconf, automake, libtool, and pkg-config. Like it or not, they "work" (as well as they ever work) everywhere, EXCEPT WINDOWS. And like it or not, nobody has really produced a good and functional alternative that can really claim to do the same thing. CMake promised that, and it might have delivered if it hadn't tried to basically be XSLT for build systems, with lots of obsolete docs on their own web pages for supported but niche features, oh, and that they didn't grab onto the idea of pkg-config and get with that tool's devs to turn their config file format into a toolchain-agnostic resource so that complex build scripts weren't needed. I realize I'm going off on a bit of a rant here, but think about it… SDL's build system is too complex for automake because it handles some unusual stuff when you're not doing Linux builds. Plus, I think Sam despises automake with a burning passion hotter than an emacs vs. vi flamewar. But that's likely only because of all the ridiculous things automake has to do in order to work everywhere. Still, let's look at SDL's configure.in, shall we? - A hack to try and preserve user requests for build options - Setting build version - Configuring libtool - Figuring out host/target for cross-compiling - Figuring out what the installed build system is - A hack for a UNIX tool too dumb to handle Windows paths on Windows - Check for Mercurial so you don't destroy the official autoconf setup. - A hack because autoconf might be running under cygwin to bypass using it - A CFLAG override mechanism - Hack to find system files like X11 because there's no standard here - Setting toolchain environment based on what we know so far - Hack for x64 Linux dists that use lib and lib64 rather than lib and lib32 - A function to find a library (because this isn't automake) - Checks for compiler options (can't divine them anywhere) - Option for debug/assertion level - Check for toolchain dependency tracking for make - Check for linker flag support - A test for libc - A test for a gcc feature - Definition of what files to build (rare for a configure, but okay…) - Optional features with their default settings - Override for OSS on OpenBSD, how to do PulseAudio on Solaris properly, etc… - Check for Wayland - Check for Mir - A comment questioning how to link Mir on BSD and OS X - Check for NaCl - Complex check for X11 because autoconf's own still can't always find it, let alone its various libs - Hacks for two OSes' locations for X11 libs by hand - A custom check for the Raspberry Pi's(? I think anyway) EGL video driver - Checks for other video driver support (OS X, Haiku, etc) - Checks for OpenGL, OpenGL ES, a random sound driver which seems to be in an odd spot in the config, etc - Checks for dbus, Linux events, udev, etc - A long list of OS-specific options for how to do pthreads (how p are they again?) - Test for Windows and specific checks for its build system and libs - Test for dlfcn and how to use it - Test for BSD USB driver - Test for how to do precise timing - Test for Linux version availability - Option to disable RPATH on systems that use it - A whole bunch of system-specific configuration options - A whole bunch of SDL buildsystem-internal regex line noise - Writing files - Telling the user what we did More or less. If you had something like CMake's compiler definition files included with gcc, clang, llvm, and their like in a common format, along with the rest of the toolchain, that'd be a lot. Get support for that into autoconf alone and rest assured that people WOULD start using them in other build systems because they'd support just about everything but the odd Microsoft compiler or the occasional non-gcc UNIX compiler from Oracle, Intel, or HP that don't see much use anymore. And anyone who DID use them would quickly produce shims for them because it'd make them instantly work with all of those build systems! Develop a standardized pkgconf format that is platform-agnostic and a means to know how to register it with the system, with the existing pkgconf as a reference implementation and watch it become even more widely used than it already is. In fact, if you extend the idea to support registering more than just how to compile and link a library and you've got gold. A way to find X11 (provided by whatever installed it for you), its headers and libs in general, and also the specific header or lib for a given X extension? Or OpenGL with a vendor string (Mesa, NVidia, Apple, etc), where the libraries and headers are, specifics for things like cg or cuda as well as glX, wgl, and other system glue. Oh, and a thing to query for the kinds of glue available in preference order. (The Mac has a few options, for example…) Another nice subsystem to standardize would be audio since there are many options and they now emulate one another pretty frequently. I'm oversimplifying it a little I know, but not as much as I'll be said to be doing. Joseph On Thu, Dec 25, 2014 at 03:20:14AM +0400, Alexander Sabourenkov wrote:
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Re: SDL and MingW (here we go again…) |
mr_tawan
|
There are people who prefer unix toolkit but have to work on Windows application (myself included). MSYS serves those people quite well. For me, having the same toolkit available in both Linux and Windows is a win, as working on cross-platform would be a lot more easier (I don't do cross-compiling, by the way). |
|||||||||||||
|
MingW-w64 working solution? (Was: SDL and MingW (here we go |
Joseph Carter
|
Just stumbled upon a (probably mostly) working solution for the
impatient trying to set up a working MingW-w64 build environment for SDL: https://wiki.allegro.cc/index.php?title=Building_with_msys2 Sam/Ryan, I can predict now that these instructions are NOT sufficient with the current release mainly because I distinctly remember issues with windres 32 and 64 bit on 2.0.3… If that's still hardcoded, can we fix that before 2.0.4? By the time I'm ready for this thing to be published somewhere, I want it to work with what's out there. The problem is that the program is always called windres.exe, and whichever one is in your path is the one that'll get used. My solution, if I got to fix it upstream, would be: /mingw32/i686-w64-mingw32-windres.exe /mingw32/windres.exe /mingw64/x86_64-w64-mingw32-windres.exe /mingw64/windres.exe Put both in your path so that the one you prefer to default to is first and provides plain gcc.exe and windres.exe (and friends…) Treat the other as a cross build where your compiler, linker, etc get specified by their full architecture name. In fact, I propose that I will file a bug upstream to make that change in a future package version and shove this email into the bug report as justification. MSYS2 supports native NTFS symlinks. Copying files is also a possibility, but one must beware of upgrades in that case. Otherwise, MingW-w64 just got a helluva lot simpler to set up. And yes, it supports hg too, I just tested it! But I gotta leave it there for now. :) Merry Christmas SDL list! Joseph On Wed, Dec 24, 2014 at 11:55:19AM -0800, T. Joseph Carter wrote:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
SDL and MingW (here we go againâ?¦) |
Joseph Carter
|
On Thu, Dec 25, 2014 at 05:11:14AM +0000, mr_tawan wrote:
Technically, if you have x86_64 Windows and you ever build for ia32 windows, you ARE cross-compiling. But MingW-w64 hides that detail from you for "simplicity" and because the resulting code will probably run on your system (drivers excluded of course!) But the idea of loading a whole VM just to compile something for the OS I'm running is the ultimate in laziness to me, especially if you've got to cross-compile to begin with. Joseph _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
SDL and MingW (here we go againâ?¦) |
Sik
|
2014-12-25 2:31 GMT-03:00, T. Joseph Carter:
To be fair, cross compilers *are* easy to deal with once setup, the biggest problem is on systems like Linux where everything assumes you'll use the compiler installed with the system and so using anything else requires settings scattered all over the place. Windows doesn't come with a compiler preinstalled so using a cross compiler isn't any harder than using a native one in comparison. The problems are more related to tools making assumptions than anything else, and on Windows you don't get to make many assumptions, so MinGW-w64 on it doesn't have to try hard (on Linux though it can get hell when you have to build a library as everything assumes you want to build for Linux by default and every library has its own way to cope with cross compiling...). _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
SDL and MingW (here we go again…) |
Alexander Sabourenkov
Guest
|
On Thu, Dec 25, 2014 at 8:11 AM, mr_tawan wrote:
Well, I know what MSYS is supposed to be used for. My point was that nowadays setting up, for example, an ubuntu VM with mingw64 inside is very simple and quick. Way simpler (and more repeatable and automatable) than setting up MSYS appears to be judging by the message I was replying to. And it's the same toolchain and shell, so it isn't like one has to learn much stuff one woudn't have to learn anyway with MSYS. Cross-compiling may sound scary, but in reality it's just a
parameter to ./configure, orÂ
to cmake (the file itself being some boilerplate googled up in about 2 minutes) I shudder to think what one is to go through to set up some kind of CI using MSYS. And if the project's meant to be build for linux too, one has to have some linux environment anyway. |
|||||||||||||||||
|
SDL and MingW (here we go againâ?¦) |
Alexander Sabourenkov
Guest
|
On Thu, Dec 25, 2014 at 8:31 AM, T. Joseph Carter wrote:
Loading up a VM might have been a big deal some years ago, but it is not now. If it's simpler and faster than trying to get some kind of half-hearted container (which MSYS, or cygwin for that matter conceptually are) to run, why waste time on the latter? It's not laziness, it's priorities. |
|||||||||||||
|
SDL and MingW (here we go again…) |
Joseph Carter
|
Just wait til you see what it takes with MSYS2. I did it on freakin' Christmas Eve in less time than it took to install the Windows 7 VM I did it in. The MSYS2 people did a fabulous job.
My request of Ryan or Sam to correct the windres issue is the only one remaining. JosephSent via mobile On Dec 24, 2014, at 22:05, Alexander Sabourenkov wrote:
|
|||||||||||||||||||
|
SDL and MingW (here we go againâ?¦) |
Alexander Sabourenkov
Guest
|
On Thu, Dec 25, 2014 at 9:04 AM, Sik the hedgehog wrote:
The problem of code with broken build systems being around certainly exists. Haven't seen a case that just would not cross-compile while happily compiling under MSYS though. The problem of cross-compiler toolchains not having some defined place to live in was more-or-less fixed by the release of Ubuntu 12.04 IIRC, I haven't had any problems with mingw64 since at least then. In fact mingw64 works better as cross-compiler than i686-linux-gnu-gcc, that is making 32-bit build is way simpler in 32-bit VM/container than on 64-bit host, where toolchain insists on picking up wrong headers and libs. |
|||||||||||||
|
SDL and MingW (here we go again…) |
Alexander Sabourenkov
Guest
|
On Thu, Dec 25, 2014 at 9:24 AM, T. Joseph Carter wrote:
Does that install time include the wait for the windres fix ? But let's not descend into install time comparisons between Windows 7 and some ubuntu flavors. Let hundred flowers bloom and all that. Â |
|||||||||||||
|
SDL and MingW (here we go againâ?¦) |
Sik
|
2014-12-25 3:28 GMT-03:00, Alexander Sabourenkov:
Nah, the problem was more that each library had its own quirks. Off the top of my head, from what I've built so far: - SDL2 worked mostly fine (using configure) but --disable-shared does something different than for most software using configure (I don't remember the details right now), so I need to explicitly not include that setting there. - PhysicsFS uses CMake and worked as expected. - libpng can use either configure or CMake, I tried with the latter but it turns out you need to explicitly tell it where zlib is installed or it'll try to use the native one instead (isn't the whole point of CMake to *avoid* this?) Bonus points for that not being documented (at least in an easy way to find). - zlib has configure but it doesn't support MinGW(-w64) at all so you have to use the dedicated makefile instead (and I don't remember if some stuff had to be changed for it to work, my script is overriding a variable but I don't remember if I had to change the file). Also you only get the static library this way, but eh, that isn't really a serious issue. - libogg and libvorbis use configure and worked as expected. But yeah, there was two different build systems there, and in three cases I had to still tweak how they worked anyway since they would not do what was expected by default. Jeez. At least this is something that you only need to do once (and if you update the library you already come prepared and don't have to figure it out again), and not having to spend time going to a Windows machine to rebuild a program certainly pays off in the long term Building using MinGW-w64 on Windows isn't anywhere as troublesome (even when you don't have MSYS, in fact I never figured out how to get it, let alone install), at least the quirks you'll have to deal with will be the same as you would with any native compiler. It's only when building from Linux that you start having issues.
That isn't really the problem, but build scripts going with the native compiler and in several cases it not being just a matter of following the standard instructions (see the list above). Trust me, I installed MinGW-w64 from the Ubuntu repo and I still had to deal with all that madness At least the cross compiler itself works like a charm, after I got the libraries built all I had to do was to set up Code::Blocks for it and the program built properly in the first try _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
mr_tawan
|
One problem of cross-compiling is when you are running a program, you have to deploy the program to the target platform before running the test. If it were just one time it would be ok, but imagine if I'm in the middle of debugging a platform-specific bug then it would be very tedious (unless there are things like remote debugging service), I'd endup have to deploy the program over and over again.
In native compiling, you'd have to build the program and run right away. In fact with IDE you could do that in one step. No hassle required. |
|||||||||||
|
SDL and MingW (here we go againâ?¦) |
Jonas Kulla
Guest
|
2014-12-25 8:49 GMT+01:00 Sik the hedgehog:
I'm pretty sure libpng's configure script uses pkg-config to determine zlib's location, at least I don't remember ever having to tell it where zlib was, neither with mingw nor the Android toolchains. In my experience cmake is generally always more trouble to make work (custom compiler definition files etc.) than an autotools based system. Â
Haha, zlib is indeed absolutely terrible to cross compile, which ironic considering their "zlib is rather portable and doesn't need much configuration" stance. I made it work by tricking their mutilated configure script into not detecting mingw and thinking it's just plain gcc, but in the end the trouble's really not worth if for a library that's probably been compiled millions of times. On Fedora, one has access to quite a lot of common libraries precompiled for mingw including zlib, so I just use that. Downside is that Fedora only packages sjlj mingw. |
|||||||||||||||
|
SDL and MingW (here we go again…) |
Alexander Sabourenkov
Guest
|
On Thu, Dec 25, 2014 at 10:49 AM, mr_tawan wrote:
For the cross-platform builds the VMs I usually configure only hold the toolchain and the build directory. Source code is mounted over the network from the host where the IDE lives, build artifacts go to either network-mounted or network-shared directories (some consistency in mount names helps with source-level debug), so from the IDE point of view, it's almost like the local build, only the compile/build commands are prefixed with 'ssh whatever' or whatever. That wouldn't work with an IDE that insists on having total control of the build system. This is not a problem though, since attempts at such control prevent automated builds/continuos integration, which isn't really acceptable anyway. |
|||||||||||||
|
SDL and MingW (here we go again…) |
M. Gerhardy
Guest
|
If you ever need help with a lib cross compiling for mingw32/mingw64, check out http://mxe.cc/ - they have a single make file for each of the libs that are supported... and they support a lot of libs. Even if you don't use mxe, you can still extract a lot of stuff from the mxe afford to cross compile a particular lib. They usually have patches available and send them upstream if something doesn't work out-of-the-box.
On Thu, Dec 25, 2014 at 9:50 AM, Alexander Sabourenkov wrote:
-- http://ufoai.sf.net http://sf.net/projects/ufoai |
|||||||||||||||
|
SDL and MingW (here we go again…) |
Joseph Carter
|
On Thu, Dec 25, 2014 at 10:36:56AM +0400, Alexander Sabourenkov wrote:
It really is the case that windres isn't "broken". It just isn't supplied in a form that allows you to just use the version in your path unless you've taken the time to explicitly set your path to use the correct one. If anything, the breakage I noted when I last worked on SDL in MingW was that SDL's buildsystem hardcoded a tool whose name might not be static. Indeed probably should not be static, since it should have the same prefix a cross-build gcc should. And having installed Ubuntu about 30 times this past week on a MacBook being used to build a slightly more intel-flavored RetroPie sort of project (external drive, Mac UEFI, nvidia-331, basically a perfect storm pain in the ass), I've got to say that Windows 7 and Ubuntu desktop take about the same time to install. Minimal is a little faster if you know exactly what you need to install. But that's fairly OT. Basically MingW went from being obnoxiously difficult to trivially easy if you know to ignore all the antiquated crap on the web about how to set it up. Me likey. Joseph _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
SDL and MingW (here we go againâ?¦) |
Joseph Carter
|
My MSYS instructions will accommodate broken build systems as best I can, but you may need to do the equivalent of a gcc-select command.
JosephSent via mobile On Dec 24, 2014, at 22:28, Alexander Sabourenkov wrote:
|
|||||||||||||||
|
SDL and MingW (here we go againâ?¦) |
Joseph Carter
|
Pretty sure MSYS2 is building zlib.dll using MingW-w64. They may have a patch for the build system.
Joseph Sent via mobile
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||
|
DarioOO
|
what about including dependencies like subfolders?
the whole point is that relying on "findPackage" may be a cheap way to get one package, but that's totally wrong to me, because someone may have installed different versions of a library and using a different version may cause troubles (totally wrong for cross-compiling and may cause issues if 3rd party software mess up your environment variables: like Visual Studio did once to me so I had to re-setup GCC). If you want to support more thant just your platform then you have also to start correctly and don't relying on findPackage. Basically i think Cmake i's more than needed to simplify life of developers, just remember to use it correctly (see my other post about Cmake) Basically I work without any assumption (so assume no software is installled and everything you need to build has to setup paths, it's a 5 minutes work to do the first time, after that you compile for X platforms as long as you can get a compiler for that platform). To give an example over my directory structure
In my opinion SJLJ should be used even if slower (it can catch exceptions not raised by your code), but people tends to use dwarf2^^ so I have to support it :p to get correct binaries, also using Cmake remove the need to use MSYS/MSYS2 (wich is pretty boring to get, I tried .. while CMake has 1 at once installer) [/code][/url] |
|||||||||||||||
|
SDL w/ MingW-w64: MSYS2 binutils ticket |
Joseph Carter
|
I've filed this ticket against MSYS2 regarding their binutils
packages. As MSYS2 is still relatively young, things like this can be more easily fixed upstream before "tradition" sets in to standardize broken behavior too much. :) https://sourceforge.net/p/msys2/tickets/118/ Resolution of this bug doesn't fix SDL to build on both 32 and 64 bit systems without path twiddling, but a look at what's in hg says that the fix involves line about 58 of configure.in: AC_CHECK_TOOL(WINDRES, [windres], [:]) …using AC_CHECK_TARGET_TOOL instead will have the desired effect if you are building with --target (which is what you should be doing to cross-compile…) Joseph On Mon, Dec 29, 2014 at 10:29:48AM -0800, T. Joseph Carter wrote:
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||
|
SDL w/ MingW-w64: MSYS2 binutils ticket |
Joseph Carter
|
It seems like the MSYS2 binutils maintainer may not be willing to make the packages cross-compile compliant. You're basically supposed to do the equivalent of logging out and back in as a different user (not that, but the rough equivalent in MSYS terms) to go from compiling 64 bit to 32. Fundamentally to twiddle your path so you have a different binutils and they don't have to distribute theirs with the standard prefix for a cross-compile. Which admittedly on windows means doubling the size of the binary package.
If you care that this be resolved, you might want to add yourself to the ticket. If they decide they're not willing, there's not a whole lot to be done. But if it's just me arguing against capital-T Tradition in the MSYS project dating back to Windows 95 by myself, I don't expect "but it works this way on literally everything that isn't windows!" to be a persuasive argument. :P Joseph Sent via mobile
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||||
|
my post ignored |
DarioOO
|
I did it and that was too easy to do.. and I don't used MSYS or MSYS2 (wich are a bit boring to download and install on windows).. My post just got ignored? |
|||||||||||||
|
Re: my post ignored |
mr_tawan
|
Well yeah it's not really that complicated, just download the binary file and extract it in c:\mingw . |
|||||||||||||||
|
Re: my post ignored |
DarioOO
|
and run update ! . the problem is not with MSYS itself, but about tools using MSYS, last attemp was with NetBeans (it requires MSYS for C++11 and MinGW) and it was a pain to configure even with a detailed step by step guide. I'm more happy when you just have to unzip stuff and setup 1 path or 2 |
|||||||||||||||||
|