emendelson wrote on 2021-03-06, 18:37:

EDIT: I've been trying to update my old build script, but I can't build libtool or anything else because I get the error "configure: error: C compiler cannot create executables". This seems to be fairly standard under Catalina and Big Sur, and no one has a solution that works, as far as I can see. I'll try doing this under Mojave, and will then come back to Big Sur.

@emendelson, I am not sure what is happening there, but I successfully compiled on Big Sur yesterday, using my above instructions.

You will see I have just added the static binary instructions. This is not something I intend to provide on the Github site, where I think most people will be fine to either compile their own system-specific build, or download the fully compiled app package which I will include shortly.

I will be interested to hear how this goes for you.

This is just terrific. Thank you. I'll continue to experiment with a script, though I may have to give up and install brew if libtool etc. refuse to get built under Big Sur.

emendelson wrote on 2021-03-07, 00:30:

This is just terrific. Thank you. I'll continue to experiment with a script, though I may have to give up and install brew if libtool etc. refuse to get built under Big Sur.

I am happy to know that almost a year of "blood, sweat and tears" (and bothering @Dominus) was worth it! 😉

I will continue to look at integrating further patches in my Github repository, and post updates here if successful.

.. I will also look into this libtool issue you have mentioned. One of the many reasons I have stayed on Mojave is my fear that such things would break and not have a work-around.

My 2015 MacBook Pro dual-boots to Mojave and Big Sur, and I'll give it a try in Mojave...

The "configure" error occurs with everything I try to install other than autoconf and automake. I'm not alone in finding this problem, which seems to have emerged in Catalina.

emendelson wrote on 2021-03-07, 00:41:

The "configure" error occurs with everything I try to install other than autoconf and automake. I'm not alone in finding this problem, which seems to have emerged in Catalina.

I suspect it could be something to do with the "sealed system volume" and symlinks etc. that started to be introduced in Catalina and then went even further in Big Sur.. possibly it creates persmissions related issues?

Perhaps you should download the DOSBox-X source on Github and take a look in there, as there could be some macOS build scripts that resolve the issue? I know that X varies quite substantially from SVN, but if they solved how to make a one-click script for Mojave through Catalina, then it might shed some light on a potential solution. The X script even builds SDL1 or SDL2 versions.

ovvldc wrote on 2021-03-03, 17:08:

Happy to see such package to try it out 😉

OK, the pre-built application wrapper is now available and ready to download (too big to attach on Vogons):

https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

See the top of the Read Me for the download link and some notes on features and usage of the wrapper.

As mentioned, I could not include the MT-32 / CM-32L roms for legal reasons, but the notes should help you work it out. If I have run afoul of any copyright or rules on distribution of DOSBox SVN, someone please tell me because I am new to this. As far as I was aware, providing the source code along with the binary is sufficient..

I do not know how many hours I have spent on this project, but it runs into the weeks I am sure.. it would be great to hear what people think of my wrapper. I am also happy to accept feedback for improvements or help with any problems.

Have fun with it!

I haven't read through everything but one important thing:
I'm getting away from building a static one, because of the fickeldy nature of the makefile and stuff being needed for the build.
Instead use dyllibbundler (available under this name in brew, macports). This will bundle everything in your app bundle and fix the paths in the dylibs so they work fine on every other machine(with same or higher version of macOS).
I'll post my script later.

My way of building it is of course a bit different than just using brew as I try to make Dosbox available for a lot of older machines...

Dominus wrote on 2021-03-07, 09:00:

My way of building it is of course a bit different than just using brew as I try to make Dosbox available for a lot of older machines...

Thanks, I will definitely look into that option. I think I might have achieved the same thing manually with my app bundle. It already finds the OpenGlide libraries inside the bundle when they are not present in my system level libraries. So, it might work the same way with all the other components. I will do some testing with the other dylibs. I agree that this approach would be a whole lot easier than the manual editing of make files.

My entire buildbot scripts at https://github.com/DominusExult/buildbot <- it evolved in something complicated but it suits my needs very much:

1. the snapshots.applescript monitors new emails coming in via mail.app, if there is a new commit mail it launches the appropriate script. For DOSBox it is https://github.com/DominusExult/buildbot/blob … sboxsnapshot.sh

2. to not have to maintain the same basic stuff for all the snapshots, I've moved a lot of common things to the functions.sh script that is called on top of the snapshot script. And since I'm doing four arches you get 4 sections.

3. I'm sending as much as possible to /dev/null to get shown as few warnings as possible. Also I've added various checks for errors that tell where it errored.

