VOGONS


Compile SVN in macOS?

Topic actions

Reply 80 of 172, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

Further progress. I've got my script to the point where it builds DOSBox. The next step is to add the dylibbundler routine to make a portable app bundle, and then clean things up a bit, and add an option to build your own customized code. A thousand thanks to Dominus and to Almeath.

Reply 81 of 172, by almeath

User metadata
Rank Member
Rank
Member
emendelson wrote on 2021-03-11, 04:08:

Further progress. I've got my script to the point where it builds DOSBox. The next step is to add the dylibbundler routine to make a portable app bundle, and then clean things up a bit, and add an option to build your own customized code. A thousand thanks to Dominus and to Almeath.

You are very welcome, and thanks for your hard work on this script .. I am very inexperienced with scripting so I must admit most of this thread is incomprehensible to me. 😉

On the subject of the dylib bundler, I noticed in my own custom app wrapper, try as I might I just cannot get the OpenGlide and its dependent SDL 1.2.0 dylib working entirely within the bundle. I used the correct commands based on the dylibbundler Github site. What I get is the otool -L command telling me that all the dependencies are correctly pointing within the bundle, but when I look in Activity Monitor, the OpenGlide dylib is insisting on accessing SDL 1.2.0.dylib from the usr/local/cellar location. If I remove the original at the system level, the .ini files are not generated within the wrapper, meaning it cannot find SDL 1.2.0 (despite it being there in the wrapper as well). Again, the otool output indicates that this should not be happening. Very odd.

If either you or Dominus get to the stage of testing out my OpenGlide fork, I was hoping you could try to re-create the problem I am experiencing here. It is as if the OpenGlide dylibs are not respecting what the dylib bundler is doing to the files, despite the apparent otool verification of the results. I am stumped. It means my wrapper is self contained, except for OpenGlide at this point in time.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 82 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I'll take a look later today, it intrigues me 😉

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 83 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Can you attach the bundle in a zip, too? So I can maybe figure out what's wrong even if my building should wotk?

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 84 of 172, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

@Almeath, one thought: is it possible that brew is causing this problem, that the bundler can't find some libraries installed by brew? Thanks to Dominus, I was able to make my script run in a brew-free environment. The only thing I had to give up was svn, which was more trouble than it was worth to install (though maybe Dominus has advice on that too...).

Reply 85 of 172, by almeath

User metadata
Rank Member
Rank
Member
Dominus wrote on 2021-03-11, 13:02:

Can you attach the bundle in a zip, too? So I can maybe figure out what's wrong even if my building should wotk?

Sure, here you go:

https://www.dropbox.com/s/51ni2k0d2wlis4k/DOS … rapper.zip?dl=0

I tested it on my Mojave build system and on a separate MacBook Pro with Big Sur, and got the same results.

When SDL 1.2.x is installed via Homebrew under usr/local/Cellar, I see this output in Activity Monitor for the DOSBox binary:

/System/Library/Extensions/AppleHDA.kext/Contents/PlugIns/AppleHDAHALPlugIn.bundle/Contents/MacOS/AppleHDAHALPlugIn
txt
/System/Library/Extensions/AMDRadeonX5000GLDriver.bundle/Contents/MacOS/AMDRadeonX5000GLDriver
txt
/Library/Application Support/CrashReporter/SubmitDiagInfo.domains
txt
/usr/local/Cellar/sdl/1.2.15_3/lib/libSDL-1.2.0.dylib
txt
/private/var/folders/wt/4_d6jnsn60l1lph310tnt0r00000gr/0/com.apple.LaunchServices-231-v2.csstore
txt
/System/Library/Components/CoreAudio.component/Contents/MacOS/CoreAudio
txt
/System/Library/Components/CoreAudio.component/Contents/Resources/gs_instruments.dls
txt
/Users/almeath/Desktop/DOSBox SVN 4441 wrapper.app/Contents/Resources/libglide2x.0.dylib

And yet here is the otool output on the binary:

