VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 1280 of 1295, by mr.cat

User metadata
Rank Member
Rank
Member

OK, thanks. So it's 1.2.x that is used.
But it seems I stated this question too vaguely. What I meant is that it would be interesting to know what backends your libSDL has support for.
I don't even know what backends are possible on Mac, but the error message looks like it could be caused by missing support for X11.
Since libSDL was installed via homebrew, there is no config.log to examine. Maybe the backends can be determined by looking directly at the library files (on Linux, ldd can be used on .so files to see any dependancies - but I don't know what the Mac equivalent is)

Reply 1281 of 1295, by almeath

User metadata
Rank Member
Rank
Member
mr.cat wrote on 2021-01-31, 17:52:
OK, thanks. So it's 1.2.x that is used. But it seems I stated this question too vaguely. What I meant is that it would be intere […]
Show full quote

OK, thanks. So it's 1.2.x that is used.
But it seems I stated this question too vaguely. What I meant is that it would be interesting to know what backends your libSDL has support for.
I don't even know what backends are possible on Mac, but the error message looks like it could be caused by missing support for X11.
Since libSDL was installed via homebrew, there is no config.log to examine. Maybe the backends can be determined by looking directly at the library files (on Linux, ldd can be used on .so files to see any dependancies - but I don't know what the Mac equivalent is)

On the Mac it is the command otool -L.

If I run that on libSDL.a, I see this:

Archive : /usr/local/lib/libSDL.a
/usr/local/lib/libSDL.a(SDL.o):
/usr/local/lib/libSDL.a(SDL_error.o):
/usr/local/lib/libSDL.a(SDL_fatal.o):
/usr/local/lib/libSDL.a(SDL_audio.o):
/usr/local/lib/libSDL.a(SDL_audiocvt.o):
/usr/local/lib/libSDL.a(SDL_audiodev.o):
/usr/local/lib/libSDL.a(SDL_mixer.o):
/usr/local/lib/libSDL.a(SDL_mixer_MMX.o):
/usr/local/lib/libSDL.a(SDL_mixer_MMX_VC.o):
/usr/local/lib/libSDL.a(SDL_mixer_m68k.o):
/usr/local/lib/libSDL.a(SDL_wave.o):
/usr/local/lib/libSDL.a(SDL_cdrom.o):
/usr/local/lib/libSDL.a(SDL_cpuinfo.o):
/usr/local/lib/libSDL.a(SDL_active.o):
/usr/local/lib/libSDL.a(SDL_events.o):
/usr/local/lib/libSDL.a(SDL_expose.o):
/usr/local/lib/libSDL.a(SDL_keyboard.o):
/usr/local/lib/libSDL.a(SDL_mouse.o):
/usr/local/lib/libSDL.a(SDL_quit.o):
/usr/local/lib/libSDL.a(SDL_resize.o):
/usr/local/lib/libSDL.a(SDL_rwops.o):
/usr/local/lib/libSDL.a(SDL_getenv.o):
/usr/local/lib/libSDL.a(SDL_iconv.o):
/usr/local/lib/libSDL.a(SDL_malloc.o):
/usr/local/lib/libSDL.a(SDL_qsort.o):
/usr/local/lib/libSDL.a(SDL_stdlib.o):
/usr/local/lib/libSDL.a(SDL_string.o):
/usr/local/lib/libSDL.a(SDL_thread.o):
/usr/local/lib/libSDL.a(SDL_timer.o):
/usr/local/lib/libSDL.a(SDL_RLEaccel.o):
/usr/local/lib/libSDL.a(SDL_blit.o):
/usr/local/lib/libSDL.a(SDL_blit_0.o):
/usr/local/lib/libSDL.a(SDL_blit_1.o):
/usr/local/lib/libSDL.a(SDL_blit_A.o):
/usr/local/lib/libSDL.a(SDL_blit_N.o):
/usr/local/lib/libSDL.a(SDL_bmp.o):
/usr/local/lib/libSDL.a(SDL_cursor.o):
/usr/local/lib/libSDL.a(SDL_gamma.o):
/usr/local/lib/libSDL.a(SDL_pixels.o):
/usr/local/lib/libSDL.a(SDL_stretch.o):
/usr/local/lib/libSDL.a(SDL_surface.o):
/usr/local/lib/libSDL.a(SDL_video.o):
/usr/local/lib/libSDL.a(SDL_yuv.o):
/usr/local/lib/libSDL.a(SDL_yuv_mmx.o):
/usr/local/lib/libSDL.a(SDL_yuv_sw.o):
/usr/local/lib/libSDL.a(SDL_joystick.o):
/usr/local/lib/libSDL.a(SDL_nullevents.o):
/usr/local/lib/libSDL.a(SDL_nullmouse.o):
/usr/local/lib/libSDL.a(SDL_nullvideo.o):
/usr/local/lib/libSDL.a(SDL_diskaudio.o):
/usr/local/lib/libSDL.a(SDL_dummyaudio.o):
/usr/local/lib/libSDL.a(SDL_sysloadso.o):
/usr/local/lib/libSDL.a(SDL_QuartzEvents.o):
/usr/local/lib/libSDL.a(SDL_QuartzGL.o):
/usr/local/lib/libSDL.a(SDL_QuartzVideo.o):
/usr/local/lib/libSDL.a(SDL_QuartzWM.o):
/usr/local/lib/libSDL.a(SDL_QuartzWindow.o):
/usr/local/lib/libSDL.a(SDL_systhread.o):
/usr/local/lib/libSDL.a(SDL_syssem.o):
Show last 10 lines
/usr/local/lib/libSDL.a(SDL_sysmutex.o):
/usr/local/lib/libSDL.a(SDL_syscond.o):
/usr/local/lib/libSDL.a(SDL_coreaudio.o):
/usr/local/lib/libSDL.a(SDL_sysjoystick.o):
/usr/local/lib/libSDL.a(AudioFilePlayer.o):
/usr/local/lib/libSDL.a(AudioFileReaderThread.o):
/usr/local/lib/libSDL.a(CDPlayer.o):
/usr/local/lib/libSDL.a(SDLOSXCAGuard.o):
/usr/local/lib/libSDL.a(SDL_syscdrom.o):
/usr/local/lib/libSDL.a(SDL_systimer.o):

And if I run it on libSDL.dylib, I get this:

/usr/local/lib/libSDL.dylib:
/usr/local/opt/sdl/lib/libSDL-1.2.0.dylib (compatibility version 12.0.0, current version 12.4.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 52.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 162.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1000.0.0)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1894.10.126)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1673.126.0)
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1348.12.4)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1069.11.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1673.126.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

