MacOS 10.13.4 Not able to run

[SCasarotto]

I downloaded the Mac build here: http://spiderwebforums.ipbhost.com/forum/12-blades-of-exile/ and am unable to open the game on macOS 10.13.4. It seems to be working on 10.12.6 just fine. So it must have been a change in 10.13.X that broke it.

Anyone have any suggestions or ways I can try to diagnose and help?

[retropipes]

I experienced this issue myself. The cause is a failure to link required libraries with the main app on launch - and if it works on an older version, clearly a change there is to blame. I’m honestly not sure what the proper way to debug this is.

[CelticMinstrel]

I'm unable to test on any modern Mac, so I can't really do anything about this. Pull requests are welcome though, as long as they don't make the Xcode 4 project file incompatible with Xcode 4 and OSX 10.7.

[retropipes]

I've forked the project and got the build (mostly) fixed on macOS 10.13. The only remaining issue is that the .dylibs aren't linked up properly, so that the final packaged build can find them. I noticed there's a script for this very purpose - fix_dylibs.sh - but SCons doesn't seem to call it anywhere, and my attempts to add it to the Mac packaging SConscript file are running into errors due to a non-existent "path" variable. Below is the code I added to the file:

targets = [ "Blades of Exile", "BoE Character Editor", "BoE Scenario Editor", ] for targ in targets: target_dir = path.join(install_dir, targ + '.app', 'Contents/Frameworks') binary = path.join(install_dir, targ + '.app', 'Contents/MacOS', targ) env.Command(None, binary, action='pkg/mac/fix_dylibs.sh')

When I try to invoke scons with this change, I get: NameError: variable 'path' is not defined ...from Python. Attempting to add path to the list of imports also fails, this time telling me path can't be imported because it does not exist... but it's used in the main SConstruct build file?! I'm confused.

[CelticMinstrel]

The module is actually os.path, so to use it as in your snippet you need import os.path as path.

[SCasarotto]

Any progress on this?

[retropipes]

I've been trying to work on it, but travel and illness have put a severe damper on available time to do so. I'll pick it back up again.

[retropipes]

It's been 7 hours now... and still have not gotten things working. I will pick this back up tomorrow, because I need sleep. I am quite confused by the documentation for the macOS magic word @executable_name for referencing the executable location... I tried using install_name_tool to edit the names, but everything I'm trying is failing when I test the compiled app in a macOS VM...

What's most confusing is the error I get from dyld using that solution: library not found: @executable_name/../Contents/Frameworks/libname.dylib. Why is the magic word not getting expanded? Am I embedding it wrong?

[CelticMinstrel]

Doesn't @executable_name refer to the path to the executable? That's in Contents/MacOS, so I'd think your path based on it shouldn't include Contents.

[retropipes]

Ah yes, good point. Edited the new paths accordingly. Doing one more test cycle. I hope this works!

[retropipes]

That change didn't fix it fully - but it told me right away that it helped, since I got a different error, that told me that I need to patch a bunch of other library references too, which I've now done. Took me 22 tries to get here, but I finally have a working build - albeit one that only works in a Homebrew environment. The way to fix that is to pass in the correct starting paths to the fix_dylibs.sh script, but determining what those should be, exactly, is quite complicated... at least it works! Creating a PR shortly with the changes. Phew!

[retropipes]

The PR is up now. Boy am I glad that's over.

[CelticMinstrel]

albeit one that only works in a Homebrew environment. The way to fix that is to pass in the correct starting paths to the fix_dylibs.sh script, but determining what those should be, exactly, is quite complicated...

Just checking, is this already fixed in the PR?

[retropipes]

The dependency on Homebrew is NOT fixed in the PR, because I have no idea how to fix it. I'm very much a newbie to the scons build tool. As I said, there's a bunch of library paths that need patching - which is evident in the changes to fix_dylibs.sh, but the old versions of those paths are currently hardcoded to the Homebrew versions. There should be a clean way to address this, but I have no idea what it is.

[CelticMinstrel]

Just gonna link to #193 here in case someone else wants to pick it up and polish it off.

Also, regarding what I said at the start of this thread...

as long as they don't make the Xcode 4 project file incompatible with Xcode 4 and OSX 10.7.

That would be satisfied by adding a second, newer Xcode project file alongside the Xcode 4 project file. Perhaps that might be easier than making scons work.

[retropipes]

Well, unfortunately it looks like maintaining this is going to be getting more difficult over time, as the requirement for notarization set to take effect upon the release of macOS 10.14.5 essentially mandates the use of Xcode 10 for compliance. Beyond that, who knows, though we'll know as soon as Apple sees fit to tell us.

[CelticMinstrel]

It doesn't help that I still have an old computer that doesn't run any Xcode beyond 4 (which is one of the reasons for sticking to it). In any case, what you just said suggests that perhaps adding a separate Xcode 10 project would actually be the way to go.

[CelticMinstrel]

Just noting that I have no intention of including notarization in the OBoE build process. Anyone who wants to play OBoE on Mac should just learn how to run non-notarized apps.

[retropipes]

If it’s because you lack Apple Developers paid membership, it’s completely understandable, and even if you did, the Mac build process isn’t even compatible with notarization right now, so that would need changing first. Not that it matters.

[CelticMinstrel]

I also just object to notarization as a concept. Signing your build is one thing, I could live with that, but requiring Apple to personally approve it is too much.