I've been refering to the wiki on how to build dosbox but am having some trouble. I got mingw and msys and downloaded the latest source for dosbox as well as SDL. Now, according to the wiki http://www.dosbox.com/wiki/BuildingDOSBox, it says that you shouldn't have to compile the SDL and could just use one that is already built from a prebuilt version of dosbox. I tried that but I kept getting this error in Msys:
1checking for sdl-config... no 2checking for SDL - version >= 1.2.0... no 3*** The sdl-config script installed by SDL could not be found 4*** If SDL was installed in PREFIX, make sure PREFIX/bin is in 5*** your path, or set the SDL_CONFIG environment variable to the 6*** full path to sdl-config. 7configure: error: *** SDL version 1.2.0 not found!
As you can see, it appears to be looking for a sdl-config file which I could not find at all. In the wiki it says to adjust the path variable to where the SDL is installed which I tried to do in a variety of ways, but none were successful.
So I decided to just compile SDL and that gave me an sdl-config file in local/bin. When I went to compile again, the ./configure worked correctly (it detected the sdl-config) but during the make I got a whole bunch of errors related to SDL. Here is just a small part of what it said:
1' with no type 2/usr/local/include/SDL/SDL_video.h:401: error: ISO C++ forbids declaration of `h 3' with no type 4/usr/local/include/SDL/SDL_video.h:438: error: expected `,' or `...' before '*' 5token 6/usr/local/include/SDL/SDL_video.h:438: error: ISO C++ forbids declaration of `U 7int16' with no type 8/usr/local/include/SDL/SDL_video.h:449: warning: `SDL_GetGammaRamp' initialized 9and declared `extern' 10/usr/local/include/SDL/SDL_video.h:449: error: `Uint16' was not declared in this 11 scope 12/usr/local/include/SDL/SDL_video.h:449: error: `red' was not declared in this sc 13ope 14/usr/local/include/SDL/SDL_video.h:449: error: `Uint16' was not declared in this 15 scope 16/usr/local/include/SDL/SDL_video.h:449: error: `green' was not declared in this 17scope 18/usr/local/include/SDL/SDL_video.h:449: error: `Uint16' was not declared in this 19 scope 20/usr/local/include/SDL/SDL_video.h:449: error: `blue' was not declared in this s 21cope 22/usr/local/include/SDL/SDL_video.h:449: error: initializer expression list treat 23ed as compound expression 24/usr/local/include/SDL/SDL_video.h:492: error: `Uint32' does not name a type 25/usr/local/include/SDL/SDL_video.h:499: error: `Uint32' does not name a type 26/usr/local/include/SDL/SDL_video.h:506: warning: `SDL_GetRGB' initialized and de 27clared `extern' 28/usr/local/include/SDL/SDL_video.h:506: error: variable or field `SDL_GetRGB' de 29clared void 30/usr/local/include/SDL/SDL_video.h:506: error: `Uint32' was not declared in this 31 scope 32/usr/local/include/SDL/SDL_video.h:507: error: expected primary-expression befor 33e "const" 34/usr/local/include/SDL/SDL_video.h:508: error: `Uint8' was not declared in this 35scope 36/usr/local/include/SDL/SDL_video.h:508: error: `r' was not declared in this scop 37e 38/usr/local/include/SDL/SDL_video.h:508: error: `Uint8' was not declared in this 39scope 40/usr/local/include/SDL/SDL_video.h:508: error: `g' was not declared in this scop 41e 42/usr/local/include/SDL/SDL_video.h:508: error: `Uint8' was not declared in this 43scope 44/usr/local/include/SDL/SDL_video.h:508: error: `b' was not declared in this scop 45e 46/usr/local/include/SDL/SDL_video.h:508: error: initializer expression list treat 47ed as compound expression 48/usr/local/include/SDL/SDL_video.h:513: warning: `SDL_GetRGBA' initialized and d 49eclared `extern' 50/usr/local/include/SDL/SDL_video.h:513: error: variable or field `SDL_GetRGBA' d 51eclared void 52/usr/local/include/SDL/SDL_video.h:513: error: `Uint32' was not declared in this 53 scope 54/usr/local/include/SDL/SDL_video.h:514: error: expected primary-expression befor 55e "const"
I'm not sure if this is because something went wrong when I compiled SDL or what.
It seems like the easiest way to do this would be to use the already built SDL in dosbox, but as I said before it kept on looking for that sdl-config file instead. Is there a way to override this and have msys point to the .dll directly? Or is there something else I can try with the SDL I compiled on my own?
The wiki is wrong. You need at least the development libraries of SDL from http://www.libsdl.org/download-1.2.php (grab the ones for mingw) or you need to compile SDL yourself. I don't know who wrote this in such a way, since you *need* SDL headers and libs present in your mingw/msys to compile Dosbox.
I hope it will work with the development libraries for you, though I suspect there is something else wrong with your mingw/msys stuff, since you should be able to build SDL on your own with that.
Well I tried again with no success. As far as I can tell, SDL compiles correctly, creating a file called "local" in the msys directory with the sub-directories bin, include, lib, and share; in bin is SDL.dll and sdl-config. I have done all the default install options for MinGW and the included Msys; msys is located here C:\MinGW\msys\1.0.
Looking at this http://www.libsdl.org/extras/win32/mingw32/README.txt it says to copy SDL.dll from local/lib to the src directory when compiling. Although my SDL.dll is located in local/bin (I only have libSDL in /lib), I copied it to the dosbox src directory and still got the same errors.
I'm not sure what could be wrong as it seems pretty straight forward. I have the SDL and dosbox sources located in C:\MinGW\msys\1.0.
I tried the development libraries but got similar errors as well. It runs the configure okay but fails during the make.
Can you post the FIRST error in the "whole bunch of errors related to SDL"? Because that's usually the real culprit, the rest is just follow-up errors caused by the parser getting out of sync with the code by the first error.
1$ make 2make all-recursive 3make[1]: Entering directory `/dosbox-0.74' 4Making all in src 5make[2]: Entering directory `/dosbox-0.74/src' 6Making all in cpu 7make[3]: Entering directory `/dosbox-0.74/src/cpu' 8Making all in core_full 9make[4]: Entering directory `/dosbox-0.74/src/cpu/core_full' 10make[4]: Nothing to be done for `all'. 11make[4]: Leaving directory `/dosbox-0.74/src/cpu/core_full' 12Making all in core_normal 13make[4]: Entering directory `/dosbox-0.74/src/cpu/core_normal' 14make[4]: Nothing to be done for `all'. 15make[4]: Leaving directory `/dosbox-0.74/src/cpu/core_normal' 16Making all in core_dyn_x86 17make[4]: Entering directory `/dosbox-0.74/src/cpu/core_dyn_x86' 18make[4]: Nothing to be done for `all'. 19make[4]: Leaving directory `/dosbox-0.74/src/cpu/core_dyn_x86' 20Making all in core_dynrec 21make[4]: Entering directory `/dosbox-0.74/src/cpu/core_dynrec' 22make[4]: Nothing to be done for `all'. 23make[4]: Leaving directory `/dosbox-0.74/src/cpu/core_dynrec' 24make[4]: Entering directory `/dosbox-0.74/src/cpu' 25make[4]: Nothing to be done for `all-am'. 26make[4]: Leaving directory `/dosbox-0.74/src/cpu' 27make[3]: Leaving directory `/dosbox-0.74/src/cpu' 28Making all in debug 29make[3]: Entering directory `/dosbox-0.74/src/debug' 30make[3]: Nothing to be done for `all'. 31make[3]: Leaving directory `/dosbox-0.74/src/debug' 32Making all in dos 33make[3]: Entering directory `/dosbox-0.74/src/dos' 34g++ -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/usr/local/include/SDL -D_GNU 35_SOURCE=1 -Dmain=SDL_main -g -O2 -MT dos.o -MD -MP -MF .deps/dos.Tpo -c -o dos 36.o dos.cpp 37In file included from /usr/local/include/SDL/SDL_main.h:26, 38 from /usr/local/include/SDL/SDL.h:30, 39 from ../../include/timer.h:23, 40 from ../../include/serialport.h:31, 41 from dos.cpp:33: 42/usr/local/include/SDL/SDL_stdinc.h:66:23: inttypes.h: No such file or directory 43 44In file included from /usr/local/include/SDL/SDL_main.h:26, 45 from /usr/local/include/SDL/SDL.h:30, 46 from ../../include/timer.h:23, 47 from ../../include/serialport.h:31, 48 from dos.cpp:33: 49/usr/local/include/SDL/SDL_stdinc.h:99: error: `uint8_t' does not name a type 50/usr/local/include/SDL/SDL_stdinc.h:101: error: `uint16_t' does not name a type 51/usr/local/include/SDL/SDL_stdinc.h:103: error: `uint32_t' does not name a type 52/usr/local/include/SDL/SDL_stdinc.h:108: error: `uint64_t' does not name a type 53/usr/local/include/SDL/SDL_stdinc.h:125: error: `Uint8' was not declared in this 54 scope 55/usr/local/include/SDL/SDL_stdinc.h:127: error: `Uint16' was not declared in thi 56s scope 57/usr/local/include/SDL/SDL_stdinc.h:129: error: `Uint32' was not declared in thi 58s scope 59/usr/local/include/SDL/SDL_stdinc.h:131: error: `Uint64' was not declared in thi 60s scope
Another disconcerting thing is that during the configure it says this:
1checking SDL_sound.h usability... no 2checking SDL_sound.h presence... no 3checking for SDL_sound.h... no 4checking for Sound_Init in -lSDL_sound... no 5checking for Sound_Seek in -lSDL_sound... no 6configure: WARNING: Can't find libSDL_sound, libSDL_sound support disabled
Does this mean I will not have sound enabled? If so, then how do I get or compile this other sdl library?
OK, "inttypes.h" is a standard ANSI C header file since C99. If that cannot be found, your whole compiler environment is either quite old or seriously screwed. Can you successfully compile and run other things, such as a simple Hello World program? If so, I'd say
1.) Search your hard disk for the inttypes.h file. If it's found, make sure it's in a directory that belongs to your compiler and see to it that it can be found there. you can add CFLAGS="-Ipathname" (where pathname is the directory in which inttypes.h lives) to your configure run if you find no better way of doing this. just say
1CFLAGS="-Iwhatever" ./configure
all in one line. At least that's the way you do it on real Unix-like systems with a Bourne type shell, I'm not sure about MinGW. Maybe you'll have to say
1SET CFLAGS=-Iwhatever 2./configure
on two lines if MinGW uses normal Windows CMD.EXE as opposed to a Unix Bourne type shell.
2.) If inttypes.h is not found, set up your compiler again. Make sure you get a recent version of all components.
You can worry about SDL_sound later I think. Once the DOSBox compilation works, the same setup should work for compiling SDL_sound from source as well.
don't worry about sdl_sound. it used for the audio tracks in cue/bin cdrom images.
"normal" sound will work if you can compile dosbox as dosbox depends on it.
I'm not sure your setup is sound. Make sure you are using the latest combo of msys and mingw. with the latest one you can safely use the same folder (C:\mingw) for both. (and make sure you run this all in msys NOT the windows command line 😀)
There must be a simple how to somewhere for this 😀
Well I found inttypes.h in C:\MinGW\include. I tried adding this with CFLAGS="-I/c/MinGW/include" ./configure which seemed to work because it did not give me any errors like SET CFLAGS did. Unfortunately, it still did not detect inttypes.h. I also tried CFLAGS="-I/MinGW/include".
The Msys.bat which I'm using to compile is located in C:\MinGW\msys\1.0 and the dosbox source is in C:\MinGW\msys\1.0\dosbox-0.74. Everything is pretty much in one directory, C:\MinGW.
I'm not sure how I could have set up the compiling environment incorrectly because it basically did everything for me. I downloaded MinGW form here http://sourceforge.net/projects/mingw. When I installed it, it gave me the option to update everything and also install Msys, which it did automatically. I chose all default options; I didn't really have any chance to screw anything up.
edit: I forgot to mention that during the ./configure I noticed it said this:
checking for inttypes.h... yes
I'm not sure if that means anything but I found it interesting.
This is looking increasingly strange. SDL_stdinc.h includes all kinds of stuff before inttypes.h, such as stdlib.h, stddef,h, stdarg.h, stdio.h, string.h so it seems to be finding those all right. Can you find out if those are in the same place as your inttypes.h?
Of course if the compiler totally refuses to cooperate, a last-ditch measure would be cutting and pasting the contents of inttypes.h into SDL_stdinc.h in place of the #include, but I really think there must be some better solution.
As for your -I flags you have to make sure that you use the path as MinGW itself uses it. try cd'ing by hand into the directory where GCC fails, then entering exactly the failing command there by hand. Just add a -v parameter at the beginning. This should make GCC report the include path it uses. Then post the results here.
You might also try using an -E parameter to GCC (leave everything else the same just change the -o parameter to something like <filename>.preprocessed or so) to get it to output the preprocessed C code, as far as it gets. That should tell you which includes are actually found, and where.
edit: I'm not certain if -E will output partial results on error. And I can't check this from here. So you'll just have to hope it does....
Now I didn't quite follow what you said after that but here's what I tried:
1$ gcc -v /usr/local/include/SDL/SDL_stdinc.h 2Reading specs from /bin/../lib/gcc/i686-pc-msys/3.4.4/specs 3Configured with: /home/cstrauss/build/gcc3/gcc-3.4.4/configure --prefix=/usr --s 4ysconfdir=/etc --localstatedir=/var --infodir=/share/info --mandir=/share/man -- 5libexecdir=/lib --enable-languages=c,c++ --disable-nls --enable-threads=posix -- 6enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug -- 7with-newlib 8Thread model: posix 9gcc version 3.4.4 (msys special) 10 /bin/../lib/gcc/i686-pc-msys/3.4.4/cc1.exe -quiet -v -iprefix /bin/../lib/gcc/i 11686-pc-msys/3.4.4/ -D__CYGWIN__ -D__CYGWIN32__ -D__MSYS__ -Dunix -D__unix__ -D__ 12unix -idirafter /bin/../lib/gcc/i686-pc-msys/3.4.4/../../../../include/w32api -i 13dirafter /bin/../lib/gcc/../../include/w32api /usr/local/include/SDL/SDL_stdinc. 14h -quiet -dumpbase SDL_stdinc.h -mtune=pentiumpro -auxbase SDL_stdinc -version - 15o /tmp/ccFBcB4f.s --output-pch=/usr/local/include/SDL/SDL_stdinc.h.gch 16ignoring nonexistent directory "/bin/../lib/gcc/i686-pc-msys/3.4.4/../../../../i 17686-pc-msys/include" 18ignoring duplicate directory "/usr/lib/gcc/i686-pc-msys/3.4.4/include" 19ignoring nonexistent directory "/usr/lib/gcc/i686-pc-msys/3.4.4/../../../../i686 20-pc-msys/include" 21ignoring duplicate directory "/bin/../lib/gcc/../../include/w32api" 22#include "..." search starts here: 23#include <...> search starts here: 24 /bin/../lib/gcc/i686-pc-msys/3.4.4/include 25 /usr/local/include 26 /usr/include 27 /bin/../lib/gcc/i686-pc-msys/3.4.4/../../../../include/w32api 28End of search list. 29GNU C version 3.4.4 (msys special) (i686-pc-msys) 30 compiled by GNU C version 3.4.4 (msys special). 31GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129973 32/usr/local/include/SDL/SDL_stdinc.h:66:23: inttypes.h: No such file or directory 33 34/usr/local/include/SDL/SDL_stdinc.h:99: error: parse error before "Uint8" 35/usr/local/include/SDL/SDL_stdinc.h:99: warning: data definition has no type or 36storage class 37/usr/local/include/SDL/SDL_stdinc.h:101: error: parse error before "Uint16" 38/usr/local/include/SDL/SDL_stdinc.h:101: warning: data definition has no type or 39 storage class 40/usr/local/include/SDL/SDL_stdinc.h:103: error: parse error before "Uint32" 41/usr/local/include/SDL/SDL_stdinc.h:103: warning: data definition has no type or 42 storage class 43/usr/local/include/SDL/SDL_stdinc.h:108: error: parse error before "Uint64" 44/usr/local/include/SDL/SDL_stdinc.h:108: warning: data definition has no type or 45 storage class 46/usr/local/include/SDL/SDL_stdinc.h:125: error: size of array `SDL_dummy_uint8' 47is negative 48/usr/local/include/SDL/SDL_stdinc.h:127: error: size of array `SDL_dummy_uint16' 49 is negative 50/usr/local/include/SDL/SDL_stdinc.h:131: error: size of array `SDL_dummy_uint64' 51 is negative
I also tried gcc -E /usr/local/include/SDL/SDL_stdinc.h (I didn't know what you meant by -o parameter or that .preprocessed thing) and I got a bunch of weird stuff so I don't know if I did it right or not.
Well that's something. It looks like you you have two different MinGW releases on your system that got mixed up with each other? One with GCC 3.4.4 and one with GCC 4.5.0? Is it possible that you had a newer one installed at some earlier time and now installed an old one over the other? Or (slightly less likely I think, from your output) vice versa?
I'd say kill your whole MinGW installation: Uninstall from Windows, then delete the whole directory C:\MinGW from Windows if it still exists, then reinstall. The newer GCC version seems preferable, so if you know which download package corresponds to which GCC, I'd say go with the newer version. Though the x.y.0 versions of GCC, such as 4.5.0, are known as relatively buggy... so if you can install a MinGW that contains GCC 4.5.1 or GCC 4.4.x with x=3 or 4 that would be the best. If such a thing exists, as non-user of MinGW I unfortunately don't know.
If this doesn't work or if the problem persists, I'll have to think of something new... e.g. you could copy the inttypes.h that you found to a couple of the other locations where you found headers (i.e. files with .h at the end of the name; as listed at the beginning of your last post). That should allow the #include to succeed in any case, but it's an evil hack. I'm not sure whether the content of inttypes.h itself depends on the compiler version. The #include might succeed and the compilation still fail.
edit: By the way the -E gives you the preprocessed code, i.e. after the compiler has processed all the lines that start with # (such as #include, #ifdef...#endif) and after doing macro expansion, but before compilation proper. It's interesting in this case because it shows where each #include file was found.
I actually have tried deleting and reinstalling to no effect. As I said, it pretty much does everything automatically and I don't really know of any other way to get msys installed along with mingw except through that file at sourceforge. What seems to be happening is that MinGW and Msys have their own separate gcc versions. In C:\MinGW\msys\1.0\bin resides a gcc.exe that is:
As far as I have read on the web, this is how msys and mingw are supposed to operate, with msys being in a subfolder of mingw. There's no options during installation to change the directory or options of msys, only a check box to install it along with mingw.
As far as I have read on the web, this is how msys and mingw are supposed to operate, with msys being in a subfolder of mingw.
This is how it used to be, though in later years it was possible to use both in the same folder, which is what I did and had working until last year when I switched to Mac.
There's no options during installation to change the directory or options of msys, only a check box to install it along with mingw.
I'm really not sure whether this is working right, it seems like it doesn't do things correctly. I'd try to find some other guide which tells you which packages to use and install.
And now for something completely different... how about using Evil(TM) Visual C++ 2010 Express for compiling? It'll produce a faster executable anyway.