4. in /tools you have two scripts to filter out the useless "no symbols" warnings on compile. I'm using these by pointing AR and RANLIB at these (export AR=...)

5. I'm also notarizing DOSBox that's why there is codesign and xcrun stuff inside. Disregard this 😀

Anyway, for the dylibbundler create your app bundle (do NOT static compile) and then point dylibbundler at it (like I'm doing https://github.com/DominusExult/buildbot/blob … snapshot.sh#L95 but as I need to maintain three arches I do it in another order)

1dylibbundler -od -b -x DOSBoxSVN.app/Contents/MacOS/dosbox -d  DOSBoxSVN.app/Contents/Resources/lib -p @executable_path/../Resources/lib -i /usr/lib

Note: usually dylibbundler ignores the system libs but the way macOS 11 is storing its libs (*) is confusing dylibbundler so you need to pass the -i /user/lib (--ignore).

*: macOS 11, Big Sur, is virtually providing the libs out of a big cache file, so even though they are linked and made us of at /usr/lib you won't find them in there.

(another note: I needed to keep the static build for the PPC target, because notarizing the app requires that the binaries are build against SDK>= 10.9. The dosbox binary is masked by lipo gluing all arches into one big binary, but the dylibs are there in the open and you can't build for PPc with SDK 10.9 😀)

almeath wrote on 2021-03-07, 09:25:

Dominus wrote on 2021-03-07, 09:00:

My way of building it is of course a bit different than just using brew as I try to make Dosbox available for a lot of older machines...

Thanks, I will definitely look into that option. I think I might have achieved the same thing manually with my app bundle. It already finds the OpenGlide libraries inside the bundle when they are not present in my system level libraries. So, it might work the same way with all the other components. I will do some testing with the other dylibs. I agree that this approach would be a whole lot easier than the manual editing of make files.

yes, you can manually do all that with otool and install_name_tool but the dylibbundler takes care of that, especially as it runs through all dependencies to grab their dependencies, too. Cann all be done manually but... it's a hackle.

This is amazing work, Dominus. Thank you a thousand times. (And it convinced me that it's time to give up on compiling without brew - I can't even get automake to build on Big Sur.)

It's time to take a very deep dive into all this. Thank you yet again!

(I still get everything done without brew, btw)

Dominus wrote on 2021-03-07, 13:18:

(I still get everything done without brew, btw)

This inspires me to keep trying without it...!

I'm willing to lend my eyes 😉
And as I just overthrew my buildbot with yet more complicated things the timing is good as I'm warmed up...
Try with the simple steps without scripting it and we can probably find the culprit.

But here or another thread? 🤷‍♂️

Dominus wrote on 2021-03-07, 13:37:

I'm willing to lend my eyes ;) And as I just overthrew my buildbot with yet more complicated things the timing is good as I'm wa […]
Show full quote

I'm willing to lend my eyes 😉
And as I just overthrew my buildbot with yet more complicated things the timing is good as I'm warmed up...
Try with the simple steps without scripting it and we can probably find the culprit.

But here or another thread? 🤷‍♂️

Another thread seems best, but I'm not sure where. But, with one last try in this thread: I'm trying to start trying to figure out why this script fails in Big Sur when ./configure says "configure: error: The installed version of autoconf does not work." The autoconf versions is 2.71.

1AMVER="1.16.3"
2mkdir -p $HOME/Development/automake-$AMVER
3curl -OL http://ftpmirror.gnu.org/automake/automake-$AMVER.tar.gz
4tar -xzf automake-$AMVER.tar.gz -C $HOME/Development
5rm automake-$AMVER.tar.gz
6cd $HOME/Development/automake-$AMVER
7./configure
8make >/dev/null && sudo make install >/dev/null && make clean >/dev/null 
9echo && echo

The two systems I'm testing were both upgraded to Big Sur from Mojave, and it seems that something changed in Perl that may affect this, but I can't figure out what. Autoconf builds correctly; so does libtool...

First things first: what environment did you set up, what's your prefix, path? Any other install maybe interfering?

UPDATE: Problem solved!

I had stupidly tried to install autoconf 2.71 and automake 1.16.3, thinking (wrongly) that the latest versions would be best.

I removed autoconf 2.71, installed 2.69 instead; then installed automake 1.15, and everything worked perfectly. Apologies for wasting your time!!

No problem, it came just in time, I was about to sit down and try things out.
Welcome to build system hell 😉

I tried installing svn in Big Sur, but decided it was too complicated; I think I use curl to download the latest code for the purposes of my script. Will be trying out your scripts over the next few days, and will report. I'll obviously need to install some stuff before I can make real progress...