Can't compile the master 64 bit Boxer, help needed =(

[Shrapnel21]

Hi everyone!
First of all, I'm a total noob: I never compiled anything before and I just downloaded Xcode for the first time ever. Sorry. =P
With that said, I tried downloading the package for the 64 bit version and tried compiling it, but Xcode 10.2.1 keeps telling me that it's "Unable to resolve build file: XCBCore.BuildFile". I've found some info about this error and tried the suggestions I saw, but nothing works. What am I doing wrong?

[almeath]

I have been trying to get the 64 bit master to build under Xcode 10 on Mojave for months now with no success. Fortunately, I was able to build MaddTheSane's 64 bit branch using Xcode 9.4.1. You can download it from here if you want to try it:

http://www.eftel.com/~almeath/mac/boxer64.zip

[almeath]

Finally got the standard 64 bit master to build in Xcode under Mojave. I used Github Desktop to download the repository, updated submodules via terminal using "git submodule update --init --recursive" and then built in Xcode 9.4.1.

http://www.eftel.com/~almeath/mac/boxer64master.zip

[john-at-charpa]

Many thanks for doing these builds. I've tested at least one or two of them and they seem to run alright until you attempt to open a folder (browse DOS Games folder). As soon as this is attempted it crashes. Have you seen this same behaviour? I've not started digging at the code, but I suspect it has something to do with sandboxing and how the file system is accessed in Mojave.

[almeath]

I have not noticed any crashing from either build in Mojave on my system.

Did you go to the Security & Privacy preference pane in the Finder and allow the Boxer app to have “full disk access”?

Also, do you experience a crash if you navigate to your DOS games folder in the Finder and launch a Boxer game bundle by double-clicking it directly?

Are you able to create and run fresh game bundles in these builds?

[john-at-charpa]

I've given the Boxer.app full disk access, but I should mention that 'old' 32-bit Boxer does not have
this access specifically granted.

I cleaned out everything in ~/Library/ that was related to Boxer in an way (caches, cookies, Application
support). However, when running it again it crashes in the same place. It asks for me to locate the
folder (and I can create it). However the instant it tries to access it there is a crash.

Next, I tried to create a new game. I skipped trying to browse and just attempted to drop a folder
with a DOS game into boxer. When I do that I get the blue Boxer window and "Session is not ready"
with the only option: OK. I suspect it somehow cannot run the DOSBox command properly.

Open a new DOS Prompt does work (and I can manually build a game).

.. and the most important bit: I can both launch a freshly created as well as an old game.boxer game bundle by double clicking on it. MT-32 emulation functions as well (whew). So it still seems like it is somehow related to disk access or folder access. Per my previous comment the drag-and-drop to install fail. However, if you click OK then run the game it functions fine (and you can re-run install).

I can certainly provide a stack trace if it would help. The source of the pain appears to be:

Performing @selector(ok:) from sender _NSPaddedButton 0x600003713900
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSWorkspace URLHasCustomIcon:]: unrecognized selector sent to instance 0x60000000c5e0'
terminating with uncaught exception of type NSException
abort() called

[john-at-charpa]

If I had to guess I'd say that the cause is this:

Boxer/Application Delegate/BXShelfAppearanceOperation.m
(line 154+)

- (void) _applyAppearanceToFolderAtURL: (NSURL *)folderURL
{  
   NSAssert(self.backgroundImageURL != nil, @"BXShelfAppearanceApplicator _applyAppearanceToFolder called without background image.");

   //If the folder doesn't have a custom icon of its own, apply our shelf icon to the folder
   if (self.icon && ![[NSWorkspace sharedWorkspace] URLHasCustomIcon: folderURL])
    {   
        [[NSWorkspace sharedWorkspace] setIcon: self.icon forFile: folderURL.path options: 0];
    }

[getaaron]

Seems like NSWorkspace+ADBIconHelpers.m isn’t compiled or linked properly?

[almeath]

Is this affecting MadTheSane’s build as well as the master?

I haven’t had a chance to try to reproduce these errors yet. I am going to test in High Sierra as well as Mojave, both fresh installs.

[almeath]

By the way, I didn’t do anything to customize these builds .. they are straight compiles with no alterations.

[almeath]

I have been able to reproduce the reported issues on fresh installs of Mojave 10.14.5 and High Sierra 10.13.6.

The issue affects both builds, so I presume the underlying problem is just carried through into MadTheSane’s customized build.

Interestingly, the errors do not occur for me in my main install of Mojave in which I compiled these builds. It only occurs once they are moved onto other installs of macOS.

I just did not notice until now because I prefer to use Boxer Bundler to make self-contained app wrappers and these all work fine for me, and on other Macs.

I am wondering if this has anything to do with the fact I could only successfully build in Xcode 9.4.1 rather than the latest 10.x release?

At least the issues can be worked around as reported, but it would be good to get to the bottom of this.

I might have another crack at compiling in the latest Xcode 10 release and see how it goes.

[john-at-charpa]

I think that something is null/empty and is passed unchecked to the API. It may be macOS API changes that cause something to silently fail earlier in the code:

https://stackoverflow.com/questions/36111461/terminating-app-due-to-uncaught-exception-nsinvalidargumentexception-reason

https://stackoverflow.com/questions/55440922/app-crashes-randomly-with-nsinvalidargumentexception-unrecognized-selector-sent

If you can determine what is different between your ripe macOS and a fresh 10.14, then we may be able to track it down. It looks like it may have something to do with icons or the folders. I've not got time to look at this right now, but if I can replicate a build with Xcode 9 then I'll see if I can add some debug prints. Fair warning: my Objective C clue is nil and I'm an abysmal programmer to start with..

[almeath]

One thing I recall is that I manually code signed the main Boxer app (but not Bundler or Standalone) via the terminal after compile because it was acting strangely when I tried to launch it - i.e. the icon was freezing for about half a second when double clicked. Code signing the app with my Apple developer ID fixed the issue and I have no idea why. I also have SIP and Gatekeeper disabled.

However, I have now managed to compile the 64 bit master in the latest Xcode (10.2.1), and this time I have not touched it at all - just dragged it fresh from the Xcode developer folder and uploaded it 'as is'. Can you please try it out and let me know if the same problems occur?

http://www.eftel.com/~almeath/mac/Boxer64master2.zip

[john-at-charpa]

Unfortunately the crash still happens. It stopped complaining about the code signature, so that's a step forward. I have a second Mac running Mojave and I got the same results running it there too.

[almeath]

The only thing that distinguishes my main install of Mojave is that it is a system that has been progressively updated from macOS 10.9 all the way though to 10.14.

I used a completely fresh install of Mojave, with fresh installs of Github desktop and Xcode. The build exhibits the above problems right off the bat, within that fresh system. That leads me to believe there is an inherent problem with building 64-bit Boxer in Mojave.

What I will do next, is repeat the fresh install process again with High Sierra. I previously tested the Mojave builds in HS, but not one built within it. That would at least help establish if we are dealing with a Mojave-only or wider issue.

[getaaron]

@john-at-charpa could you please post the full stack trace? I’m trying to reproduce it on a fresh Mojave system and having trouble.