VOGONS

DOSBox SVN Daum: Faults, Fixes, and The Future (64-bit and Beyond)

Topic actions

First post, by leycec

Posted on 
User metadata
Rank Newbie
Rank
Newbie

The newest release of DOSBox SVN Daum now builds under 64-bit architecture. It doesn't officially, of course. The only downloads available at http://ykhwong.x-y.net for OS X, Linux, and probably Windows are 32-bit. But I've discovered the petty secrets of how to compile a 64-bit Daum for yourself at home... and it's not pretty.

In fact, it's uniformly awful. After wrestling with the Daum patchset for a little over a week, I remain firmly convinced that Daum as shipped is currently uncompilable on most systems – whether 32- or 64-bit.

To make sense of all this madness, I've thus structured this post a bit... uniquely.

We kick off with a list of practical issues facing the Daum codebase – from major compilation and linkage errors to minor dependency and patch errors. To avoid descending into unmindful trolldom, I offer practical fixes for each – in all cases, fixes that anyone can apply at home. For Gentoo and Sabayon Linux users, I've gone one step further and completed a working ebuild for Daum and all dependencies (OpenGLide, SDL SVN with OpenGL-HQ support, SDL_sound SVN). (More on that in another post, assuming I don't collapse of sleep deprivation first.)

I wrap things up with a discussion of the Daum codebase, community, and development methodology. Yup, shit just got real. If Daum already works for you, just skip the error reports and go straight to the "good stuff" at the end.

Before we wade into the nitty-gritty, I should probably clarify: I really like the Daum patchset and wish it nothing but continued success. In the crowded marketplace of unofficial DOSBox patches, the Daum and DOSBox-X patchsets clearly reside at the head of the pack. I humbly appreciate the very real and significant effort that Taewoong (ykhwong), gulikoza, HAL 9000, and other dedicated community members have invested – either directly or indirectly – into Daum. At the end of the day, that's why I authored this thread. Because Daum is too close to completion to let it fall apart in the final mile.

So here we go.

Let Loose the Dogs of War

Let's be frank: DOSBox SVN Daum is fundamentally uncompilable in its current state. The autotools files ("Makefile.am", "configure.am") are predominantly either broken or insufficient; the codebase itself is significantly broken in numerous places, including but not restricted to the minizip patch (incompatible with the current release of "zlib") and dynamic CPU cores (referencing undefined functions); the documentation neglects to mention whole nontrivial dependencies (OpenGLide, I'm looking at you); the OpenGL-HQ patch on http://ykhwong.x-y.net fails to apply to SDL sources. I could go on. And I will.

Paradoxically, ykhwong and a handful of others continue to successfully compile and distribute 32-bit Windows, OS X, and Linux releases. I congratulate them. I'm also mystified at how they managed to do it.

Let's see why.

Compilation and Linkage Errors

Daum suffers three severe compilation and linkage errors. For each, I give a verbal description of the solution. For those who'd rather automate your way to victory, here's a series of "sed" commands patching the errors for you. Run the following from the top-level directory to which you extracted the Daum source code:

	sed -ie 's~^\(#include "zlib.h"\)$~\1\
#ifndef OF /* function prototypes */\
#  ifdef STDC\
#    define OF(args)  args\
#  else\
#    define OF(args)  ()\
#  endif\
#endif~' include/ioapi.h
	sed -ie '/if (PAGING_ForcePageInit(lin_addr)) {/,+6d'\
		src/cpu/core_dynrec/decoder_basic.h
	sed -ie '$ c\
Bits CPU_Core_Dyn_X86_Run(void) {\
	return 0;\
}\
Bits CPU_Core_Dyn_X86_Trap_Run(void) {\
	return 0;\
}\
void CPU_Core_Dyn_X86_Cache_Reset(void) {\
}\
#endif' src/cpu/core_dyn_x86.cpp

I should also provide a single patch for easy application. But I'm woefully tired, pathetically lazy, and would like other people to actually understand what went wrong.

So – in the order in which I encountered and fixed each error, let's go.

Undefined zlib Macro OF()

This is the first compilation error I received:

    x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I..  -I../include -I/usr/include/SDL -D_REENTRANT  -march=native -O2 -pipe -c miniunz.c
    In file included from ../include/unzip.h:55:0,
                     from miniunz.c:46:
    ../include/ioapi.h:127:51: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘OF’

What's happening here?

I'm glad you asked. The system-wide "zconf.h" library installed by zlib used to define a macro named OF(). This was obviously a bad name for a macro to be used by hundreds of thousands of cross platform-portable applications the world over, so newer versions of zlib mangled it to _Z_OF().

Guess what macro Daum expects? OF(). It doesn't exist on newer systems, causing the above compilation error. The correct fix is to rename all instances of "OF(...)" to "_Z_OF(...)" and require the user install a sufficiently new version of zlib. Since I'm (again) pathetically lazy, I just added the old definition of OF() to Daum's "include/ioapi.h" file after inclusion of "zlib.h":

    #include "zlib.h"
    ifndef OF /* function prototypes */
      ifdef STDC
        define OF(args)  args
      else
        define OF(args)  ()
      endif
    endif

