The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

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

2014-12-20 7:08 GMT+01:00 T. Joseph Carter:


The choice isn't entirely arbitrary - sjlj still incurs a runtime hit of about 10 - 20% in exception heavy code.

With dwarf you don't have the runtime cost, at the expense of more bloated object code.

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:

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.

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:

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.

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

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).

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

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

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

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.

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.

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:

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.

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.

 

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

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.

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.

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.

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

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

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:

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

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]

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

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

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?

Well yeah it's not really that complicated, just download the binary file and extract it in c:\mingw .

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