Chocolate Doom

I am trying to compile the latest git for windows (I'd use stable the moment 2.1 is released, due to the no sound in multiplayer bug). I followed the instructions and installed mingw within cygwin, but I still get this error message
"No compiler found. Please install gcc!"

What am I doing wrong?

Not your fault; the build process for Windows is out of date. There's a little discussion from an issue I opened here: https://github.com/chocolate-doom/chocolate-doom/issues/422

I can post my build instructions later if you want. They're a bit hacky but they will result in a stable build you can use.

You could also check out Crispy Doom if you haven't already, since it's based on the Chocolate Doom git sources. Doesn't help if you're trying to make vanilla-compatible maps though.

I would appreciate it. The second reason I want to use the git until 2.1 comes out is the limited bex support added for freedoom string compatibility.

plums said:

Not your fault; the build process for Windows is out of date. There's a little discussion from an issue I opened here: https://github.com/chocolate-doom/chocolate-doom/issues/422

I can post my build instructions later if you want. They're a bit hacky but they will result in a stable build you can use.

You could also check out Crispy Doom if you haven't already, since it's based on the Chocolate Doom git sources. Doesn't help if you're trying to make vanilla-compatible maps though.

Highly appreciated - would love to have a newer base for my project.

Building Chocolate Doom latest git from source in Windows:

• Install Cygwin from https://cygwin.com/install.html
  
  
• Add Cygwin Ports to your Cygwin packages lists, following instructions at http://cygwinports.org
  
  
• For a 32-bit build, install the following packages and all dependencies:
  
  * automake
  * autoconf
  * bash
  * git
  * make
  * python
  * mingw64-i686-binutils
  * mingw64-i686-gcc
  * mingw64-i686-g++
  * mingw64-i686-headers
  * mingw64-i686-runtime
  * mingw64-i686-SDL
  * mingw64-i686-SDL_image
  * mingw64-i686-SDL_mixer
  * mingw64-i686-SDL_net
  * mingw64-i686-libpng (optional, for png screenshots)
  * mingw64-i686-libsamplerate (optional, for libsamplerate resampling)
  * mingw64-i686-flac (optional, for digital music playback)
  * mingw64-i686-libogg (optional, for digital music playback)
  * mingw64-i686-libvorbis (optional, for digital music playback)
  
  For a 64-bit build, change every instance of i686 to x86_64 in the packages above, and also in all of the following steps. (Untested! I do not have a 64-bit machine.)
  
  
• Open up a Cygwin terminal in your home directory. Get the latest Chocolate Doom git sources by typing
  
  git clone https://github.com/chocolate-doom/chocolate-doom.git chocolate-doom-git
  
  (If you aren't familiar with Cygwin or Linux terminals, you can copy that text in your web browser and paste it in a terminal by middle-clicking on the terminal window.)
  
  
• Here's the hacky part: I can't get the build process to recognize the mingw64-i686 libraries the normal way. Maybe there's an obvious step I'm missing, but what works for me is to add them to the path temporarily by typing
  
  export PATH="$PATH:/usr/i686-w64-mingw32/sys-root/mingw/bin"
  
  You can also add that directory to your Windows path if you prefer, which is maybe not a good idea but so far hasn't given me problems...
  
  
• You also want to set the SDL_PREFIX variable here I think.
  
  SDL_PREFIX=`/usr/i686-w64-mingw32/sys-root/mingw/bin/sdl-config --prefix`
  
  
• Do the autogen stuff, as per the build-chocolate-doom script.
  
  cd chocolate-doom-git
  mkdir autotools
  aclocal -I "$SDL_PREFIX/share/aclocal" && autoheader && automake -a -c && autoconf && automake
  
  
• Run configure, using the mingw environment
  
  ./configure --host=i686-w64-mingw32
  
  
• Finally, build Chocolate Doom!
  
  make
  
  The exe files will be in the directory chocolate-doom-git/src . Copy them to wherever you want. You also need to copy all the dll's from /usr/i686-w64-mingw32/sys-root/mingw/bin into that same directory, unless you added that to your Windows PATH.
  
  
• To update to the latest git version later on, you need to run these commands:
  
  export PATH="$PATH:/usr/i686-w64-mingw32/sys-root/mingw/bin"
  cd chocolate-doom-git
  git pull
  make
  

That should be it, let me know if it works or doesn't work for you.

I just tried this. I couldn't change the volume whine in native midi/timidity mode. Otherwise it works fine.

Danfun64 said:

I just tried this. I couldn't change the volume whine in native midi/timidity mode. Otherwise it works fine.

You mean the music volume right? Could you with Chocolate Doom 2.0.0 ? I can't on either, as I understand it it's an issue with SDL Mixer not supporting Windows' audio mixer fully, or something like that.

Glad to hear it works otherwise.

Yes, I meant music, and by whine I meant while. I don't have any time to test 2.0 as I'm going to bed in a few minutes.

BIG thanks Plums!
May take me a few days but I'm looking forward to the 64bit build option.

I just tried 2.0, and it seemed like "Native Midi" didn't work at all.

edit: I just found out something. In 2.0 on windows, it doesn't seem to accept soundfonts in a timidity cfg, but it does support Gravis Ultrasound patches, as crude.cfg from freepats works properly. Also, the 2.1 git seems to recognize my timidity.cfg installed on my computer and unconditionally uses it unless I set the music to off or opl.

Also, for the 2.1 compiling, are all those dll's really neccesary?

edit 2: For fun I tried the 2.1 build in an old win98se2me (with kernelex) laptop and I get an illegal operation error regarding libpng15-15.dll

MinGW-w64 will require a lot more DLLs than the old MinGW32 style of builds. It's kind of annoying, but oh well... it's basically taking up a more Unix-y way of doing library dependencies.

Also it's worth noting that MinGW32 and MinGW-w64 are totally independent projects that share no code. It's stupid such a confusing naming scheme was done... I think MinGW-w64 had the intention of merging back into the upstream and becoming the official project, but that never happened. Another big difference is that MinGW-w64 has no support for Windows 9x or NT 3.x/4.0, you need to stick with MinGW32 for such support. Trivial binaries might run but anything as complicated as SDL/Chocolate has no chance.

I don't understand what you are saying. Are you saying that Chocolate Doom can't compile with regular MinGW32 or are you saying that small programs compiled with MinGW-W64 will run on Win9x/NT3.5/NT4, just not Chocolate Doom?

If you only mean the ladder, can you post instructions for compiling with regular Mingw32 if possible?

Thanks for the instructions plums.

If you're interested, maybe you could take a look at fixing the build script? That would be much better than relying on instructions on a forum that are inevitably going to get lost in a thread this huge. The script is supposed to do almost all the things you list.

Just for reference, I don't have any immediate plans to distribute 64-bit Windows binaries of Chocolate Doom. But it's nice to know that it does compile and work.

fraggle said:

If you're interested, maybe you could take a look at fixing the build script? That would be much better than relying on instructions on a forum that are inevitably going to get lost in a thread this huge. The script is supposed to do almost all the things you list.

I'd be happy to update the build script. My concern (and the reason I haven't done so already) is that this build process feels a bit like a stopgap measure to me since (1) it relies on the unofficial (though well-maintained, it seems) cygwin-ports repository, and (2) adding the dll directory to the path seems especially like a quick-fix. Neither of those are for lack of trying other solutions mind you.

If you're OK with both of those things, then sure, I'll update the build script. I suppose even a hacky process is better than the non-functioning one that exists currently.

plums said:

(1) it relies on the unofficial (though well-maintained, it seems) cygwin-ports repository,

I think I'm probably missing something here, but what's "unofficial" about Cygwin's package collection? Is it not part of the Cygwin project? Genuinely curious because I don't understand your point here.

and (2) adding the dll directory to the path seems especially like a quick-fix. Neither of those are for lack of trying other solutions mind you.

Do you need to copy the DLLs to compile, or just to run the compiled executable?

fraggle said:

I think I'm probably missing something here, but what's "unofficial" about Cygwin's package collection? Is it not part of the Cygwin project? Genuinely curious because I don't understand your point here.

The process above relies on http://cygwinports.org/ which is a repo of additional binary and source packages for Cygwin environments, and not officially endorsed or tied to the Cygwin project. This is in lieu of building SDL and other libraries from scratch, which I got fed up with after they required hacking (to avoid the -mno-cygwin flag) or didn't work properly (I couldn't get ogg/flac working at all when building it from source).

It appears quite well maintained -- it started in 2007 I believe, and seems to receive regular updates especially when security vulnerabilities are concerned. Nonetheless it is a separate entity from the main Cygwin project.

Do you need to copy the DLLs to compile, or just to run the compiled executable?

The DLLs need to be copied, or in the current path, both for compilation (all the usual parameters for specifying include directories were failing me) and for running the compiled program.

plums said:

The process above relies on http://cygwinports.org/ which is a repo of additional binary and source packages for Cygwin environments, and not officially endorsed or tied to the Cygwin project. This is in lieu of building SDL and other libraries from scratch, which I got fed up with after they required hacking (to avoid the -mno-cygwin flag) or didn't work properly (I couldn't get ogg/flac working at all when building it from source).

Okay, no. That doesn't work. The build script is used on multiple platforms - Linux and Mac in addition to Windows. So it needs to do the SDL build itself.

I've heard that -mno-cygwin isn't supported by gcc any more, so that probably needs to be fixed. It looks like that parameter actually comes from SDL, so by all rights it's probably SDL that should be fixed. But maybe they don't care about the 1.2 branch any more.

But it looks like removing the -mno-cygwin might be (?) as simple as just providing the right --host parameter, eg. --host=i686-w64-mingw32

The DLLs need to be copied, or in the current path, both for compilation (all the usual -L and -D flags were failing me) and for running the compiled program.

Is it possible to set LD_LIBRARY_PATH to point to them?

fraggle said:

I've heard that -mno-cygwin isn't supported by gcc any more, so that probably needs to be fixed.

Indeed, I think that was from my report on the Chocolate Doom github issue tracker :)