This works, though it's not entirely pretty. Who cares.

Undefined Function PAGING_ForcePageInit()

This is the next compilation error I received:

    cpu/libcpu.a(core_dynrec.o): In function `MakeCodePage(unsigned long, CodePageHandlerDynRec*&)':
    core_dynrec.cpp:(.text+0x88d7): undefined reference to `PAGING_ForcePageInit(unsigned long)'

What in the Ninety Stygian Hells is happening here?

Oh, boy. This is a bad one. I'm shaking my head already. The reference to PAGING_ForcePageInit() is undefined, because... it's not defined. That's right: PAGING_ForcePageInit() is declared by "include/paging.h" but never actually defined anywhere. While it's not at all clear what the right thing to do here is, I noticed this VOGONS thread in which HAL 9000 recommends deleting the entire if conditional in "src/cpu/core_dynrec/decoder_basic.h" calling PAGING_ForcePageInit(). After doing so, your MakeCodePage() function should resemble:

    static bool MakeCodePage(Bitu lin_addr,CodePageHandlerDynRec * &cph) {
        Bit8u rdval;
        //Ensure page contains memory:
        if (GCC_UNLIKELY(mem_readb_checked(lin_addr,&rdval))) return true;

        PageHandler * handler=get_tlb_readhandler(lin_addr);
        if (handler->flags & PFLAG_HASCODE) {
            // this is a codepage handler, and the one that we're looking for
            cph=(CodePageHandlerDynRec *)handler;
            return false;
        }
        if (handler->flags & PFLAG_NOCODE) {
            //!!!!!!! Here's where the deleted if conditional used to be !!!!!!!!
            if (handler->flags & PFLAG_NOCODE) {
                LOG_MSG("DYNREC:Can't run code in this page");
                cph=0;
                return false;
            }
        }
        // The rest of the function is the same...
    }

This works, though it's really not pretty. [Insert collective shrug here.]

Undefined Function PAGING_ForcePageInit()

This is the next compilation error I received:

    x86_64-pc-linux-gnu-g++  -march=native -O2 -pipe -std=c++0x -fpermissive  -I/usr/include/freetype2  -Wl,-O1 -Wl,--as-needed -o dosbox dosbox.o save_state.o miniunz.o minizip.o unzip.o zip.o iowin32.o ioapi.o mztools.o  cpu/libcpu.a debug/libdebug.a dos/libdos.a fpu/libfpu.a hardware/libhardware.a shell/libshell.a gui/libgui.a ints/libints.a misc/libmisc.a hardware/serialport/libserial.a hardware/parport/libparallel.a libs/gui_tk/libgui_tk.a libs/porttalk/libporttalk.a hardware/reSID/libresid.a -lSDL_sound -lasound -lm -ldl -lpthread -ltbb -lFLAC -lgthread-2.0 -pthread -lrt -lglib-2.0 -lSDL -lpng -lz -lfreetype -lz -lbz2 -lpcap -lSDL_net -lX11 -lGL -lfluidsynth -lphysfs -lz
    cpu/libcpu.a(cpu.o): In function `CPU_FindDecoderType(long (*)())':
    cpu.cpp:(.text+0x50f6): undefined reference to `CPU_Core_Dyn_X86_Run()'
    cpu.cpp:(.text+0x5117): undefined reference to `CPU_Core_Dyn_X86_Trap_Run()'
    cpu/libcpu.a(cpu.o): In function `(anonymous namespace)::SerializeCPU::setBytes(std::basic_istream<char, std::char_traits<char> >&)':
    cpu.cpp:(.text+0x5609): undefined reference to `CPU_Core_Dyn_X86_Cache_Reset()'
    hardware/libhardware.a(voodoo_interface.o): In function `Voodoo_PCI_Enable(bool)':
    voodoo_interface.cpp:(.text+0xad3): undefined reference to `CPU_Core_Dyn_X86_SaveDHFPUState()'
    voodoo_interface.cpp:(.text+0xae1): undefined reference to `CPU_Core_Dyn_X86_RestoreDHFPUState()'
    collect2: ld returned 1 exit status

At this point, an uneasy lethargy begins to settle over the mind.

What is this? No, really. Just what in the Playerless Wastes of Azeroth is going on with this codebase? Has anyone actually ever succeeded in compiling this?

I begin to harbour doubts. Stupidly, I press on. And it hits me like a GCC-crafted bludgeon. I'm trying to compile Daum under a 64-bit architecture. Daum must no longer support 64-bit architecture! It doesn't actually say that anywhere, of course. But "by their fruits ye shall know them." But that doesn't make sense! Daum used to support 64-bit architecture. It's right there in the changelog:

Oct. 30. 2010

Fixed a crash while pausing DOSBox (Windows build)
Uploaded a build for Linux (x86, x86-64)

