Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Porsche Monty

Problem building Chocolate Doom with cygwin on WinXP

Recommended Posts

I finally got cygwin to compile Chocolate Doom (latest svn) but somehow the binaries (or dll's?) ended up broken.

Besides the exe's and dll's being a lot larger than the official builds', chocolate-doom.exe crashes on startup with "Failed to initialize video: No available video device" while chocolate-setup.exe doesn't even seem to be running at all.

Here's a screenshot I took at the end of the building process:



I'd have posted the log file but I don't even know which one it is.

Any help would be greatly appreciated.

Regards.

Share this post


Link to post

Download the latest win32 release off the website, copy the SDL dlls into the src/ directory of your SVN checkout, it should then work.

Share this post


Link to post

Also, I imagine your EXEs and DLLs are a lot larger because they still have debugging information in them. You can use the strip command to make them smaller

Share this post


Link to post

@Frgglae: latest release of Chocolate Doom or some SDL package? also I have C:\cygwin\home\user\chocolate-doom with the "build", "install" and "packages" folders inside. Where exactly would they go?

For what it's worth, I'm using the unmodified "build-chocolate-doom" for this.

@chungy: I guess so, just didn't expect it to be on by default. I'll try that.

Thank you both for your help, I'm not anywhere near used to doing anything with cygwin at the moment.

Share this post


Link to post

Alright, just extracted the dlls' from chocolate-doom-1.6.0-win32.zip and placed them in a couple of src folders and that fixed it! however, the real reason I wanted to build CD myself is libsamplerate, which's being left out of the official builds for whatever reason.

Can you help me out with that?

Share this post


Link to post

Just wondering, what's the reason you're not using something like cmake? That one seems to be tremendously popular for quite some time now.

Share this post


Link to post
Porsche Monty said:

Alright, just extracted the dlls' from chocolate-doom-1.6.0-win32.zip and placed them in a couple of src folders and that fixed it! however, the real reason I wanted to build CD myself is libsamplerate, which's being left out of the official builds for whatever reason.

Can you help me out with that?


I can include libsamplerate in my svn builds. I put together a test build with it here: http://web.engr.oregonstate.edu/~delbelb/chocolate-doom-v2-win32-r2471.zip

Can you test it and let me know if it has what you need? If so, I'll update my scripts.

Share this post


Link to post

Please do if you can, that's exactly what I needed, thank you so much! the difference between "use_libsamplerate 0" and "use_libsamplerate 5" is night and day.

Share this post


Link to post
boris said:

Just wondering, what's the reason you're not using something like cmake? That one seems to be tremendously popular for quite some time now.

I've answered this several times before: I have no plans to switch to a different build system.

The problem in this thread actually had nothing to do with the build system: the problem was the SDL libraries. A different build system would not have made any difference.

There may be a problem with the build script that builds the SDL libraries and sets up a working development environment, as it is apparently not generating working SDL libraries on Windows. Again, though: the build system used to build Chocolate Doom itself (autotools) had nothing to do with this, and using cmake would not have made the slightest bit of difference.

Share this post


Link to post

autotools is still a major annoyance that may prevent many people from building Chocolate Doom.

Even if it works for you I consider it broken by default.

Share this post


Link to post

That's nice. When you take over maintaining Chocolate Doom from me, you're welcome to replace it with whatever build system you'd prefer.

Share this post


Link to post

Graf Zahl said:
autotools is still a major annoyance that may prevent many people from building Chocolate Doom.

Agreed. Typing "./configure" requires twice as many keystrokes as "cmake".

Share this post


Link to post

If you get it to work, that is...

And there lies the big problem. CMake works perfectly fine on Windows whereas autoconf requires you to jump through hoops to persuade it to do its job.

I have never even once managed to get an autoconf-based project to compile.

Share this post


Link to post

I've never managed to get a CMake-based project to compile either. Not that I've ever tried.

The funny thing is that autotools isn't actually the difficult part. The choice of build tool is actually pretty much irrelevant. The difficult part, as demonstrated by this thread, is getting a working build environment with the SDL libraries installed. That's why I've gone to the trouble of automating the process and documenting how to do it.

Share this post


Link to post

For code-illiterate people like myself, there's little practical difference if any difference at all. What actually matters for me is how well the process is explained.

I ran into a few problems and dilemmas that I had to resolve on my own while downloading and setting up the cygwin environment.

Firstable, there's 2 downloading options (bin and src) , some times newer, stable versions of what you're supposed to download (which makes you wonder if you should really stick to the exact version suggested in the guide or go for the updated one instead) and on the top of that, software like "python" has a thousand different files that carry the same name, thus I wasted quite some time choosing the correct "python" just to eventually realize I had to switch back to "category" and grab the whole package...and at this point I'm not even sure if that was necessary.

Next I had to figure out where to place the script, and when you see your freshly compiled exes bloated up to several times the size of the official binary distributions, you wonder what the hell went wrong, even if they run ok.

Also it doesn't help that most of the projects I've managed to compile in the past didn't apply any kind of optimizations, even the safest ones, so I get that feeling of "does the programmer give a damn?" and how much of the available resources are being wasted for nothing.

In other words, be as detailed as you can possibly be and never make any assumptions on the amount of knowledge people who don't work in the programming field actually posses, because it's normally none, and the learning curve for even the most basic stuff can be a overwhelming to some.

I know spoonfeeding trivial stuff like this gets irritating and frustrating, and for that I apologize, but trust me, it's even more irritating and frustrating to be on the other side ;)

Share this post


Link to post

What is THE way to build chocolate for windows?
I got the impression the visual way is somewhat of a bastard's son option.
I'm not really a coder so I chose the micro way... think I fetched 1.5 or 1.6 via svn and now I'm doing the most cruel things to those damn bytes.

Share this post


Link to post

To be honest when I compile chocolate-doom I just throw the whole thing into Codeblocks and hit "Build Workspace".

Share this post


Link to post

I believe the way the official packages are built, is via MinGW/MSYS. Though when I do builds personally, I cross-compile from Linux. There's a few different ways to do it, they should all be on the wiki.

Share this post


Link to post

I've updated the build script, so the problem reported in this thread should hopefully be fixed now.

Share this post


Link to post

Just completed a test compile on Win98 for DoomLegacy, and had similar compile problems.

Installation of MinGW (unlike Watcom that creates an IDE) does not make it very clear on where to put your source code and libraries like SDL. Thus they end up in various places depending upon user whim.

SDL-mixer is a totally separate download, and the whim of where to put it (within SDL directory, or outside) adds more complications.

Installed SDL run-time libraries into system32 directory too. I have no idea which copy is getting used at run-time or compile time. It seems to check on it at link-time.

SDLconfig does not work on Windows machines (I did not install MSYS), so had to extract that info from it by reading, and put similar lines directly into the Makefile.

DoomLegacy Makefile ended up with two extra optional lines that the user can modify to indicate the extra places where SDL libraries and include files could be hiding. But, I doubt that anyone who is not an experienced coder will ever find them. I did not install MSYS, it is not required for compiling.

If this had been a CMake configured compile, I suspect it would have still failed, and been much harder to fix.

Share this post


Link to post
chungy said:

I believe the way the official packages are built, is via MinGW/MSYS. Though when I do builds personally, I cross-compile from Linux. There's a few different ways to do it, they should all be on the wiki.

To clarify: the build instructions are on the website. The recommended way is to use Cygwin (not MSYS) - although the output of the build is a MingW executable (no dependency on cygwin1.dll).

When I first started the project I initially used MSYS to build Windows executables, but the problem with MSYS is that although it gives a Unix-like environment it's very limited and incomplete compared to Cygwin. Obviously I wanted MingW executables without a dependency on cygwin1.dll, but I didn't realise at the time that you can just use the MingW compilers within Cygwin to generate them. In fact, SDL's compile flags do this automatically.

Share this post


Link to post

Ah, thanks for clarifying. I don't think MSYS has been updated in years... it's a very old fork of a very old version of Cygwin, so it makes sense to just ignore it and use Cygwin proper.

Share this post


Link to post

I still shudder whenever I see a makefile distributed with any project. If you are lucky, it will be recently created and, supposedly, "having learned from the mistakes of the past" or at least the assumptions made will be documented somewhere (if there's a README or NOTES files).

If not, as is the case with even slightly older stuff, you'll get a "makefile" that only works on the developer's machine, with a particular flavor of make etc.

Trying to use makefiles that make assumptions of a particular OS and specific hardcoded paths is fun...NOT (with a Borat accent).

Share this post


Link to post
Porsche Monty said:

I also recall the Visual Studio installation being a lot heavier, complex and intruding than cygwin, which's beautifully self-contained.



By contrast VS is a fully features IDE, not some rudimentary collection of command line tools that try to make feel Unix users at home.

Try to give that to a regular Windows user and all you get is confusion.

At least when I get a VC++ project I know I can make it work quickly.

Share this post


Link to post

And that's what I heard from about every Windows programmer I worked with, however, for people like me, I think cygwin is a better option, provided most of the process is fully automated.

Share this post


Link to post

That's simply ample confirmation of what I've been saying all this time.: if Windows programmers find the "One True Unix Way" of doing things to be convoluted and arcane, imagine how plain users feels about doing much more mundane tasks like installing applications ;-)

Share this post


Link to post

Some (most?) Windows Programmers do not know how to change extension in files, because Windows blocks this feature by default. Also they do not know how create ".htaccess" file, because explorer does not allow it (they ask friend hackers for creating and mailing it, then they save it on flash drive for future use)

Share this post


Link to post
Guest
This topic is now closed to further replies.
×