emendelson wrote on 2021-03-07, 16:03:

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...

Good luck with the scripting .. seems we have had some breakthroughs. As mentioned, I would be happy to revise my approach on the Github page if you want to collaborate. In the meantime, I think most people will probably just download the pre-built app I created.

If I follow the advice of Dominus and switch to including dylibs in the application package, then it will be pretty easy for me to maintain. The hardest work will be continuing my quest to incorporate more patches that do not play nice with macOS. At the moment the 3dfx emulation patch is giving me a headache.. 😀

I'll keep trying , but I've already bumped into some major problems, which I haven't been able to solve simply by creating the directories that Dominus's script expects. If I can make any progress, then I'll be glad to collaborate, but I'm not completely hopeful at the moment!

Just another heads up, as Apple pestered me I switched to zsh shell and changed my scripts accordingly.
If you have done so as well, there are likely some things you need to change in your scripts as well.

I've been using zsh as the default. Will report more when I've figured out what some of the problems are...!

@almeath and @dominus - First, Dominus: I have a 2015 MacBookAir and a 2015 MacBook Pro, both running Big Sur. On the Air, I gave up and installed Brew. Almeath, I followed your guide and built SVN successfully - after I figured out the one essential step of using svn to download the SVN code.

Dominus, I used dylibbuilder to move the libraries into the app, and that worked perfectly also. Thank you!

Two problems:

1. The executable that I made runs only under Big Sur. I'll have to study Dominus's buildbot to figure out how to target earlier versions, because I want to distribute the result.

