VOGONS


Compile SVN in macOS?

Topic actions

Reply 140 of 172, by almeath

User metadata
Rank Member
Rank
Member

The next thing I will start looking at is creating my own custom diff files for all the various patches, so that updating the SVN code base and re-patching will be a quick and easy process from now on.

I am grateful that you got me off the old approach of manually patching make files! 😉

Once emendelson has perfected his script, I will then see if I can build individual patching options into it .. but I am a scripting novice and will probably need some help with that.

Reply 141 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

No problem, we can help you. It's a bit learning by doing anyway (was so for 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 142 of 172, by almeath

User metadata
Rank Member
Rank
Member

I have worked out a quick and easy method to update my repository with the latest SVN source and apply all of the patches in less than 10 minutes. I just need to script it now.

In the meantime, if anyone wants to test out the latest wrapper, the link is in the Read Me:

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

It is based on the latest SVN 4442 source and now includes, Munt, OpenGlide, 3dfx Voodoo, Nuked OPL3, FM volume adjustment, 384mb RAM, Large hard drive images, CGA monochrome, Fluidsynth, 4mb video ram, and patched PC speaker emulation. In a way, I am kind of trying to reverse-engineer DOSBox ECE, as I never could manage to get it to compile directly.

Reply 143 of 172, by almeath

User metadata
Rank Member
Rank
Member

Is anyone running Big Sur 11.2.3?

I just updated today and I cannot get my wrapper to launch. If I run the dosbox binary inside the wrapper, it does launch, but double-clicking the wrapper icon will briefly show the DOSBox launch window, and then it will just quit back to the desktop - no error message. It does not appear to be an Apple security thing as it does at least get to the DOSBox splash screen, which would not occur if Big Sur security features were trying to block it.

This is the direct link to the wrapper:

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

It works perfectly in Mojave, and the Activity Monitor confirms there are no external dependencies.

EDIT - I just ran xattr-cr on the wrapper via Terminal, and now it works. Big Sur is placing quarantine flags on this if it is downloaded or even air dropped from one Mac to another! Anyway, at least it is resolved, but is an annoying extra step. Odd that it gets to the DOSBox splash screen though..

Last edited by almeath on 2021-03-16, 10:31. Edited 1 time in total.

Reply 144 of 172, by almeath

User metadata
Rank Member
Rank
Member

I tried code signing the bundle on my Mojave machine, but even with a valid code signature it will fail to open if I zip it up and download it from Github onto my Big Sur machine. As mentioned above, it even fails without being zipped at all and just copied across with Air Drop.

There must be an easier way to get around this than requiring people to run xattr -cr on my bundle after downloading it? 🙁

Apple keeps insisting that they do not want to mess with the fundamental right to run what we want on our Macs... but they create so many hurdles.

Reply 145 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

yeah, I get the same with your zip 🙁
I think it's because your dosbox binary is not in the .../contents/macos/ folder but somewhere else in the bundle. When I began notarizing my SVN snapshots I found that codesigning the app bundle only codesigns the binary not anything in the other folders (and no, --deep does not help 🙁 ). So run codesign twice more: one by pointing at the dosbox binary directly (not at the folder) and once more by pointing at the libraries (wildcard *.dylib works for that).

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

User metadata
Rank Oldbie
Rank
Oldbie

The app runs perfectly well in Big Sur - but you have to move it out of your Downloads folder and into some other folder before it will run. If you launch it without moving it, macOS won't run it, for security reasons: macOS wants to be sure that you manually did something with it before running it, as a way of showing that some bad actor didn't plant it on your system and launch it. (I didn't write this policy; I'm just reporting it.)

I'm surprised that it doesn't display an error message with "translocation" in it somewhere, because that's what I remember from earlier versions.

Exactly as Dominus says, the app can't be notarized in a straightforward way because of the error "unsealed contents present in the bundle root." I haven't tried Dominus's method, but I used the "SD Notary" app from Late Night Software, and it displayed the "unsealed contents" error.

Reply 147 of 172, by almeath

User metadata
Rank Member
Rank
Member

Yes, I have downloads to my Desktop by default, but I unzipped and moved the app to my User folder, back to Desktop again, and it works. If macOS wants to stick quarantine flags on something there appears to be no way around that. So it is either doing this, or stripping the flags immediately with xattr -cr.

I was able to codesign the app using the terminal command:

codesign --force --deep -s "Apple Development: <my Apple ID and specific key information>"

I used that once for the app, once for the DOSBox binary, and then again for all the dylibs with the *.dylib.

That only works if I first removed the documentation folder from the root of the wrapper. It does not mind all the stuff in resources, but anything next to the Contents folder is apparently forbidden. I put the folder back again after code-signing. Which, of course, would not work for hardening and notarization because that would mean the contents of the app changed, which would break that process.

Also, notarization is pointless for this wrapper, as it is fundamentally at odds with the concept of the wrapper itself. Apple does not want people using apps that have contents that are altered. It wants everything neatly sandboxed and stored in your User folder. I understand the sentiment, but resent the rigidity of the process and lack of clear options to bypass the restrictions if one accepts some basic self responsibility for running their own computer. Anyway, I won't get on my soapbox to further bash Apple's heavy handed security changes, as I probably sound like a broken record. We will never be going back to the Snow Leopard days ..

I will just place some instructions as a Read Me bundled with the app, explaining the translocation thing and how to get around it.