Reply 1282 of 1295, by mr.cat

User metadata
Rank Member
Rank
Member

OK, yeah to me that looks like there's no X-anything in there. Instead, you have OpenGL (QuartzGL?).
However I can't advise on what the correct action would be. I guess the options are to compile libSDL with X support, or use OpenGL somehow.

Reply 1283 of 1295, by almeath

User metadata
Rank Member
Rank
Member
mr.cat wrote on 2021-01-31, 19:25:

OK, yeah to me that looks like there's no X-anything in there. Instead, you have OpenGL (QuartzGL?).
However I can't advise on what the correct action would be. I guess the options are to compile libSDL with X support, or use OpenGL somehow.

Yeah, everything I read online says that you do not need to specify X11 support when compiling SDL1/2 because macOS is supposed to handle all the translations to OpenGL automatically.

For the record, when I build SVN using an SDL 1.2.x (Mercurial) static library, and adding the latest 3dfx/Glide patch (download/file.php?id=83117) I actually get the same error as with ECE, being:

glide.cpp:165:21: error: no member named 'info' in 'SDL_SysWMinfo'
hwnd = (HostPt)wmi.info.x11.window;

Also, when I compile the SDL static build, I use parameters that seemingly disable X11 and patch the XQuartz code. If I do not run these commands, the build fails. These commands only work on Mercurial SDL 1.2.x and not on any other build up to and including 1.2.15.

$ ./configure --prefix=$HOME/Desktop/staticbuild --enable-static --disable-shared --disable-video-x11
$ perl -p -i -e "/CGDirectPaletteRef palette;/d" ./src/video/quartz/SDL_QuartzVideo.h

So, this problem is not specific to the ECE build and seems common to any build using 3dfx/Glide patches on macOS.

I think I have hit a bit of a brick wall at the moment, but will consider it further. Whatever I am doing wrong, they solved it in DOSBox-X. When I used the auto-build script for Mac (either SDL1 or SDL2) I end up with a build that supports 3dfx software emulation. I have not had a chance to test the glide functionality yet, as I only managed to build the libraries and dylibs a few days ago.

If I have any breakthroughs I will report back.

Reply 1286 of 1295, by almeath

User metadata
Rank Member
Rank
Member
mr.cat wrote on 2021-02-01, 08:01:

OK, thank you both for the clarification. I simply wasn't sure how this is supposed to work on macOS.

It is not clear if it supposed to / able to work with macOS, at least with standard builds. I have no idea how the DOSBox-X team worked it out, but my focus is to see if it is possible for regular DOSBox or builds that have not been so extensively modified from the main code base.