But things have changed.

So, I decided to try and set things right. It worked. I replaced the last line
of "src/cpu/core_dyn_x86.cpp" ("#endif") with the following lines, evaluated when not compiling on a 32-bit machine (i.e., when compiling on a 64-bit machine):

    Bits CPU_Core_Dyn_X86_Run(void) {
        return 0;
    }
    Bits CPU_Core_Dyn_X86_Trap_Run(void) {
        return 0;
    }
    void CPU_Core_Dyn_X86_Cache_Reset(void) {
    }
    #endif

Voila! A Daum that almost compiles, links, and installs on 32- and 64-bit systems.

Dependency and Patch Errors

The compilation and linkage errors were pretty awful, right? Right. In the end, however, they were only a slice in the awful pie that is Daum compilation.

The OpenGL-HQ SDL Patch

Daum requires SDL 1.2 live sources to be patched with a homebrew OpenGL-HQ patch available under "Download" as "OpenglHQ patch", described as "...apply to SDL 1.2 hg | updated on Jun-26-2013".

"Great," I thought. "How hard can that be?" Finally, something that will just work! I followed the simple instructions in "linux.txt":

    patch -up1 < openglhq-dosbox-for-sdl-20130726_msvc_gcc.patch

And the patch failed to cleanly apply.

    patching file ./configure.in
    Hunk #1 succeeded at 2906 (offset 30 lines).
    patching file ./include/SDL_config.h.in
    patching file ./include/SDL_video.h
    patching file ./src/events/SDL_keyboard.c
    patching file ./src/events/SDL_mouse.c
    patching file ./src/main/macosx/SDLMain.m
    patching file ./src/thread/pthread/SDL_systhread.c
    patching file ./src/thread/win32/SDL_sysmutex.c
    patching file ./src/video/SDL_glfuncs.h
    patching file ./src/video/SDL_sysvideo.h
    patching file ./src/video/SDL_video.c
    patching file ./src/video/openglhq/Makefile
    patching file ./src/video/openglhq/README
    patching file ./src/video/openglhq/SDL_ohqthread.h
    patching file ./src/video/openglhq/SDL_ohqvideo.c
    patching file ./src/video/openglhq/SDL_ohqvideo.h
    patching file ./src/video/openglhq/SDL_openglhq_pass1.fp
    patching file ./src/video/openglhq/SDL_openglhq_pass1.h
    patching file ./src/video/openglhq/SDL_openglhq_pass2.fp
    patching file ./src/video/openglhq/SDL_openglhq_pass2.h
    patching file ./src/video/openglhq/SDL_openglhq_pass3.fp
    patching file ./src/video/openglhq/SDL_openglhq_pass3.h
    patching file ./src/video/openglhq/SDL_openglhq_table.dat
    patching file ./src/video/openglhq/SDL_openglhq_table.h
    patching file ./src/video/openglhq/asciidump.c
    patching file ./src/video/openglhq/hexdump.c
    patching file ./src/video/openglhq/tablebuilder.ui
    patching file ./src/video/openglhq/test.c
    patching file ./src/video/quartz/SDL_QuartzVideo.m
    patching file ./src/video/wincommon/SDL_lowvideo.h
    patching file ./src/video/wincommon/SDL_sysevents.c
    patching file ./src/video/wincommon/SDL_syswm.c
    patching file ./src/video/wincommon/SDL_syswm_c.h
    patching file ./src/video/windib/SDL_dibvideo.c
    patching file ./src/video/windx5/SDL_dx5video.c
    patching file ./src/video/x11/SDL_x11modes.c
    patching file ./src/video/x11/SDL_x11modes_c.h
    patching file ./src/video/x11/SDL_x11video.c
    Hunk #1 FAILED at 131.
    Hunk #2 FAILED at 1482.
    2 out of 2 hunks FAILED -- saving rejects to file ./src/video/x11/SDL_x11video.c.rej

The problem is almost certainly DOS line endings. ykhwong's OpenGL-HQ patch contains spurious DOS-specific carriage returns (<Ctrl-m> characters). Since the OS X and Linux versions of SDL contain only Unix line endings, the patch fails to apply. Globally removing all carriage returns from the patch would probably do the trick. Probably. I only discovered the carriage return issue much later, however – long after the fact. (If I had discovered it at the time, I'm still not sure I could have mustered the interest in addressing it.)

The mind boggles. At this point, I was nearly in tears. Yes, DOSBox SVN Daum had reduced a grown man to incessant teeth gnashing and white-knuckled fists.

At the end of my rope, I stumbled across the official archive of OpenGL-HQ patches. No mention of the above patch. I still have no idea where ykhwong got it from. (Self-authored, I suspect...) At this point, I probably no longer care.

I downloaded the newest official cross-platform patch, crossed multiple fingers and toes, and attempted to patch SDL 1.2. It cleanly applied. And the flaming sword-wielding angels wept then.