/Users/almeath/Desktop/DOSBox SVN 4441 wrapper.app/Contents/Resources/dosbox/DOSBox:
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 50.1.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 158.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 492.0.0)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/CoreMIDI.framework/Versions/A/CoreMIDI (compatibility version 1.0.0, current version 69.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1671.60.107)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1575.17.0)
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1265.9.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 946.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1575.17.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

And the OpenGlide dylib:

/Users/almeath/Desktop/DOSBox SVN 4441 wrapper.app/Contents/Resources/libglide2x.0.dylib:
/Users/almeath/Desktop/DOSBox.app/Contents/Resources/libglide2x.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/Users/almeath/Desktop/DOSBox.app/Contents/Resources/libSDL-1.2.0.dylib (compatibility version 12.0.0, current version 12.4.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1)

And SDL 1.2.0 dylib:

/Users/almeath/Desktop/DOSBox SVN 4441 wrapper.app/Contents/Resources/libSDL-1.2.0.dylib:
/Users/almeath/Desktop/DOSBox.app/Contents/Resources/libSDL-1.2.0.dylib (compatibility version 12.0.0, current version 12.4.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 52.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 162.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1000.0.0)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1894.10.126)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1673.126.0)
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1348.12.4)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1069.11.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1673.126.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
Last edited by almeath on 2021-03-11, 13:34. Edited 1 time in total.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 86 of 172, by almeath

User metadata
Rank Member
Rank
Member
emendelson wrote on 2021-03-11, 13:25:

@Almeath, one thought: is it possible that brew is causing this problem, that the bundler can't find some libraries installed by brew? Thanks to Dominus, I was able to make my script run in a brew-free environment. The only thing I had to give up was svn, which was more trouble than it was worth to install (though maybe Dominus has advice on that too...).

It is possible.. I list SDL1 as a dependency for my OpenGlide fork, so anyone who follows those instructions will have it installed via Homebrew... I have not checked if the instructions will work without it.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 87 of 172, by almeath

User metadata
Rank Member
Rank
Member

I have gone back and noticed that the ./bootstrap command for the OpenGlide source produces an error about a missing "sdl.m4", however configure and make commands still succeed despite this.

aclocal: error: aclocal: file '/usr/local/share/aclocal/sdl.m4' does not exist glibtoolize: putting auxiliary files in '.'. glib […]
Show full quote

