VOGONS


First post, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

EDIT At Dominus's suggestion, I'll stop updating the code in this post, and update the script on Github instead, here:

https://github.com/emendelson/OneStopDOSBoxOS … topDOSBoxOSX.sh

First, everything important in this was provided by Dominus, who has spent years fine-tuning his method of building static-linked DOSBox under OS X. All I did was combine the bits that he suggested into a single script.

If all you need is a current SVN build of DOSBox, you don't need this script. This script is designed for anyone who wants to modify DOSBox and create a custom build (or build Wengier's LFN-and-clipboard-enabled variant). You can always download Dominus's up-to-date OS X build from here:

http://dl.dropbox.com/u/7737184/Dosbox/Dosbox-Snapshot.dmg

But if you want to build your own DOSBox, here is a script that I call OneStopDOSBoxOSX.sh. It offers to download the latest dosbox source code, and then offers to install all the libraries needed to build static-linked DOSBox in OS X; then it offers to build a dynamic-linked version (usable only on your own current system); then it offers to build a static-linked version that can work on other people's system as well as on yours; then it offers to create an OS X app from whichever version of the executable you created. (The OS X app is incomplete - it lacks an icon - but at least it will run. See below for more details.)

EDIT: The script now prompts you to install Xcode and the Xcode command-line tools if they're not already on your system. If these are not already installed. If you install Xcode when prompted, you must run Xcode once and accept the license agreement before running the script.

I can confirm that this script works perfectly in a new, clean OS X El Capitan system.

The script can go anywhere (I think), but I put it in ~/Development for easy access to all related folders. Of course you'll need to run chmod +x OneStopDOSBoxOSX.sh before you can run ./OneStopDOSBoxOSX.sh in the terminal.

By default, it downloads the source code and builds the executable in ~/Development/dosbox but you can change this by changing a variable at the top of the script. If you use the script to download the code, the resulting build will identify itself as DOSBox CVS, but (as qbix confirms in another thread) it will otherwise be identical to a build made from code downloaded from SourceForge SVN (and that SVN-based build will identify itself as DOSBox SVN).

When the script runs, it displays a zillion warnings, but it should not produce any errors. If it does, please let me know. When you build the static-linked version, you may be prompted to press Enter after the Makefile gets patched by the script - this prompt is there to make certain that the patch succeeded; if it works on your system, feel free to remove the line that does the prompting. (EDIT: As Dominus points out in a message below, you ONLY need to static-link if you are creating a build that needs to run on someone else's machine! You don't need to bother with static-linking if you are creating a build for your current system only.)

In case you see error messages when building: Exit the script; in the terminal, navigate to the folder with the source of the library or dosbox that is causing the errors; copy he block of lines with OPTs and EXPORTS from the script into the terminal; then enter these commands, and then run the script again:

autoheader -f
autoconf -f
automake -f
chmod +x *.sh
chmod configure

Except for that one "Press Enter to continue" prompt, all prompts default to "No." Press Y repeatedly the first time you run the script to build the environment and install the needed libraries.