All I have to go on at the moment is 12 year old threads where Dominus was able to patch something together on very old versions of macOS and DOSBox. I will keep researching, but it may well be impossible without some code rewrites within the patches themselves. OpenGlide does at least install for me, and produces all of the correct libraries on my system, and if it works on Mojave it is likely to continue in Catalina .. not sure about Big Sur, but I have no intention of going there for a long time.

Reply 1287 of 1295, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
glide.cpp:165:21: error: no member named 'info' in 'SDL_SysWMinfo'
hwnd = (HostPt)wmi.info.x11.window;

If this was the problem, then perhaps you could simply remove the line or assign 'NULL' to the 'hwnd' native handle. Make sure that you also compiled a version of OpenGlide with '--enable-sdl'. IIRC OpenGlide SDL1.2 does not require native window handle. SDL1.2 seems to know how to retrieve and reuse an existing SDL window (which is DOSBox). DOSBox SVN is SDL1.2 only, I don't know if DOSBox ECE had adapted the SDL2 patch for DOSBox. If it did, then OpenGlide SDL1.2 will not work if DOSBox uses SDL2 for its window decoration.

Reply 1288 of 1295, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
kjliew wrote on 2021-02-02, 06:32:

DOSBox SVN is SDL1.2 only, I don't know if DOSBox ECE had adapted the SDL2 patch for DOSBox.

It hasn't, it uses 1.2 like SVN still does.

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 1289 of 1295, by almeath

User metadata
Rank Member
Rank
Member
kjliew wrote on 2021-02-02, 06:32:

If this was the problem, then perhaps you could simply remove the line or assign 'NULL' to the 'hwnd' native handle. Make sure that you also compiled a version of OpenGlide with '--enable-sdl'. IIRC OpenGlide SDL1.2 does not require native window handle. SDL1.2 seems to know how to retrieve and reuse an existing SDL window (which is DOSBox). DOSBox SVN is SDL1.2 only, I don't know if DOSBox ECE had adapted the SDL2 patch for DOSBox. If it did, then OpenGlide SDL1.2 will not work if DOSBox uses SDL2 for its window decoration.

Thanks, the suggestion to assign NULL to 'hwind' avoids the error.

Running the make command again, resulted in an error about missing 'gl.h' and 'glext.h' files.

I located these in the OpenGL frameworks folder in my library/frameworks folder, but using these spat out way too many errors of all kinds (30+).

I then ran a search on my entire system, and found that I had a "GL" folder under "opt/X11/include/GL".

I copied these files into "usr/local/include/GL", and ran make again. This time there were 10 errors, as below.