Did I mention that you're not done yet, though? Even after applying the patch, you have to manually generate additional header and ".c" files. Assuming you're building SDL 1.2 in "/tmp/sdl":

        mv SDL-1.2-openglhq-2012-10-19.zip /tmp/sdl/src/video
        cd /tmp/sdl/src/video
        unzip SDL-1.2-openglhq-2012-10-19.zip
        cd ../..
        make -C src/video/openglhq

...and I'm all out of bubblegum.

The OpenGLide Dependency

The "linux.txt" documentation omits all mention of a key dependency: OpenGLide, an open-source Glide to OpenGL wrapper. Installation is trivial, though completely undocumented. Their CVS repository contains no documentation – not a single "INSTALL" or "README" file or text file of any sort. In fact, the only set of instructions that Google willingly burped up come from a mid-2009 German language blog post. I wish I was kidding.

While OpenGLide's SourceForge project does offer source archives, the last archive was uploaded in 2002. The most recent change to their repository was committed in 2010. Needless to say, use CVS to install OpenGLide.

Note that OpenGLide depends on SDL 1.2 and thus must be installed after SDL as follows:

    cvs -d:pserver:anonymous@openglide.cvs.sourceforge.net:/cvsroot/openglide login
    cvs -z3 -d:pserver:anonymous@openglide.cvs.sourceforge.net:/cvsroot/openglide co -P openglide
    openglide/
    ./bootstrap
    ./configure
    make
    make install

Rock the 3Dfx Casbah.

Configuration Globals

All sane autotools-based Makefiles internally list all libraries (LIBS), gcc and g++ options (CPPFLAGS), and g++-specific options (CXXFLAGS) required for compilation and linkage. The user doesn't have to define them. The Makefiles define them already.

But this is Daum. Before running "./configure", you have to manually export the following globals:

    LIBS+=" -ltbb -lFLAC $(pkg-config --libs gthread-2.0)"
    CPPFLAGS+=" -I /usr/include/openglide/ $(pkg-config --cflags gthread-2.0)"
    CXXFLAGS+=" -std=c++0x -fpermissive"
    export LIBS CPPFLAGS CXXFLAGS

The "linux.txt" documentation fails to mention the need to set ${CPPFLAGS} at all or that pre-4.7 versions of g++ require "-std=c++0x" rather than "-std=c++11" and improperly omits the "-fpermissive" from ${CXXFLAGS}. If you try to compile without these options, you're going to have a bad time.

It Goes On and On and On

But I'm stopping here. Oh, I should probably discuss the vortex of sanity-rending pain that was "/usr/include/GL/gl.h": manually commenting out about twenty functions from your system-wide OpenGL header (I'm not kidding) before compiling DOSBox SVN Daum. Who honestly thought that was a good idea? WHO!?!? Anyone? Because the following definition applies to them, writhing as they probably are in a heroin-induced haze of hypnagogic self-delusion:

"A bunch of mindless jerks who'll be the first against the wall when the revolution comes."

And with that, to quote "There Will Be Blood":

"I'm finished."

The Future

The ever-vigilant VOGONS community has already documented many of these same issues and their fixes. Consider the "decoder_basic.h" error. HAL 9000 publicly described a stable fix in late 2011. It never made its way into the patchset.

But this isn't HAL 9000's fault. It's no one's fault. No one's to blame. As often in real life, people didn't fail; the system of maintaining large patchsets through forum threads failed. The "decoder_basic.h" error wasn't left unfixed because of a lack of human attention. It was left unfixed because there's no infrastructure, organization, or documentation to support fixing errors in Daum or other patchsets outside of VOGONS. VOGONS, however awesomely helpful (and it is!), is not enough.

There's no bug tracker, so there's no sane way of managing compile- or runtime issues – especially when they don't effect the patchset maintainers themselves. There's no public wiki, so there's no sane way for users to manage these issues themselves in a structured manner. There's no hosted repository, code browser, or online documentation, so it's never clear just what the current patchset even contains.

This has to change, people. We can fix the broken system.

Officially, Daum is just another DOSBox patchset. A rather large patchset complete with its own dedicated websites (!), changelogs, source tarballs, and platform-specific installation packages – all internationalized into multiple spoken languages (e.g., Korean, English).

Unofficially, that doesn't sound like just another DOSBox patchset. That sounds like a DOSBox fork.

We can't call it that, of course. Forks are offensive. They divide volunteer contributors into fanatically opposed camps. We've all seen it: "ffmpeg" vs. "libav", "openoffice" vs. "libreoffice", "mysql" vs. "mariadb". So I fully appreciate that the community doesn't want to offend anyone. But I think it's time we called a spade a spade. Daum isn't just another patchset.

Because Daum isn't just another patchset, it's beginning to need things that ordinary patchsets don't: infrastructure, organization, and documentation.

Let's talk about infrastructure first.

Future Infrastructure

The Daum codebase needs to be under public revision control – ideally through an online project host providing code browsing, bug tracker, mailing list, and wiki functionality. Since I host several projects at github, I'm probably not the most unbiased source. But any free project host would do, including bitbucket (Mercurial "hg") and launchpad (Bazaar "bzr").

The codebase could also benefit from an eventual transition away from the current autotools-based make system. It's fragile, it's unwieldy, it's obscure; in a word, it's a mess.

It also requires significant modification. At the least, DOSBox patches requiring nontrivial changes to system dependencies (e.g., the OpenGL-HQ patch requiring SDL itself to be patched with OpenGL-HQ support) should be toggleable by command-line options (e.g., "./configure --disable-sdl-openglhq"). And those options should probably be disabled by default.

Since the build system has to be modified anyway, replacing it now with a modern, maintainable, and well-documented alternative makes some sense – say, CMake. From the downstream user perspective, CMake just works. As a Gentoo developer, I cherish technology that "just works." Autotools never "just works." Painfully often, it never works at all.

Future Organization

Get the infrastructure right and the organization follows. I wouldn't be surprised to see a self-assembling community of developers and users leap into existence the picosecond a public repository goes live.

As a community outsider, I probably have nothing constructive to add here. Next!

Future Documentation

The documentation is a hit and miss affair. What little documentation there is is segregated to "linux.txt" in the source. Despite the filename, this file documents installation for all platforms. It fails to document a significant dependency installable only from live CVS sources: OpenGLide. It also fails to document how to actually configure any of the included patches after installation. How do you enable patched support for OpenGL-HQ, fluidsynth, Glide, or the xBRZ scaler? You Google it. Like every God-fearing DOSBox user, you pray that whatever Google unearths (almost always from this forum) actually relates to whatever patch Daum happens to have integrated.

Ideally, Daum-specific instructions should also be merged into the general DOSBox instructions ("INSTALL", "README"). I'd settle for anything, though.

The End My Friend

Now I'm really finished. I drink your milkshake!

Reply 1 of 88, by leileilol

Posted on 
User metadata
Rank l33t++
Rank
l33t++

It's a hobby.

Has anyone actually ever succeeded in compiling this?

truth5678

apsosig.png
long live PCem

Reply 2 of 88, by gulikoza

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

64-bit dyncore is slower than 32-bit dynamic core. While having 64-bit builds is certainly good (I helped write the x64 core), using 32-bit build is preferable on platforms that support that.

http://www.si-gamer.net/gulikoza

Reply 3 of 88, by Dominus

Posted on 
User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

If the trollish comments were toned down it would be a good and useful read 😉
Daum instructions will not make it into normal dosbox svn as most of those patches are unwanted in trunk 😉

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 4 of 88, by IIGS_User

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

Another question:
Anyone got the Mac OS X port of Daum Café to run?
When I click the DOSBox unix executable file, I get:

dyld: Library not loaded: libtbb.dylib Referenced from: /Volumes/LaCie/Emulatoren/DOSBox/Daum Cafe/20130725_Intel_i386/dosbox […]
Show full quote

dyld: Library not loaded: libtbb.dylib
Referenced from: /Volumes/LaCie/Emulatoren/DOSBox/Daum Cafe/20130725_Intel_i386/dosbox
Reason: image not found
Trace/BPT trap: 5
logout

Tried to copy the required libraries to their requested location on the hard disk
("You need to copy all those dependencies to the right places if required.", the /opt/local/lib/ and /usr/lib/ ones) ,
but next time OS X 10.8 refused to boot.

Klimawandel.

Reply 6 of 88, by IIGS_User

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

Dominus, thanks for reporting.

After playing around with Terminal, got it now by using
su <Name of Admin>
Password:
Sudo /Volumes/LaCie/Emulatoren/DOSBox/Daum\ Cafe/20130725_Intel_i386/dosbox

Result is the same as above, but finally it tries to run this way.

I believe I've to add the path to the library files which are in the LIBS subfolder of OS X Daum Café

Klimawandel.

Reply 8 of 88, by gulikoza

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

Do you have libtbb.dylib even installed? AFAIK this lib was added by the xBRZ patch, it's not needed by vanilla dosbox.

http://www.si-gamer.net/gulikoza

Reply 9 of 88, by IIGS_User

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

Nice hint, where to install it, please?

Now I noticed, by default the file in request (libtbb.dylib) is stored in the main folder of Daum Café's DOSBox itself.

Klimawandel.

Reply 10 of 88, by ykhwong

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

Hi, leycec. First thanks for your detail error reports.
As a hobby, DOSBox SVN-Daum is a tiny work done by me as just one of the DOSBox enthusiasts.

leycec wrote:

The Daum codebase needs to be under public revision control

Well, I have lots of patches that are intended to be applied to the latest dosbox svn base. When newer revision comes up on sourceforge, I try to apply my whole patches to it. I am not willing to use public revision control though those patches are hard to be maintained on my own.

leycec wrote:

No mention of the above patch. I still have no idea where ykhwong got it from.