As far as I can tell, the SDL team has been telling people to use gcc 3.x for years now to make -mno-cygwin work, so I'm guessing they have no intention of updating the 1.2 branch to fix it.

I was able to compile SDL with mingw64-i686-gcc but I had to filter out -mno-cygwin somehow. I can't remember exactly, working with alternate compilers isn't something I've done before so I was sort of fumbling my way through it. Perhaps specifying the host will work properly.

Is it possible to set LD_LIBRARY_PATH to point to them?

Do you mean exporting that as an environment variable? Can't remember if I tried that or not.

It was getting hair-pullingly frustrating at the time, so when I found a process that worked I said "good enough!" and just settled for that. However it's been long enough that I could take another crack at it.

plums said:

Indeed, I think that was from my report on the Chocolate Doom github issue tracker :)

Sorry, I'm sure you're right. It's hard to keep track of all these bug reports.

As far as I can tell, the SDL team has been telling people to use gcc 3.x for years now to make -mno-cygwin work, so I'm guessing they have no intention of updating the 1.2 branch to fix it.

I was able to compile SDL with mingw64-i686-gcc but I had to filter out -mno-cygwin somehow. I can't remember exactly, working with alternate compilers isn't something I've done before so I was sort of fumbling my way through it. Perhaps specifying the host will work properly.