aclocal: error: aclocal: file '/usr/local/share/aclocal/sdl.m4' does not exist
glibtoolize: putting auxiliary files in '.'.
glibtoolize: copying file './ltmain.sh'
glibtoolize: You should add the contents of the following files to 'aclocal.m4':
glibtoolize: '/usr/local/Cellar/libtool/2.4.6_2/share/aclocal/libtool.m4'
glibtoolize: '/usr/local/Cellar/libtool/2.4.6_2/share/aclocal/ltoptions.m4'
glibtoolize: '/usr/local/Cellar/libtool/2.4.6_2/share/aclocal/ltsugar.m4'
glibtoolize: '/usr/local/Cellar/libtool/2.4.6_2/share/aclocal/ltversion.m4'
glibtoolize: '/usr/local/Cellar/libtool/2.4.6_2/share/aclocal/lt~obsolete.m4'
glibtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
glibtoolize: and rerunning glibtoolize and aclocal.
glibtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoheader: error: AC_CONFIG_HEADERS not found in configure.ac
configure.ac: error: no proper invocation of AM_INIT_AUTOMAKE was found.
configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE,
configure.ac: that aclocal.m4 is present in the top-level directory,
configure.ac: and that aclocal.m4 was recently regenerated (using aclocal)
configure.ac:16: installing './config.guess'
configure.ac:16: installing './config.sub'
Makefile.am:11: error: Libtool library used but 'LIBTOOL' is undefined
Makefile.am:11: The usual way to define 'LIBTOOL' is to add 'LT_INIT'
Makefile.am:11: to 'configure.ac' and run 'aclocal' and 'autoconf' again.
Makefile.am:11: If 'LT_INIT' is in 'configure.ac', make sure
Makefile.am:11: its definition is in aclocal's search path.
Makefile.am: installing './depcomp'
/usr/local/share/automake-1.15/am/depend2.am: error: am__fastdepCXX does not appear in AM_CONDITIONAL
/usr/local/share/automake-1.15/am/depend2.am: The usual way to define 'am__fastdepCXX' is to add 'AC_PROG_CXX'
/usr/local/share/automake-1.15/am/depend2.am: to 'configure.ac' and run 'aclocal' and 'autoconf' again
/usr/local/share/automake-1.15/am/depend2.am: error: AMDEP does not appear in AM_CONDITIONAL
/usr/local/share/automake-1.15/am/depend2.am: The usual way to define 'AMDEP' is to add one of the compiler tests
/usr/local/share/automake-1.15/am/depend2.am: AC_PROG_CC, AC_PROG_CXX, AC_PROG_OBJC, AC_PROG_OBJCXX,
/usr/local/share/automake-1.15/am/depend2.am: AM_PROG_AS, AM_PROG_GCJ, AM_PROG_UPC
/usr/local/share/automake-1.15/am/depend2.am: to 'configure.ac' and run 'aclocal' and 'autoconf' again
platform/linux/Makefile.am:4: error: Libtool library used but 'LIBTOOL' is undefined
platform/linux/Makefile.am:4: The usual way to define 'LIBTOOL' is to add 'LT_INIT'
platform/linux/Makefile.am:4: to 'configure.ac' and run 'aclocal' and 'autoconf' again.
platform/linux/Makefile.am:4: If 'LT_INIT' is in 'configure.ac', make sure
platform/linux/Makefile.am:4: its definition is in aclocal's search path.
platform/sdl/Makefile.am:4: error: Libtool library used but 'LIBTOOL' is undefined
platform/sdl/Makefile.am:4: The usual way to define 'LIBTOOL' is to add 'LT_INIT'
platform/sdl/Makefile.am:4: to 'configure.ac' and run 'aclocal' and 'autoconf' again.
platform/sdl/Makefile.am:4: If 'LT_INIT' is in 'configure.ac', make sure
platform/sdl/Makefile.am:4: its definition is in aclocal's search path.
platform/windows/Makefile.am:4: error: Libtool library used but 'LIBTOOL' is undefined
platform/windows/Makefile.am:4: The usual way to define 'LIBTOOL' is to add 'LT_INIT'
platform/windows/Makefile.am:4: to 'configure.ac' and run 'aclocal' and 'autoconf' again.
platform/windows/Makefile.am:4: If 'LT_INIT' is in 'configure.ac', make sure
platform/windows/Makefile.am:4: its definition is in aclocal's search path.
configure.ac:8: error: possibly undefined macro: AM_CONFIG_HEADER
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:18: error: possibly undefined macro: AM_INIT_AUTOMAKE
configure.ac:24: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
configure.ac:25: error: possibly undefined macro: AC_PROG_LIBTOOL
configure.ac:39: error: possibly undefined macro: AM_PATH_SDL

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 88 of 172, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

@Dominus - Question: do you know of any way to avoid that Big Sur message asking us to open System Preferences in order to give DOSBox access to keystrokes from any application? I've seen discussions of this elsewhere, but haven't seen a solution.

And I've now got my script building the portable app. Will post probably tomorrow when I have some time free.

Reply 89 of 172, by almeath

User metadata
Rank Member
Rank
Member

Actually, ignore my message above about the bootstrap error ; I was placing SDL in the wrong place after temporarily removing it to perform a test...whoops.

The bootstrap command will work properly when SDL is in the Hombrew cellar location.

The configure command then contains these references:

checking for sdl-config... /usr/local/bin/sdl-config
checking for SDL - version >= 1.2.0... yes

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 90 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

@emendelson: the keyboard access security question:

