Yeah, clang has a feast with Dosbox warnings. I don't think you need to worry about that too much. Eventually the devs might want to clean that up. I think I posted some warnings ages ago... I need to look it up, there is a compiler switch to silence the warnings...
The -j9 switch makes compiling a lot faster since it compiles stuff in parallel. And the clutterless makes it appear faster 😉
EDIT: When I first posted this message, I asked this question:
I may want to add screenshot support to my solution someday. How can I link libpng statically to this project? I have png.h in /opt/local/include/libpng15.
I now see that you already answered the question a couple of years ago. Here is what I think is the answer (I haven't tested whether the screenshot function actually works!):
1. near the top of the build script, UNcomment the line:
1export LDFLAGS='-L/opt/local/lib '$SDK' '$OPT
2. after the first sed command and error-test add this code:
An updated AppleScript for a mail rule when new messages arrive, this time only for Dosbox
1set subj to "DOSBox" 2tell application "Mail" 3 activate 4 set icon_path to ((path to applications folder) as string) & subj & ".app:Contents:Resources:" & subj & ".icns" 5 set snapshotdialog to display dialog "New revision!!! 6 7Build " & subj & " snapshot? 8" buttons {"Cancel", "OK"} giving up after 110 with icon alias icon_path with title subj 9 if button returned of snapshotdialog = "OK" or gave up of snapshotdialog is true then 10 tell application "Terminal" 11 activate 12 tell application "System Events" to tell process "Terminal" to keystroke "t" using {command down} 13 delay 1 14 do script "cd ~/code/sh; . " & subj & "snapshot.sh" in selected tab of the front window 15 end tell 16 end if 17end tell
As for your patched compile maybe we can have a look to make your SDLmain.cpp up to current again. I'm not sure that is that safe to have that not up to date with current SVN.
Another thing I do in my script: I no longer use sed but have a patch file to change the libs.
so instead of calling two times sed I only run once "patch -p0 -i intel.diff"
That patch needs to be adapted to your needs, though. I'm also building with SDL_sound, so my static compile is a bit different to yours (not to mention different paths 😀)
Thank you for your offer to look at my SDLmain.cpp. I remembered, after posting my message, that SDLmain.cpp is the one file that is completely different in my Windows and OS X builds, because I've adapted the modifications made in the dbDOS project that add pasting from the Windows clipboard and a custom system menu (the menu that drops down from the icon in the upper left corner of the window). In my OS X project, SDLmain.cpp closely tracks SVN, because I wasn't able to add those Windows-style features. The version of SDLmain.cpp that's out of step in my project in the Win32 one.
I really don't expect you to spend time on a Windows-based project, but if anyone is interested in using these added Windows-based features, here's the file, attached.
I made this by modifying the file from the dbDOS 1.5 code (http://www.dbdos.com, in the patches section). The author seems to have based it on Megabuild and added the clipboard and one or two other things. The rest of my project uses patched SVN, but it was beyond my abilities to put the added features into current code.
Again, I don't expect anyone to spend time on this, but if someone is interested in the added features - which I only modified, and didn't write - it may be worth a look.
so instead of calling two times sed I only run once "patch -p0 -i intel.diff"
That patch needs to be adapted to your needs, though. I'm also building with SDL_sound, so my static compile is a bit different to yours (not to mention different paths 😀)
I'm going to use your patch method in my build script instead of sed, as you suggest. One question: in my build script, following your suggestion, I change the makefile both in the top-level directory and in src. Do you do the same thing with your patch file??
No surprises here: I wanted to confirm that, by following Dominus's instructions, I was able to build DOSBox under OS X 10.9 Mavericks. Lots of warnings appeared, but no errors. Thanks again to Dominus for figuring out how to do this!
I recently tried to build my DOSBox project again under Mavericks, using the script generously supplied by Dominus, which has worked well for years with minor revisions. I hadn't built DOSBox since last December.
This time, I got an error about not being able to find libpng 1.5, but that was because macports had updated me to libpng 1.6, so I changed every reference to libpng15 in my script to libpng16, and built successfully again. The resulting build works perfectly on my system.
Unfortunately, when I try to run it it on a clean install of OS X 10.9.3, without macports installed, I get this error message:
1dyld: Library not loaded: /opt/local/lib/libX11.6.dylib
What puzzles me about this is that I didn't know I was using X11 at all in my build. There's no reference to it the build script. (Of course, /opt/local/lib/libX11.6.dylib is present on the system I build with, thanks to macports, but I'm trying to make a static build that I can distribute - and the build I made in December works perfectly on the same clean install of OS X in which the new build fails.)
I hope Dominus has an easy answer to this problem - he's guided me every step of the way so far - but if not, I hope someone else might have an idea about how to solve it.
Some library is pulling in x11...
Maybe SDL or maybe libpng 1.6 OR you are pulling in a xquartz lib accidentally. So investigate sdl and libpng whether they are built without x11 (or if it is libpng whether there is a no_x11 variant)
That was quick! I think you found the answer. The results of "sudo port installed" include:
libsdl @1.2.15_3+universal+x11 (active)
I'm waiting for an "upgrade outdated" to complete before I try to replace this with a no-x11 installation of libsdl. This thread seems as if it might be useful:
Yup that's it 😉
But you won't need to change all of them.
First look up which port that depends on x11 also depends on SDL (my guess is none but who knows). There is some port command to list dependents but I don't know without looking it up 😉
Then find out if that port can be installed without x11. This way you won't need to force upgrade too many ports.
Just to be thorough, I uninstalled everything that showed up in
sudo port installed | grep x11
which turned out to be a lot. If I need any of it, I'll just reinstall it with the -x11 +quartz option.
Incidentally, when I reinstalled libsdl, I needed to use the +universal option to create an executable that worked in a clean system. Oddly enough, my usual system had no trouble with the executable that I built without the +universal variant of libsdl, but that non-universal build wouldn't run in my clean system. So I installed +universal, built again, and now the executable worked in the clean system. So I've got it working now again, thanks to your help!
Last edited by emendelson on 2014-05-29, 16:54. Edited 2 times in total.
My usual system is 10.9.3 on a 2012 Macbook Air, and it seems to think it is a 64-bit system, so I'm puzzled. I may have done something else wrong, and will experiment. I'll report back if I learn more. Meanwhile, thank you again for sorting this out so quickly!
A possibly interesting development about building DOSBox under OS X 10.9:
My Mavericks system was getting bloated, so I wiped the disk and installed it again. I installed MacPorts but didn't install any ports. Using the script that I put together with Dominus's help, I then tried to build a static-linked DOSBox.
The build failed because I didn't have autoconf, so I installed autoconf through MacPorts, and built again - without having downloaded sdl or anything else through MacPorts. The resulting build didn't have libpng, SDL_net, or libSDL_sound, but I don't use those anyway.
The autogen.sh part of the script generated these messages:
1./autogen.sh: line 8: aclocal: command not found 2./autogen.sh: line 10: automake: command not found
but this didn't seem to make any difference.
This does seem to make it easier to build DOSBox. Thanks again to Dominus for figuring out how to do it!