Have you ever clicked "(Related link)" besides OpenglHQ patch? Even though that is not explicitly mentioned, it will lead you to Moe's website which is primary source of openglhq. Actually I got the latest official openglhq patch from his website which is still broken when compiling on Visual Studio. I fiddled with it, finally fixed the issue, and sent it to the author by email. I am sorry that there are serious line endings issues in the modified patch. You can find a refined openglhq patch that patch tool can accept here:
DOSBox-G: A heavily modified Daum build

leycec wrote:

Undefined zlib Macro OF()

Weird. I haven't received the compilation error on any platform that I've tried even with the zlib 1.2.8 which is the latest one released on this April.

leycec wrote:

Undefined Function PAGING_ForcePageInit()

Yes, I confirm that PAGING_ForcePageInit() was removed by applying h-a-l's MB6 diff.

leycec wrote:

Daum must no longer support 64-bit architecture! It doesn't actually say that anywhere, of course. But "by their fruits ye shall know them." But that doesn't make sense! Daum used to support 64-bit architecture.

I used to have 64bit compilation few years ago. Like gulikoza said above, however, I decided to stop providing it as someone advised me not to do it due to the performance issue in 64-bit dyncore.

Overall, DOSBox is open source and there are currently several variants which include special changes and enhancements (gulikoza, uberbuild, mb6, dosbox-g, dosbox-x, svn-daum, moe, etc) When I borrow external patches into my release, I mention who created them on my website and in SVN-specific manuals since I think giving credit to someone is important. Some patches are not from external sources. For example, I made GUI menu bar and some features for users who are not familiar with DOS commandline. Maintaining lots of patches and making them work together in one project is not simple, that is a hard work. I just started svn-daum for people who want to try extra features.

Last edited by ykhwong on 2013-09-01, 02:53. Edited 1 time in total.

Reply 11 of 88, by ykhwong

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

Sorry for my poor explanation for building dosbox svn-daum and also probably my poor English which can make you thrown into confusion.
I post a detailed guide to how to build dosbox svn-daum here.
This may not be complete, which means something can be missing or wrong. Any questions/opinions/comments are welcome.

--------------------
This guide will show you how to build DOSBox on 32-bit based system with GCC.

For building debugger-enabled build, refer to Guide to the DOSBox debugger
Curses library is required to support debugging.

SVN-Daum build requires the following libraries:
SDL | physfs | zlib | libpng | fluidsynth | libflac | libogg | libvorbis | libpcap | freetype | sdl_net | sdl_sound | libtbb
(mpg123 is needed if you are using visual studio)

Linux
Get the latest version of Ubuntu Desktop (13.04 or higher) from http://www.ubuntu.com/ and install.
Create and logon as your account. Open Terminal.

******* Preparation
To obtain admin previlege, type:
sudo su

* To download source from repository, you need Mercurial, Git, and Subversion.
apt-get install mercurial git subversion

* This step is for setting basic components for building DOSBox.
apt-get install autoconf
apt-get install libglew-dev
apt-get install g++
apt-get install cmake
apt-get install cmake-qt-gui

apt-get install libasound2-dev libpulse-dev

* The following lines are for libpcap installation.
apt-get install flex
apt-get install bison

Now, change to /tmp by typing cd /tmp

******* automake and libtool
Don't install automake 1.14 which interrupts the installation of glib.
automake can be obtained from http://ftp.gnu.org/gnu/automake
Get automake-1.13.2 and extract to /tmp
./configure --prefix=/usr/local && make && make install

Download libtool from http://www.gnu.org/software/libtool/ and extract to /tmp
./configure --prefix=/usr/local && make && make install

******* SDL
Never use SDL 2.0 which is currently incompatible with DOSBox! Hg of SDL 1.2 is enough.
hg clone -u SDL-1.2 http://hg.libsdl.org/SDL

Now you've got SDL. Change to SDL directory.
Get Moe's openglhq patch from my website and apply it to the SDL source.
This patch includes some fixes for DOSBox and also implements openglhq output.

patch -up1 < openglhq-dosbox-for-sdl-202121117_msvc_gcc.patch
./auotgen.sh && ./configure --enable-shared=no && make && make install

******* zlib
Get the latest version of zlib from http://www.zlib.net/ and extract ti to /tmp

./configure --static && make && make install

******* libpng
git clone git://git.code.sf.net/p/libpng/code libpng-code

After git clone, change to libpng-code directory and type:
make -f scripts/makefile.linux
If you are on MinGW/MSYS, use make -f scripts/makefile.gcc

cp libpng.a /usr/local/lib/libpng.a
cp png.h /usr/local/include/png.h
cp pngconf.h /usr/local/include/pngconf.h
cp pnglibconf.h /usr/local/include/pnglibconf.h
cp libpng-config /usr/local/bin/libpng-config

******* SDL_net
SDL_net is used for networking.
Don't use hg version of SDL_net as it does not directly support SDL 1.2.
Get SDL_net 1.2.8 and extract it to /tmp. Change to sdl_net directory and type:
./autogen.sh && ./configure --enable-shared=no && make && make install