No, that's another SDL 1.2 issue. They fixed it for SDL2 but that fix is not applicable at all for SDL 1.2 (unless Dosbox-x has a fix in its SDL 1.2 fork).

And no, I have no easy solution for getting SVN other than a package manager. Hency why I put an alias into my zsh environment to call the macports svn even if macports is not in the path.

Last edited by Dominus on 2021-03-11, 14:06. Edited 1 time in total.

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 91 of 172, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

For the purposes of my script, it's enough simply to download the current code instead of using SVN - I'm assuming that if you're using this script you've got a fast enough connection to download the code quickly enough.

My todo list: Add an option to run your own patch file on downloaded code.

Almeath, I basically know nothing about scripting - I simply use bits of code that I found on the web, and combine those with advice from Dominus. My script is fairly heavily commented, so when I post it on Github, I think you'll have no trouble adding your own customizations. I'll be happy to test and to make suggestions to the extent that I understand anything that my script does!

Reply 92 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator
almeath wrote on 2021-03-11, 12:48:
You are very welcome, and thanks for your hard work on this script .. I am very inexperienced with scripting so I must admit mos […]
Show full quote
emendelson wrote on 2021-03-11, 04:08:

Further progress. I've got my script to the point where it builds DOSBox. The next step is to add the dylibbundler routine to make a portable app bundle, and then clean things up a bit, and add an option to build your own customized code. A thousand thanks to Dominus and to Almeath.

You are very welcome, and thanks for your hard work on this script .. I am very inexperienced with scripting so I must admit most of this thread is incomprehensible to me. 😉

On the subject of the dylib bundler, I noticed in my own custom app wrapper, try as I might I just cannot get the OpenGlide and its dependent SDL 1.2.0 dylib working entirely within the bundle. I used the correct commands based on the dylibbundler Github site. What I get is the otool -L command telling me that all the dependencies are correctly pointing within the bundle, but when I look in Activity Monitor, the OpenGlide dylib is insisting on accessing SDL 1.2.0.dylib from the usr/local/cellar location. If I remove the original at the system level, the .ini files are not generated within the wrapper, meaning it cannot find SDL 1.2.0 (despite it being there in the wrapper as well). Again, the otool output indicates that this should not be happening. Very odd.

If either you or Dominus get to the stage of testing out my OpenGlide fork, I was hoping you could try to re-create the problem I am experiencing here. It is as if the OpenGlide dylibs are not respecting what the dylib bundler is doing to the files, despite the apparent otool verification of the results. I am stumped. It means my wrapper is self contained, except for OpenGlide at this point in time.