2. Everything looks good on the non-retina Air, but when I launched the app on the retina MacBook Pro, the text was tiny, in the lower left of the window. EDIT: The fix for this is to specify output=surface (possibly other options too, but I didn't test them).

Also, there's a minor typo in almeath's guide, step 6 - HOME should read $HOME

Thank you both for this terrific work!

Further update. I entered this command at the terminal in Big Sur:

export MACOSX_DEPLOYMENT_TARGET=10.12

(For my project, I don't need anything older than 10.12.) I then built libpng from source (after uninstalling it from brew) and built SDL from source., following Almeath's guide. I think built SVN, using Almeath's guide, and used Dominus's dylibbuilder command to put the external libraries into an app bundle.

The resulting app runs successfully in 10.12 and later, though built in Big Sur.

This is terrific progress. I'll try to write a single script for all this, which will (for better or worse) rely on brew. I wish I didn't have to use it, but I simply can't build some of the things that I installed via brew.

emendelson wrote on 2021-03-08, 00:29:

Also, there's a minor typo in almeath's guide, step 6 - HOME should read $HOME

Thank you both for this terrific work!

Fixed.

I am happy to have helped, and I look forward to the final result.

I presume the script will be designed to work as far back as at least Mojave? And it would support building off a patched SVN source like the one I have posted? I will keep maintaining and offering my own manual self-contained app, but it would be great to offer an option for a one-click build of a 'standard' app bundle.

I am too old school to like Apple's sandbox policy of having apps spew all their support files into my documents folder and around the system.. I know its a security thing, but I want the choice to have things neatly wrapped up in one place, so that when I move the app, I know I am taking all its content and dependencies along with it. The other option would be to develop something like the approach Boxer took, which was to allow the creation of self-contained "bundles", which would contain everything except the underlying app. So you could create a library of self-contained games, but only have one copy of the app rather than many individual copies that would have to be individually updated.

@emendelson: it's all strange. I've built everything I need on Big Sur without brew. I'll post my steps here (without my elaborate scripting 😉).
You really really need to do it without brew OR find out if you can set the deployment target in brew as well.
Otherwise having some libs only with Big Sur deployment and onthers for older macOS *will* eventually bite you in the ass.

1dependencies:
2Automake: autoconf
3libpng: zlib
4libogg
5libvorbis: pkgconfig, libogg
6libsdl_net: pkgconfig, libsdl
7libsdl_sound: libsdl, libvorbis, libogg
8
9Create folder /opt/x86_64 (or some other but then you need to replace it in the environment and the configure --prefix switch)
10Environment:
11OPT=' -O2 -m64 -msse -msse2 '
12SDK=' -mmacosx-version-min=10.10'
13export MACOSX_DEPLOYMENT_TARGET=10.10
14export PATH=/opt/x86_64/bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
15export CC="/usr/bin/clang"
16export CXX="/usr/bin/clang++"
17export CPPFLAGS='-I/opt/x86_64/include '$SDK
18export CFLAGS='-I/opt/x86_64/include '$SDK' '$OPT
19export CXXFLAGS='-I/opt/x86_64/include '$SDK' '$OPT
20export LDFLAGS='-L/opt/x86_64/lib '$SDK' '$OPT
21export PKG_CONFIG_PATH="/opt/x86_64/lib/pkgconfig"
22export PKG_CONFIG=/opt/x86_64/bin/pkg-config
23
24
25Minimal needed programs and libs with configure args:
26autoconf
27automake
28libtool ARGS='F77=no FC=no GCJ=no --program-prefix=g'
29pkgconfig ARGS='--with-pc-path=/opt/arm64/lib/pkgconfig:/opt/x86_64/share/pkgconfig --with-internal-glib --disable-silent-rules --disable-host-tool'
30zlib
31libpng
32libogg
33libvorbis
34SDL (latest git from https://github.com/libsdl-org/SDL-1.2) ARGS='--enable-static --enable-joystick --enable-video-cocoa --enable-video-opengl --disable-video-x11 --without-x --disable-nasm'
35SDL_sound ARGS='--disable-mikmod --disable-modplug --disable-flac --disable-speex --disable-physfs --disable-smpeg --disable-sdltest'
36
37SDL_net <- this one is problematic, it might need to be build against SDK 10.14 because SDK 10.15+ add darwin_check...overflow and that wreaks havoc. It might only be a problem for static building not dynamic one.
38Put the SDK 10.14 somewhere if you still have it (it may be in /Library/developer/CommandLineTools/SDKs).
39Change the environment SDK to SDK=' -isysroot /Library/developer/CommandLineTools/SDKs/MacOSX10.14.sdk -mmacosx-version-min=10.10' and then r.erun the other environment exports that make use of $SDK.
40
41
42Almost all of those packages do not need you to run ./autogen.sh, just run configure with the ARGS I listed  and the prefix switch and you should be good. If there is no configure, run ./autogen.sh.
43
44./configure --prefix=/opt/x86_64 ${=ARGS}
45make -j9 -s
46make install

that's the barebone, manual way to do it. If this works, you can begin scripting it. But mind that zsh is slightly different. Some variables will need to be passed differently or programs will not understand (for example see that I used ${=ARGS} instead of $ARGS for the configure line).

Just an FYI for anyone interested - I have successfully applied the 3dfx emulation patch to my SVN build and will update Github shortly.

The current list of patches is now:

- Munt
- Glide (with bundled OpenGlide)
- 3dfx Voodoo emulation (SDL1)
- Nuked OPL3
- 384 ram limit
- 8GB img file support

I will keep going I'm sure, as I seem to be on a roll..

Whee! nice!

@Dominus, you are absolutely right that I shouldn't be using brew. I'll try your method (later this week) and will try to remove brew when I've got it working. Question: you say that zsh requires different methods; I'm already using zsh as my default script, and your method uses zsh also, correct? So I don't need to change anything that you've posted, because we're both using zsh? (Just making certain that I'm not misinterpreting you.)

EDIT: I just tried building automake with your exports, and it worked perfectly! So I'm confident that the others will work also. This removes an enormous amount of frustration.

@Almeath, yes, I mostly want to use this script to build my own patched code (which is what I used to do with a modified version of my OneStopDOSBoxOSX.sh script). So I'll include an option to use customized code instead of SVN. But this won't get done for at least a week, maybe more.

Yes, my script stuff should work with zsh now. Of course sometimes something creeps in 😉

@Dominus - I took a few minutes over coffee to instal libpng and zlib with your options, and of course they worked. My current problem is with libvorbis. I can't reach the web site now, but I had earlier downloaded 1.3.7. ./configure works properly with your options, but make produces these errors:

1In file included from /opt/x86_64/include/ogg/ogg.h:24:
2/opt/x86_64/include/ogg/os_types.h:75:12: error: unknown type name 'uint16_t'
3   typedef uint16_t ogg_uint16_t;
4           ^
5/opt/x86_64/include/ogg/os_types.h:77:12: error: unknown type name 'uint32_t'
6   typedef uint32_t ogg_uint32_t;
7           ^
8/opt/x86_64/include/ogg/os_types.h:79:12: error: unknown type name 'uint64_t'
9   typedef uint64_t ogg_uint64_t;
10           ^

I can't pretend to understand what's wrong here. Have you any insights?

EDIT: This seems to be related problem, but I can't see how to solve it:

https://trac.macports.org/ticket/58924

Also this, but I can't see exactly which file to change:

https://gitlab.xiph.org/xiph/ogg/-/issues/2298

right, sorry, my bad. I always take a look at the patches done by macports.
change include/ogg/os_types.h line 70

1diff --git include/ogg/os_types.h include/ogg/os_types.h
2index 4165bce..eb8a322 100644
3--- include/ogg/os_types.h
4+++ include/ogg/os_types.h
5@@ -70,7 +70,7 @@
6 
7 #elif (defined(__APPLE__) && defined(__MACH__)) /* MacOS X Framework build */
8 
9-#  include <sys/types.h>
10+#  include <inttypes.h>
11    typedef int16_t ogg_int16_t;
12    typedef uint16_t ogg_uint16_t;
13    typedef int32_t ogg_int32_t;

Aha! That worked - after I configured and made and make installed libogg. Thank you!

@Dominus - making progress here. One quick question: Back in the past you used this arg for configure with libvorbis: --disable-oggtest

Is that still needed??

Otherwise, I'm making progress adapting my old script to zsh and the other changes.

You can still use that arg, it might make configure run a second faster 😉
It's just performing some test and I prefer to have less clutter, but probably just takes no time at all.

almeath wrote on 2021-03-08, 10:23:

Just an FYI for anyone interested - I have successfully applied the 3dfx emulation patch to my SVN build and will update Github […]
Show full quote

Just an FYI for anyone interested - I have successfully applied the 3dfx emulation patch to my SVN build and will update Github shortly.

The current list of patches is now:

- Munt
- Glide (with bundled OpenGlide)
- 3dfx Voodoo emulation (SDL1)
- Nuked OPL3
- 384 ram limit
- 8GB img file support

I will keep going I'm sure, as I seem to be on a roll..

For the last two, I think you can also try to use the patches in DOSBox-X in your builds, as the large memory and image file support have been extended much further in DOSBox-X. For example, with the FAT32 patch in DOSBox-X image files up to 2TB can be supported, both formatted and unformatted.

emendelson wrote on 2021-03-08, 02:12:

Further update. I entered this command at the terminal in Big Sur: […]
Show full quote

Further update. I entered this command at the terminal in Big Sur:

export MACOSX_DEPLOYMENT_TARGET=10.12

(For my project, I don't need anything older than 10.12.) I then built libpng from source (after uninstalling it from brew) and built SDL from source., following Almeath's guide. I think built SVN, using Almeath's guide, and used Dominus's dylibbuilder command to put the external libraries into an app bundle.

The resulting app runs successfully in 10.12 and later, though built in Big Sur.

This is terrific progress. I'll try to write a single script for all this, which will (for better or worse) rely on brew. I wish I didn't have to use it, but I simply can't build some of the things that I installed via brew.

Glad to know you eventually got it to work, which is great. Congratulations.