The script builds Wengier's LFN-and-clipboard-enabled source code (you'll have to download that on your own). EDIT Wengier has updated his code so that it now works perfectly with this script. If you want the clipboard feature, you will need to add --enable-clipboard to the ./configure commands for dosbox. (This applies to Wengier's version only!)

About the part of the script that creates a MyDOSBox.app: If you add a dosbox.icns icon (perhaps from Dominus's build) to the src folder, you can uncomment the line in the script that copies dosbox.icns into the app, and that should create a complete OS X app; though possibly it won't display the right icon until you Get Info or logout, etc.

Again, all the intelligent parts of this script are the work of Dominus. All I did was automate it by putting it into one enormous script.

EDIT: I've removed the actual script code, because the current version is at the GitHub address at the top of the post.

Last edited by emendelson on 2016-06-01, 21:38. Edited 27 times in total.

Reply 2 of 15, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie
mr_bigmouth_502 wrote:

What would a person have to change to use this script on Linux?

I don't know. Certainly some of the stuff near the top would need to be changed. You may not need to download and install a lot of the libraries because most linux distros have most (all?) of them, but I don't know whether the existing ones would work to create an i386 architecture.

Also, almost certainly the part that creates a patch won't be needed; it's Dominus's fix for a problem caused by recent versions of OS X. But you don't need to build a static-linked version under Linux anyway, presumably, so this should be relatively easy to manage.

If you get it working, please let us know!

Reply 3 of 15, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

I decided it was impolite for me to require you to download the dosbox source code by yourself, so I added an option in the script to download it for you. I've edited the first post to reflect this change. Remember that if you don't want this script to use ~/Development/dosbox for its code and building, change the variable at the top of the script.

Last edited by emendelson on 2016-05-15, 17:20. Edited 1 time in total.

Reply 4 of 15, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

The static linking patch is only needed if you want to build for other machines as well (except for the cursed curses 😉).

Mr.Bigmouth - I was thinking about that as well.
For starters, you would need to get rid of "-arch i386" only Apple's gcc/clang knows about that, "m32" is the correct thing to use on linux, I think.
Further you probably need to build more dependencies yourself. OS X provides universal frameworks and libraries (iconv, ...), which may be needed for a 32bit build. Since Linux don't (usually) do that by default, you will need to build more.
If you don't care about 32bit (but you should, and I know you are aware of why 😉) then it is much easier. You could just apt-get the libraries and their devel packages and then grab Dosbox for compiling.

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 5 of 15, by mr_bigmouth_502

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote:
The static linking patch is only needed if you want to build for other machines as well (except for the cursed curses ;)). […]
Show full quote

The static linking patch is only needed if you want to build for other machines as well (except for the cursed curses 😉).

Mr.Bigmouth - I was thinking about that as well.
For starters, you would need to get rid of "-arch i386" only Apple's gcc/clang knows about that, "m32" is the correct thing to use on linux, I think.
Further you probably need to build more dependencies yourself. OS X provides universal frameworks and libraries (iconv, ...), which may be needed for a 32bit build. Since Linux don't (usually) do that by default, you will need to build more.
If you don't care about 32bit (but you should, and I know you are aware of why 😉) then it is much easier. You could just apt-get the libraries and their devel packages and then grab Dosbox for compiling.

In my case it would actually be "pacman -S" instead of "apt-get" as I'm on Manjaro. 😉 When it comes to getting 32-bit libraries, it's still kind of hit or miss, but it's easier on here than it was on Ubuntu.

Reply 7 of 15, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

And now I've improved the script so that it prompts you to install Xcode and the Xcode command-line tools. If they're not already installed. I've tested the script on a new, clean El Capitan system, and it works perfectly.

Reply 8 of 15, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

And now you are becoming more and more like a package manager 😉

You should use github, btw, to version control your script.

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 9 of 15, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote:

You should use github, btw, to version control your script.

You mean, like this?

https://github.com/emendelson/OneStopDOSBoxOSX

Or, more directly, like this?

https://github.com/emendelson/OneStopDOSBoxOS … topDOSBoxOSX.sh

😉

Reply 10 of 15, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Yeah 😉

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 11 of 15, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

Quick update. Wengier Wu has updated his LFN-and-clipboard-enabled source code and it now compiles and runs perfectly under OS X. This is a major improvement; many thanks to Wengier.

Reply 12 of 15, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

I've now revised the script (at the Github link in the first post) so that it does the following:

1. You can launch it with a folder name as the parameter (or with a single dot as a parameter to indicate the current directory), and it will offer to download and build dosbox into that folder (and create the folder if it doesn't exist). You can still modify the default folder setting in a line near the top of the script itself.

2. If you launch it with the command-line parameter "uninstall" (no quotation marks) it will offer to uninstall the various libraries that it installed earlier. The one exception to the uninstalling routine is libtool, which I haven't figured out how to uninstall cleanly; but you can go to $HOME/Development/libtool-2.4.6 and run "make uninstall'" to get partial results. But there's no special reason to uninstall libtool, as far as I know.

Reply 13 of 15, by Darklord42

User metadata
Rank Newbie
Rank
Newbie

If I were to do this, I would strongly recommend a package manger like macports. (In fact, I would only recommend macports. Fink is never up to date, and homebrew's philosophies of combining gnu tools with apple's right on top of each other is fool hardy at best). How else are you going to make sure all these libraries you are throwing on your system are continually up to date, or make it easy to remove if you need to clean your hard drive without blowing up your system, should that time come? At least install libraries in a prefix folder somewhere away from the rest of the system...

Reply 14 of 15, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie
Darklord42 wrote:

If I were to do this, I would strongly recommend a package manger like macports. (In fact, I would only recommend macports. Fink is never up to date, and homebrew's philosophies of combining gnu tools with apple's right on top of each other is fool hardy at best). How else are you going to make sure all these libraries you are throwing on your system are continually up to date, or make it easy to remove if you need to clean your hard drive without blowing up your system, should that time come? At least install libraries in a prefix folder somewhere away from the rest of the system...

This is partly an experiment in working without MacPorts, etc. And, other than that, I do EXACTLY what you suggest: all the libraries are installed in a prefix folder (~/Development/i386) and the script will offer to uninstall the libraries (one by one) if you start it with the parameter "uninstall" (or "-u"). The version at GitHub is completely updated from the one posted in the first post, and probably I should delete the code in the first post now.