I'm pretty sure it will. I think the best way to think of this is like you're doing a cross-compile - building on Cygwin but targeting MingW. I've cross-compiled from Linux to MingW plenty of times and it works fine, so this may actually make things a lot simpler.

I'm planning on doing one more release on SDL 1.2 and then going all-out for the next version on switching to SDL 2.0, so hopefully that should improve things as well.

Do you mean exporting that as an environment variable? Can't remember if I tried that or not.

Yes. LD_LIBRARY_PATH is the standard-ish environment variable on Unix systems that tells the runtime linker where to look for libraries.

It was getting hair-pullingly frustrating at the time, so when I found a process that worked I said "good enough!" and just settled for that. However it's been long enough that I could take another crack at it.

I know that feeling!

Danfun64 said:

I don't understand what you are saying. Are you saying that Chocolate Doom can't compile with regular MinGW32 or are you saying that small programs compiled with MinGW-W64 will run on Win9x/NT3.5/NT4, just not Chocolate Doom?

If you only mean the ladder, can you post instructions for compiling with regular Mingw32 if possible?

I mean that programs compiled with MinGW-w64 will not run on Windows 9x/Me/NT3.x/NT4. Only programs compiled with MinGW32 will do so.

fraggle said:

Just for reference, I don't have any immediate plans to distribute 64-bit Windows binaries of Chocolate Doom. But it's nice to know that it does compile and work.