******** libflac (needed for SDL_sound)
git clone git://git.xiph.org/flac.git

After git clone, change to flac directory and type:
./autogen.sh && ./configure --enable-shared="" --enabled-static && make && make install

******** libogg (needed for SDL_sound and Vorbis)
svn co http://svn.xiph.org/trunk/ogg

After svn clone, change to ogg directory and type:
./autogen.sh && ./configure --enable-shared=no && make && make install

******** libvobis (needed for SDL_sound)
svn co http://svn.xiph.org/trunk/vorbis

After svn clone, change to vorbis directory and type:
./configure --enable-shared=no --disable-oggtest && make &&make install

******** physfs
This is used for zip/7z mounting.
hg clone http://hg.icculus.org/icculus/physfs/

Change to physfs directory and type:
cmake-gui .

Click configure -> unix makefiles -> use default native compilers.
Uncheck physfs_build_shared
Click configure again
Click generate and close the cmake window.
Type:
make && make install

******* glib (needed for Fluidsynth)
In order to install glib, you need libffi, expat, and python.
Visit http://www.linuxfromscratch.org/blfs/view/svn … ral/libffi.html
Get libffi and its patch, extract it to /tmp, and apply patch:
patch -Np1 -i ../libffi-3.0.13-includedir-1.patch
./configure --prefix=/usr/local && make && make install

Get expat from http://www.linuxfromscratch.org/blfs/view/svn … eral/expat.html
Extract it to /tmp and type:
./configure --prefix=/usr/local && make && make install