2 warnings generated.
mv -f .deps/voodoo_emu.Tpo .deps/voodoo_emu.Po
g++ -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/usr/local/include/SDL -D_GNU_SOURCE=1 -D_THREAD_SAFE -std=c++11 -O3 -mno-ms-bitfields -MT voodoo_opengl.o -MD -MP -MF .deps/voodoo_opengl.Tpo -c -o voodoo_opengl.o voodoo_opengl.cpp
In file included from voodoo_opengl.cpp:28:
In file included from ./voodoo_opengl.h:33:
In file included from ./voodoo_vogl.h:31:
/usr/local/include/SDL/SDL_opengl.h:37:9: warning: '__glext_h_' macro redefined [-Wmacro-redefined]
#define __glext_h_ /* Don't let gl.h include glext.h */
^
/usr/local/include/GL/glext.h:2:9: note: previous definition is here
#define __glext_h_ 1
^
In file included from voodoo_opengl.cpp:28:
In file included from ./voodoo_opengl.h:33:
In file included from ./voodoo_vogl.h:31:
/usr/local/include/SDL/SDL_opengl.h:116:9: warning: 'GL_GLEXT_VERSION' macro redefined [-Wmacro-redefined]
#define GL_GLEXT_VERSION 29
^
/usr/local/include/GL/glext.h:56:9: note: previous definition is here
#define GL_GLEXT_VERSION 20160609
^
voodoo_opengl.cpp:1054:34: error: assigning to 'UINT32' (aka 'unsigned int') from incompatible type 'GLhandleARB' (aka 'void *')
extra->info->so_shader_program=m_hProgramObject;
^~~~~~~~~~~~~~~~
voodoo_opengl.cpp:1055:33: error: assigning to 'UINT32' (aka 'unsigned int') from incompatible type 'GLhandleARB' (aka 'void *')
extra->info->so_vertex_shader=m_hVertexShader;
^~~~~~~~~~~~~~~
voodoo_opengl.cpp:1056:35: error: assigning to 'UINT32' (aka 'unsigned int') from incompatible type 'GLhandleARB' (aka 'void *')
extra->info->so_fragment_shader=m_hFragmentShader;
^~~~~~~~~~~~~~~~~
voodoo_opengl.cpp:1082:24: error: comparison between pointer and integer ('GLhandleARB' (aka 'void *') and 'UINT32' (aka 'unsigned int'))
if (m_hProgramObject != extra->info->so_shader_program) {
~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
voodoo_opengl.cpp:1083:26: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
(aka 'unsigned int')
glUseProgramObjectARB(extra->info->so_shader_program);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
voodoo_opengl.cpp:1084:36: error: assigning to 'GLhandleARB' (aka 'void *') from incompatible type 'UINT32' (aka 'unsigned int')
m_hProgramObject = extra->info->so_shader_program;
~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
voodoo_opengl.cpp:1801:57: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
(aka 'unsigned int')
if (info->so_vertex_shader >= 0) glDetachObjectARB(info->so_shader_program, info->so_vertex_shader);
^~~~~~~~~~~~~~~~~~~~~~~
voodoo_opengl.cpp:1802:59: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
(aka 'unsigned int')
if (info->so_fragment_shader >= 0) glDetachObjectARB(info->so_shader_program, info->so_fragment_shader);
^~~~~~~~~~~~~~~~~~~~~~~
voodoo_opengl.cpp:1803:57: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
(aka 'unsigned int')
if (info->so_vertex_shader >= 0) glDeleteObjectARB(info->so_vertex_shader);
^~~~~~~~~~~~~~~~~~~~~~
voodoo_opengl.cpp:1804:59: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
(aka 'unsigned int')
if (info->so_fragment_shader >= 0) glDeleteObjectARB(info->so_fragment_shader);
^~~~~~~~~~~~~~~~~~~~~~~~
2 warnings and 10 errors generated.

If the mods want this discussion shifted elsewhere, I am fine with that. I guess it is relevant to any Mac user wanting to successfully compile ECE, which is still my primary goal.

Reply 1290 of 1295, by Chuck

User metadata
Rank Newbie
Rank
Newbie

(Applying MMX patch to DosBox ECE) thanks to suggestions here i've got the .exe compiled (running 2 times make command, the last without -lssp flag, i don't know if this can be considered normal), but MMX doesn't work, i've tried to write cputype=pentium_mmx_slow and pentium_mmx into .conf file without success, as the status window writes is not a valid argument, core=normal does nothing too, at this point i really don't know where to start troubleshooting, maybe isn't compiled correctly.

Reply 1291 of 1295, by mr.cat

User metadata
Rank Member
Rank
Member
Chuck wrote on 2021-02-02, 15:26:

(Applying MMX patch to DosBox ECE) thanks to suggestions here i've got the .exe compiled (running 2 times make command, the last without -lssp flag, i don't know if this can be considered normal), but MMX doesn't work, i've tried to write cputype=pentium_mmx_slow and pentium_mmx into .conf file without success, as the status window writes is not a valid argument, core=normal does nothing too, at this point i really don't know where to start troubleshooting, maybe isn't compiled correctly.

Yeah that "double make" doesn't sound right. Did you use -lssp for libopus only, or is it required for the whole thing?
Could you try with a cputype such as "pentium_slow" that should definitely work? Just to make sure the .conf file isn't corrupted somehow (I'm thinking something like extraneous or missing characters).
You can also check the files dosbox.cpp and cpu/cpu.cpp to ensure that you in fact have the pentium_mmx stuff in there.

Reply 1292 of 1295, by Chuck

User metadata
Rank Newbie
Rank
Newbie
mr.cat wrote on 2021-02-02, 16:41:
Yeah that "double make" doesn't sound right. Did you use -lssp for libopus only, or is it required for the whole thing? Could yo […]
Show full quote
Chuck wrote on 2021-02-02, 15:26:

(Applying MMX patch to DosBox ECE) thanks to suggestions here i've got the .exe compiled (running 2 times make command, the last without -lssp flag, i don't know if this can be considered normal), but MMX doesn't work, i've tried to write cputype=pentium_mmx_slow and pentium_mmx into .conf file without success, as the status window writes is not a valid argument, core=normal does nothing too, at this point i really don't know where to start troubleshooting, maybe isn't compiled correctly.

Yeah that "double make" doesn't sound right. Did you use -lssp for libopus only, or is it required for the whole thing?
Could you try with a cputype such as "pentium_slow" that should definitely work? Just to make sure the .conf file isn't corrupted somehow (I'm thinking something like extraneous or missing characters).
You can also check the files dosbox.cpp and cpu/cpu.cpp to ensure that you in fact have the pentium_mmx stuff in there.

patch -p1 < mmx_20200624.diff
./autogen.sh -lssp
./configure LIBS="-Wl,--as-needed -lssp"
make LIBS="-Wl,--as-needed -lssp"
make

these are the commands that successfully created DosBox.exe. The other cpu configurations works, only the MMX one won't. The file cpu.cpp got entries about: if C_MMX - CPU_ARCHTYPE_PMMXSLOW etc. and dosbox.cpp writes:

	const char* cputype_values[] = { "auto", "386", "386_slow", "486_slow", "pentium_slow", 
#if C_MMX
"pentium_mmx_slow",
#endif
"386_prefetch", 0};

Reply 1293 of 1295, by mr.cat

User metadata
Rank Member
Rank
Member
Chuck wrote on 2021-02-03, 10:31:
these are the commands that successfully created DosBox.exe. The other cpu configurations works, only the MMX one won't. The fil […]
Show full quote
mr.cat wrote on 2021-02-02, 16:41:
Yeah that "double make" doesn't sound right. Did you use -lssp for libopus only, or is it required for the whole thing? Could yo […]
Show full quote
Chuck wrote on 2021-02-02, 15:26:

(Applying MMX patch to DosBox ECE) thanks to suggestions here i've got the .exe compiled (running 2 times make command, the last without -lssp flag, i don't know if this can be considered normal), but MMX doesn't work, i've tried to write cputype=pentium_mmx_slow and pentium_mmx into .conf file without success, as the status window writes is not a valid argument, core=normal does nothing too, at this point i really don't know where to start troubleshooting, maybe isn't compiled correctly.

Yeah that "double make" doesn't sound right. Did you use -lssp for libopus only, or is it required for the whole thing?
Could you try with a cputype such as "pentium_slow" that should definitely work? Just to make sure the .conf file isn't corrupted somehow (I'm thinking something like extraneous or missing characters).
You can also check the files dosbox.cpp and cpu/cpu.cpp to ensure that you in fact have the pentium_mmx stuff in there.

patch -p1 < mmx_20200624.diff
./autogen.sh -lssp
./configure LIBS="-Wl,--as-needed -lssp"
make LIBS="-Wl,--as-needed -lssp"
make

these are the commands that successfully created DosBox.exe. The other cpu configurations works, only the MMX one won't. The file cpu.cpp got entries about: if C_MMX - CPU_ARCHTYPE_PMMXSLOW etc. and dosbox.cpp writes:

	const char* cputype_values[] = { "auto", "386", "386_slow", "486_slow", "pentium_slow", 
#if C_MMX
"pentium_mmx_slow",
#endif
"386_prefetch", 0};

Thanks. I tried this on Linux and this bug is present there too:

"pentium_mmx_slow" is not a valid value for variable: cputype.

Looks like that C_MMX isn't getting set for some reason. You can force it by adding defines, for me the command line I used was:
CPPFLAGS="-I/usr/local/include/openglide/ -DC_FPU=1 -DC_MMX=1" ./configure

That will introduce a new set of errors (undefined references) though...
The Makefile in src/cpu directory needs some patching, as it is missing mmx. Once that is added, the compilation goes through.
The easiest way to do it is to just add mmx.cpp in src/cpu/Makefile.am, and re-run autogen.sh before compilation.

Reply 1294 of 1295, by Chuck

User metadata
Rank Newbie
Rank
Newbie

Finally got working DosBox ECE with MMX patch. However i ran the make command 3 times now because of the errors that stops compiler. I do like this: copied sdk2_* files from openglide source code to include folder, then i edit src\cpu\makefile.am and add mmx.cpp entry. The first 2 commands into Msys2:

patch -p1 < mmx_20200624.diff
./autogen.sh -lssp

after them i edit the file src\gui\midi_fluidsynth.h deleting: LOG(LOG_MISC,LOG_WARN)("MIDI:fluidsynth: Unknown Command: %08lx", (long)msg) remaining only ; and at the end configure and make:

CPPFLAGS="-DC_FPU=1 -DC_MMX=1" ./configure LIBS="-Wl,--as-needed -lssp"
CPPFLAGS="-DC_FPU=1 -DC_MMX=1" make LIBS="-Wl,--as-needed -lssp"
make LIBS="-Wl,--as-needed -lssp"
CPPFLAGS="-DC_FPU=1 -DC_MMX=1" make

as far as i know all this steps are needed to get the .exe. I don't know for now if something else doesn't work, but 3d acceleration (voodoo card), mmx, mounting .img files and sound blaster 16 surely works (got no errors from status window). Thanks for the help.