I cannot imagine this kind of thing getting any easier with the Apple Silicon systems..

Reply 148 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Notarization could be done but would need an extra option pointing to an entitlements.plist file (because the bundle executable (the wrapper) starts another binary (dosbox)) and following other guidelines.
I've spent a bit time of getting notarization right for Dosbox and my Exult snapshots (and yes, it's an ugly process of getting things wrong a couple of times).

Why don't you move the docs folder into the contents folder and be done without having to do an extra step.

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

User metadata
Rank Member
Rank
Member
Dominus wrote on 2021-03-16, 12:26:

Notarization could be done but would need an extra option pointing to an entitlements.plist file (because the bundle executable (the wrapper) starts another binary (dosbox)) and following other guidelines.
I've spent a bit time of getting notarization right for Dosbox and my Exult snapshots (and yes, it's an ugly process of getting things wrong a couple of times).

Why don't you move the docs folder into the contents folder and be done without having to do an extra step.

Thanks for trailblazing a path for us on this issue 😉

Yes, I could move it, but then again I do not want or need to codesign the app in the first place (at least for now). That will change if Apple makes code signing compulsory..

The problem of the quarantine flags still exists either way, unfortunately.

Reply 150 of 172, by almeath

User metadata
Rank Member
Rank
Member

I should also add that if I can eventually get a script designed for this (not easy, given the complex structure of the wrapper) then it might be better for my purposes just to let people build their own wrapper, which avoids the transportability issues or the need to eventually pay for a full Apple Developer ID (required for Notarization).

Reply 151 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator
emendelson wrote on 2021-03-16, 12:02:

The app runs perfectly well in Big Sur - but you have to move it out of your Downloads folder and into some other folder before it will run. If you launch it without moving it, macOS won't run it, for security reasons: macOS wants to be sure that you manually did something with it before running it, as a way of showing that some bad actor didn't plant it on your system and launch it. (I didn't write this policy; I'm just reporting it.)

Ah yes, that makes it work fine here without the need for codesigning. One note though, you have to use Finder to move it, not any other file manager. Hence it is good idea to warp the app in a disk image. That should always open in a Finder window.

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

User metadata
Rank Member
Rank
Member
Dominus wrote on 2021-03-16, 12:50:

Ah yes, that makes it work fine here without the need for codesigning. One note though, you have to use Finder to move it, not any other file manager. Hence it is good idea to warp the app in a disk image. That should always open in a Finder window.

Thanks - I put it inside a DMG image.

Reply 153 of 172, by almeath

User metadata
Rank Member
Rank
Member

@emendelson, I have a question about your script.

I noticed that when I build the DOSBox app with your script, it includes 'libz.1.2.11.dylib' in the application bundle.

This library does not get included in my own self-contained bundle when I run dylib bundler on a fresh copy of my custom-patched DOSBox binary. Nor does it show up in the active dylibs when I look in Activity Monitor. I do check out the same SVN source used by your script, and I run the standard configure and make commands after doing my patching, followed by dylib bundler when it is placed in my app bundle. I also checked to make sure I have zlib installed in my Homebrew cellar, so it should be accessible if required by the build process.

I know you have the option in your script to download zlib before commencing with the build process, but I do not see any 'non-standard' build commands to ensure this is bundled with the app. So if it is not determined by the build commands, what commands in your script are ensuring that it gets bundled?

Reply 154 of 172, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

@almeath, I wish I knew the answer to that question. I don't do anything special with zlib that I don't do with the other libraries, and the only thing that bundles the libs is the command that Dominus gave us for dylibbundler.

All I can guess - and it's only a guess - is that dylibbundler can't find the file in your brew setup. Perhaps try downloading it separately, as in my script, and making sure that the path where it gets installed is in the various EXPORTs (which I don't pretend to understand - I only do what Dominus tells me).

Reply 155 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Libpng depends on zlib. If brew's libpng solves that via the system's zlib then you don't need to bundle it.
I think out of compatibility issues I always use an extra zlib since earlier macOS, since older systems bundled a much earlier version.

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

User metadata
Rank Oldbie
Rank
Oldbie

And I only included zlib because my script dates back many years, and possibly it needed it then. If I get a chance, I'll try running my script under Mojave or some earlier version, without downloading zlib...

Reply 157 of 172, by almeath

User metadata
Rank Member
Rank
Member
Dominus wrote on 2021-03-30, 12:38:

Libpng depends on zlib. If brew's libpng solves that via the system's zlib then you don't need to bundle it.
I think out of compatibility issues I always use an extra zlib since earlier macOS, since older systems bundled a much earlier version.

Thanks, I definitely have libpng installed and bundled properly, so that must be it.

For the record, when I run ./configure on my source, I see the following references:

checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes

Reply 158 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Check otool -L on the libpng.dylib. It should list the zlib dependeny and where that gets found.

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

User metadata
Rank Member
Rank
Member
Dominus wrote on 2021-03-30, 13:09:

Check otool -L on the libpng.dylib. It should list the zlib dependeny and where that gets found.

Yes, it is there:

@executable_path/../lib/libpng16.16.dylib (compatibility version 54.0.0, current version 54.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1)

As it resides under usr/lib in the same place as the libobjc-trampolines.dylib, I presume it is a standard file in macOS installations; hence dylib bundler does not bundle it because libpng will always be able to call for it externally?