Get python 2.7.5 from http://www.linuxfromscratch.org/blfs/view/svn … al/python2.html
(don't install if python is already installed)
Extract it to /tmp and type:
./configure --prefix=/usr/local --enable-shared=no --with-system-expat --with-system-ffi --enable-unicode=ucs4 && make && make install

Get glib from http://www.linuxfromscratch.org/blfs/view/svn … eral/glib2.html
Extract it to /tmp and type:
./configure --prefix=/usr/local --enable-gtk-doc-html=no --enable-debug=no --enable-static=yes --enable-shared=no && make && make install

******** Fluidsynth
This is used for loading soundfonts with MIDI synth.
svn co https://fluidsynth.svn.sourceforge.net/svnroo … runk/fluidsynth
Change to fluidsynth directory and type:
cmake-gui .
Click configure -> unix makefiles -> use default native compilers
Uncheck build_shared_libs
Click configure again. Click generate, close cmake window, and type:
make
If pthread is missing, add "-lpthread" to src/CMakeFiles/fluidsynth.dir/link.txt
make install

******** SDL_sound
hg clone http://hg.icculus.org/icculus/SDL_sound/
Change to SDL_sound directory and type:
./bootstrap && ./configure --enable-shared=no --enable-physfs=no && make && make install

******** libfreetype
This is used for printing.
git version may not work. /*giti clone git://git.sv.gnu.org/freetype/freetype2.git*/
Get freetype-2.5.0.1.tar.gz from http://www.freetype.org/. extract it to /tmp and type:
./configure --enable-shared=no && make && make install

******** libpcap
This is used for computer networking / Internet.
Get libpcap-1.4.0.tar.gz from tcpdump.org. Extract it /tmp and type:
./configure --enable-shared=no && make && make install

******** libtbb
This library will be used by xbrz scaler. (Don't compile it!)
Get the latest version of tbb from the official website http://threadingbuildingblocks.org/
Extract it to /usr/local/
Copy everything from /usr/local/lib/ia32/gcc4.4 to /usr/local/lib

--------------------
1) GL.h modification
Open /usr/include/GL/gl.h with text editor.
Comment out a block of code as shown below:
/*
GLAPI void GLAPIENTRY glActiveTextureARB(GLenum texture);
...
GLAPI void GLAPIENTRY glMultiTexCoord4svARB(GLenum target, const GLshort *v);
*/

You can revert the above change after compiling DOSBox SVN-Daum.

If everything is fine, delete everything in the working directory (/tmp).

2. Get openglide source from http://sourceforge.net/projects/openglide/ (Don't compile it)
Just extract it to /tmp/openglide

---------------------------------
Compiling DOSBox

Grab DOSBox SVN-Daum source from my website and extract to /tmp/dosbox.

The following lines can be achieved by typing chmod +x autogen.sh
aclocal
autoheader
automake --include-deps --add-missing --copy
autoconf

These export lines will add some missing libs and support for c++11 to dosbox.
export LIBS='-ltbb -lglib-2.0 -lgthread-2.0 -lFLAC'
export CXX='/usr/bin/g++ -std=c++11'

./configure --enable-core-inline && make

dobsox binary will be placed on /tmp/dosbox/src

--------------------------
Windows
Use MinGW/MSYS, a complete open source programming tool set.
Download both the latest MinGW and MSYS from http://www.mingw.org, and install MinGW first.
Run MSYS installer and you will be asked to specify the location of MinGW installation directory.

After the installation of the tool set, download and install the following:
mercurial (hg) from http://mercurial.selenic.com/
subversion from http://tortoisesvn.net/
git from http://git-scm.com/

These can be readily used on MinGW/MSYS shell commandline.

You can get Direct3D headers for MinGW from http://dim-i.net/2004/06/26/directx-devpak-for-dev-cpp/
Download DX9 Devpack, extract it with 7zip for the use with msys.

pkg-config may be required. You can get it from http://sourceforge.net/projects/gimp-win/files/

libtool, autoconf, automake, and gcc (including c++, core, libstdc++) can be obtained from http://sourceforge.net/projects/mingw/files/
Download them and extract their binary and header files to the appropriate directory (e.g., /usr/local).
As DOSBox may hang with gcc 4.7.2, try using older versions of gcc.

CMake can be obtained from http://www.cmake.org/

If you are prepared, you may follow the above instruction for Linux (except apt-get and gl.h modification part) in order to compile win32 build.

--------------------------

OS X Mountain Lion

To install packages, simply use MacPort command (http://www.macports.org/):
sudo port install [package-name]

For example, "sudo port install gcc48 +universal" will install gcc version 4.8 on your system.
"sudo port install fluidsynth +universal" will install FluidSynth on your system.
Most of the remaining libraries required by DOSBox can be installed by this way. Everything should go to /opt/local/

Obtain dosbox source and extract it to /dosbox. Change to the dosbox source directory. Do "./autogen.sh" or type the following:
aclocal
autoheader
automake --include-deps --add-missing --copy
autoconf

export LIBS='/opt/local/lib/libtbb.dylib -framework CoreAudio -framework CoreMidi -framework AudioToolbox -framework AudioUnit'
export CPPFLAGS="-I/opt/local/include"
export CC='/opt/local/bin/gcc -arch i386'
export CXX='/opt/local/bin/g++ -std=c++11 -arch i386'
export GCOV='/opt/local/bin/gcov -arch i386'

./configure --enable-core-inline --prefix=/opt/local --host=i386
make

Reply 12 of 88, by IIGS_User

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie
ykhwong wrote:

...and also probably my poor English which can make you thrown into confusion.

I, would say, me too. 😉

Thanks for posting the Install explanations, especially about Macports, I remember this from earlier times.

Klimawandel.

Reply 13 of 88, by Orka Borka

Posted on 
User metadata
Rank Newbie
Rank
Newbie

I should also point out that the way of hardcoding the libraries path for the Mac Os X build on /opt/local/bin usually conflicts with macports, homebrew, and other similar environments - they're extremely common if you're a web developer or graphic designer using Mac Os.
They usually deploy a 64-bit version of the libraries, which causes a " mach-o, but wrong architecture" if using the original libraries and way, way worse problems if the user tries to overwrite the original 64-bit dylib with the ones found inside the Dosbox SVN Daum archive. The right way, according to here (see at the end) and here would be using the @loader_path and @executable_path when compiling the libraries and copying them inside an application bundle.

...To be honest tough, It's quite easier to just use the windows build under wine, which also let's you install a more recent glide wrapper like nglide.

Reply 15 of 88, by ovvldc

Posted on 
User metadata
Rank Newbie
Rank
Newbie
Dominus wrote:

I think it needed to be run with sudo

Wow, that is ugly.

Reply 16 of 88, by ykhwong

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie
ovvldc wrote:
Dominus wrote:

I think it needed to be run with sudo

Wow, that is ugly.

No, you don't have to run it with sudo.

Reply 17 of 88, by ovvldc

Posted on 
User metadata
Rank Newbie
Rank
Newbie
ykhwong wrote:

No, you don't have to run it with sudo.

That's a relief 😀.

As for the trollish tone in the first post, and some impatience elsewhere, I get the impression that many people who don't follow the DOSBox SVN are frustrated with having no idea where the official DOSBox is headed and what kind of features the developers are aiming at. The only thing I have heard is some kind of coexistence with Wine. Daum clearly advertises the new (and useful) features it offers but its development is more opaque, hence the requests to formalise it.

Of course, both the people behind Daum and the people behind official DOSBox are free to do whatever they please with their creations. However, as both application are quite good at what they do, it seems only natural that people get enthusiastic and want to know how potential for more features and better implementation will be realised. I therefore hope that instead of the superficial tone of these messages, the devs will hear the underlying enthusiasm.

Reply 18 of 88, by Dominus

Posted on 
User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

AFAIR, some features of Daum *do* need elevated rights, I think the network feature at least. I'm happy if that is not true 😀

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 19 of 88, by IIGS_User

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie
ykhwong wrote:

No, you don't have to run it with sudo.

Thanks, Ykhwong, nice hint to run your port by entering ./dosbox into the Terminal window.

Got another result now:

Klimawandel.

Go to top of page Go to top of page
Back to DOSBox Development
Close window
Close window