Adding to the confusing names... MinGW32 is capable of building 32-bit and 64-bit binaries, and MinGW-w64 is capable of building 32-bit and 64-bit binaries, too. -w64's goal was to support Windows 64-bit with a clean-room implementation (mingw32 uses MSDN code of questionable copyright status), and has been part of upstream GCC for a few years now, and since then gained 32-bit support as well, but they're fairly explicit about supporting only Windows 2000 and newer (exempting Windows Me... which was released after Win2000, but not part of the same series, WinME is pretty much Windows 98).

Trust me, I wish that kind of naming nonsense didn't exist, but it does :)

As an aside, I build the Crispy Doom Windows executables completely without Cygwin. I just install MingW32 + MSYS, the latter of which is some kind of boiled down version of Cygwin that only ships the bare minimum to be able to run a ./configure script and Makefiles. The advantage is that binaries built in this environment are not linked against any cygwin-specific libraries. Edit: Of course, this means that I had to build all of SDL, zlib, libpng and libsamplerate *once* in this environment before I could start building Crispy Doom.

Regarding MingW-W64, I think it started out as a fork to add support for the Win64 ABI, but never got merged back into the mainline project. Since then, it gained support for the Win32 ABI as well and is considered by many as the more complete and cleaner implementation, AFAIUI. E.g. Debian has replaced MingW32 with MingW-W64 for cross-building purposes.

So if I were to "build all of SDL, zlib, libpng and libsamplerate ... in this environment", how would I link the libraries to chocolate doom? Would I copy the lib, include, bin, whatever folders to the root directory of mingw32?

As an aside note, it always seems easier to compile in linux than windows for me. All I have to do is apt-get the dependencies, compile and install any dependencies not in debian, and then simply make. Why does Windows have to be more complicated then that :P ?

Generally, it is not much more complicated. The Makefiles of said projects usually have an install rule, which you can call to install the headers and libraries into the designated locations in the file system. Here, "file system" in MSYS actually means a sub-directory of your MSYS installation directory. This is typically something like c:\mingw\msys\1.0, which gets "mounted" as '/' in MSYS.

Okay, good news - I can compile Chocolate Doom 2.0.0 using Cygwin and the normal build script. A couple of things:

You need to provide the -host parameter. ie:

bash build-chocolate-doom -host=i686-pc-mingw32

This only works with mingw32. I tried mingw64 and it fails to compile. I'm planning to stick with mingw32 for official builds anyway so that Chocolate Doom will run on Win9x, just for the novelty.

I updated the list of packages here so this should now be up to date. The mingw gcc package is now called mingw-gcc-core.

I haven't tried building a Git build yet, but I'm doing this now (I have a Windows VM, but it's running on an ancient EEEPC which doesn't even have hardware virtualization support - imagine how slow this is). Once I have a functioning Git build I'll try building with the extra libraries as well.

so the g++ thing wasn't necessary?

edit: tried compiling with your instructions, used "bash build-chocolate-doom -host=i686-pc-mingw32", and I still get an "install gcc" type error.

And you installed all the packages from the list?

Everything except subversion (installed git instead), but I don't see how that could cause my problems...

Tried the MinGW way but it didn't work out for me. Nonetheless big thanks for describing the process in detail.
I retried building choco via MSVC and voila - all the errors/nuisances of previous projects seem to have vanished.

Only 'deh_bexstr.c' has to be added to the /Doom project and it compiles!

Just for everyone who has reported OPL MIDI playback issues. I believe that with this latest change that I made last night, most MIDIs should now play back correctly! If you find some that still don't play properly please let me know.

After your commit, I checked if some MIDIs that I said were not working a while ago are now working. They still don't play like they should play in Vanilla Doom (tested on Linux).

Old bug report:
https://github.com/chocolate-doom/chocolate-doom/issues/174

It still have to check if this still occurs:
https://github.com/chocolate-doom/chocolate-doom/issues/334

Edit: I think your commit fixed a bug that sometimes caused Chocolate-Doom to crash when trying to play these files. Choco still doesn't behave like Vanilla when playing the two files in my old bug report. The remaining bug may be a MIDI to MUS conversion problem.