Please post all questions concerning DOSBox ECE in this thread for now on, so we can keep other threads tidy and on topic!
I compiled a build of DOSBox ECE for Linux. Consider it highly experimental, since I only run Linux in a VM, I can't test all the features, because the VM is lacking hardware acceleration. So it would be very nice if someone could run some tests with it. It comes (or should come) with all the features of the Windows build, minus the possibility to select the midi device by name or a part of it. Please download it (link is in my signature), play with it and let me know if something's not working or missing!
Last edited by Yesterplay80 on 2018-12-10, 09:11. Edited 2 times in total.
Hello, any chance you could include the 128mempatch and Pentium_MMX (for CPU/memory hungry games like Blood and Win9x)? Games like MDK would also take benefit from Pentium_MMX. Also the patch to configure video memory size would be good for Build games.
More patches for more instabilities? I really hope that ECE does not go too far astray from mainline DOSBox. DOSBox-X would be a better route for Win9x and MMX. I love that ECE has the patches that increase accuracy but does not go down the path of Daum and get broken by needless bells and whistles.
Generally I'm not a big fan of adding things that only a handful of games can make use of, as collector said every patch that adds a new feature might break others, so I rather concentrate on those that all or at least many games can gain profit from.
The Daum build was working fine just until it merged with doxbox-x.
A perfect example of why the more minimal approach that ECE currently uses is the way to go. Nothing is stopping you from starting your own fork to add the patches that are important to you.
The MAME world has something they call "MAME Compiler 64" (and a few others). Makes patching and compiling a breeze for n00bs on Windows. I'm not generally a fan, but until the next DOSBox releases, maybe the DOSBox community needs something similar so that they're not dependent as much on packagers, only on patch authors to maintain their preferred patches?
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen
Such a frontend would be toolchain- and platform-specific, especially since DOSBox, unlike the "MAME World", mercifully does not use its own toolchain that is annoyingly redone every couple of months. Most DOSBox patch authors, including myself, provide a compiled Win32 executable of the latest SVN with that particular patch applied, so compilation is not required when just using one particular patch, at least on the Win32 platform. And when it comes to applying multiple patches, the potential incompatibilities between the several patches cannot be properly sorted out by a frontend anyway, only by a competent human packager.
(And if the "MAME World" is doing something a particular way, my gut reaction is to do avoid doing that at all cost.)
The Daum build was working fine just until it merged with doxbox-x.
A perfect example of why the more minimal approach that ECE currently uses is the way to go. Nothing is stopping you from starting your own fork to add the patches that are important to you.
I'd love to. I guess I keep asking everyone else because of my programming skills total lack.
The Daum build was working fine just until it merged with doxbox-x.
A perfect example of why the more minimal approach that ECE currently uses is the way to go. Nothing is stopping you from starting your own fork to add the patches that are important to you.
I'd love to. I guess I keep asking everyone else because of my programming skills total lack.
It's the most easiest part to further your programming knowledge in a couple of steps...
1. follow the guide on how to compile Dosbox yourself (essentially setting up your own development environment)
2. compile Dosbox from SVN and test that
3. learn how to apply a simple patch
4. learn how to apply a more advanced patch and deal with errors when it doesn't apply (with a text editor going through the changes - since the patch is a text file and the source code is made up of text files, it is simple looking at it and finding the pattern where the patch should have applied to)
5. learn how to add mor dependeny libraries to your development environment for patches that require those
6. have no more time to actually play since you are always busy with 4. and 5.and dealing with the fallout of the builds you offered for everyone else 😉
Vanilla DOSBox Linux build throws 'error while loading shared libraries: libasound.so.2: cannot open shared object file: No such file or directory'. libasound2 package was showing as already installed.
While trying to run DOSBox ECE under Linux(Ubuntu 16.04 LTS), I'm getting 'error while loading shared libraries: libSDL_sound-1.0.so.1: cannot open shared object file: No such file or directory'. libsdl-sound1.2 (1.0.3-7build1) was not pre-installed. Even after installation the error doesn't go away.
I'm a relatively new linux user. What am I missing?
BTW Windows ECE build works flawlessly, thanks heaps 😀 .
Last edited by gandhig on 2017-02-19, 05:29. Edited 1 time in total.
@yesterplay, make a static build of Dosbox for linux, meaning you compile all dependenies into DOSBox, otherwise you run into these above problems.
Especially with SDL_sound which can be compiled against SDL 1.2x or SDL2 on the other systems and thus might not be compatible.
Still getting the same error. Is it Ok to run the executable from any user folder?
It should be. I'm no Linux pro neither, I installed it only to get DOSBox ECE running. AFAIK it should run from every folder, the problem is that I obviously don't get all the dependent libraries compiled into DOSBox. Does anyone know which switches I have to set when configuring DOSBox?
No, those are the dynamic links. You need to exchange this with the path to the *.a files of the libraries. You can try this configure option (along with whatever else you pass to configure)
./configure LDFLAGS="-static"
But I'm not a linux guy and on OS X Ihave to rewrite LIBS= manually to use the static libs (because Apple prevents easy static linking).
If you have to do it manually get the SDL libs stuff via "sdl-config --static-libs" (or similar sdl-config -h should tell you).
Checked out a fresh SVN of DOSBox
ran /autogen.sh
ran ./configure LDFLAGS="-static-libgcc -static-libstdc++ -s"
ran sdl-config --static-libs, which resultetd in the following output:
Did you change both makefiles (root and /src)? Did you try with the LDFLAG I wrote (just -static)?
Flac dependency comes from SDL_sound. You need to strip SDL_sound off all dependencies you don't need.
Did you change both makefiles (root and /src)? Did you try with the LDFLAG I wrote (just -static)?
No, just the on under root. Now it seems to try to compile using the static libraries but results in a lot of errors, I'll try to use only the static libraries for the SDL stuff for the beginning.
yes, this seems a bit complicated. it really shouldn't pull in all of the system dlls. Very problematic are the Virtualbox stuff. This shouldn't really be in at all.
As a rough guideline, my OS X patch for the makefiles looks like this