Ok, I see two problems with your wrapper:
- you are still static compiling sdl into your dosbox binary (as you can see in the otool -L of the binary). That it even uses the glide library is a big question, I guess I'd need to test with a glide game.
- you are using hardcoded paths and not relative paths for the bundling of the dylibs (/Users/adammeath/Desktop/DOSBox.app/Contents/Resources/libglide2x.0.dylib <- that's what I get here from otool -L)

So you need to abandon the static compiling (so no more patching the makefile to replace the dynamic loading with the static library , for example -lzlib with the path to libz.a) and then use

dylibbundler -od -b -x ./dosbox.app/contents/resources/dosbox/dosbox -d ./dosbox.app/contents/resources/lib -p @executable_path/../lib

This will put the files in a lib sub folder of the Resources folder (as it is better to put them all in one folder way from everything else - dylibbundler has the option to create and first delete the destination folder which *I* prefer in my scripts).
(named it dosbox.app to not have to muck around with spaces in the folder name for ease of use 😀)

If you don't plan to codesign it, get rid of the _codesignature folder.

But I'll need to check with a build of my own as well, there is something off with the dosbox binary. It references only once libglide2x.dylib but without it showing up in otool (only by hex examining it).

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 93 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

ugh... now I see... the glide patch is ugly...
it uses the lib by running this in the code...

#elif defined(MACOSX)
hdll = dlopen("libglide2x.dylib", RTLD_NOW);
#else

Phew... I'll need to see how to handle this... it's ugly...

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 94 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

so for testing, can you refresh my memory? how do I enable openglide, for, say, Tomb Raider?
I may just have to do some configure stuff so it links against the dynamic library

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 95 of 172, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

The script seems to be working for building a portable DOSBox SVN. Until I get to set up a GitHub version, here's a link:

https://www.dropbox.com/s/28jbyukicfaokhf/One … oxMacOS.sh?dl=0

Of course look into the script to see the variables at the top and change them if required. The default is to create a folder named ~/DBBuild and put everything inside that, but you may want something different. After testing, of course simply delete that whole folder if you want.

EDIT: Of course it still produces the SDL problem of tiny type unless you change the output to surface. So this is not for real world use yet.

Reply 96 of 172, by almeath

User metadata
Rank Member
Rank
Member
Dominus wrote on 2021-03-11, 17:07:

so for testing, can you refresh my memory? how do I enable openglide, for, say, Tomb Raider?
I may just have to do some configure stuff so it links against the dynamic library

I really appreciate you looking into this. Yes, I figured the issue was something specific to the OpenGlide source, but I am not savvy enough with the coding to figure it out. It was a battle just to get it to build at all, as I had to basically reverse a number of source patches dating to October last year, among other changes. All I can say is that the Glide wrapper functionality is definitely working for me.

The only game I have tested extensively is Lands of Lore 2, which exhibits the same behavior in SVN and DOSBox-X (i.e. there are glitches, but it looks like those are issues inherent to OpenGlide). The correct ini and log files are generated by the wrapper (already included in my app package) and changing settings in there functions as expected (i.e. full screen vs. windowed mode, increasing memory etc.).

In Lands of Lore 2, Glide is automatically detected when you go to the in-game video options menu. If the wrapper is functioning, the 'hardware acceleration' menu shows up (otherwise it is not in the list at all). Unfortunately I do not have the Tomb Raider game. Is there a shareware version I can test on?

My testing experience is documented here:

https://github.com/joncampbell123/dosbox-x/issues/2314

With SVN the only difference I found is that upon quitting the game, DOSBox-X will exit cleanly, whereas SVN will hang with a black screen without returning to the Mac desktop, so it requires switching to a second desktop with Mission Control and then quitting DOSBox from the Dock.

Last edited by almeath on 2021-03-11, 21:20. Edited 2 times in total.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 97 of 172, by almeath

User metadata
Rank Member
Rank
Member
Dominus wrote on 2021-03-11, 17:03:
ugh... now I see... the glide patch is ugly... it uses the lib by running this in the code... […]
Show full quote

ugh... now I see... the glide patch is ugly...
it uses the lib by running this in the code...

#elif defined(MACOSX)
hdll = dlopen("libglide2x.dylib", RTLD_NOW);
#else

Phew... I'll need to see how to handle this... it's ugly...

Oh I see .. at least I know I wasn't making any mistakes with the dylib bundler.

So that means it would still be OK for me to continue with static builds, and the issue requires a patch to the source? Or use of OpenGlide as a bundled dylib will require the rest of the dependencies being similarly bundled as dylibs vs. being built into the binary? In other words, a hybrid solution is not practical? I suppose bundling dylibs makes more sense from the perspective of not having to fiddle around with manual make file patching.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 98 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

If it works, continue like this. But I may take more shots at it and may be able to fix the loading of the openglide lib.
Since two weeks ago, I was a strong believer in static building but now I finally gave in and believe dynamic is better.

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 99 of 172, by almeath

User metadata
Rank Member
Rank
Member

What was the main factor in that decision? A simpler build process? More flexibility?

If you do have time to look into the glide code, that’s great, and I will help where I can, at least with testing.

In the meantime, I think I might modify my instructions to recommending that while glide functionality is supported by the app, the first step will be to install OpenGlide at the OS level using the instructions on my GitHub page, which are validated up to Big Sur.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS