Incompatible with macOS versions that are 64-bit only

[Liz4v]

I got the just-pre-released version from today and got this:

“DPE-mac.app” needs to be updated.
The developer of this app needs to update it to work with this version of macOS. Contact the developer for more information.
Learn More… https://support.apple.com/en-ca/HT208436

I am running macOS Monterey 12.0.1 on a MacBook Pro (15-inch, 2018). Processor is x86_64.

[hidefromkgb]

Done! Please test.
The only correction I made to the source to build the x64 version is -m32 → -m64 here.
Will update the repo soon, and maybe even teach the build system to generate «fat» multi-arch binaries that contain both x86-32 and x86-64 code — and who knows, maybe even M1 code as well. Someday. when I pluck up enough courage to buy an actual Mac instead of relying on virtual machines

[hidefromkgb]

«Fat» binary generated and added to the release.

[Liz4v]

I was planning to try to build it but I've been v busy with end-of-year stuff! 😅
Anyhow!! It loads now, it asks to download the ponies and it throws this error during the updater:

Failed to create directory "/private/var/folders/n4/bsmk1fxx4h585fzklwwyy804mjg6k8/T/AppTranslocation/F04B9172-58CB-47BC-9734-452175023D72/d"

I checked and this directory already exists.

[Liz4v]

It looks like this is some sort of macOS security feature that creates a sandbox that is probably not writable. This sucks! I'll see if I can find a solution.

[hidefromkgb]

Damn… This is something new. On my 10.13 it downloads the animation base just fine.
Please do try to debug this, since I (for the umpteenth time) don`t have the means to reproduce it.

[hidefromkgb]

This might be relevant: https://apple.stackexchange.com/a/311274

[hidefromkgb]

Just checked on 10.15.7, still cannot reproduce =(

[Liz4v]

I finally got around to trying to build it. The build fails on

✘  ~/src/DPengine/macos   master  make
clang -march=core2 -mstackrealign -fno-stack-protector -fvisibility=hidden -fconstant-cfstrings -mmacosx-version-min=10.6.0 -m32 -Wl,-macosx_version_min -Wl,10.6.0 -lcurl -lcrypto -framework AppKit -headerpad_max_install_names -L.. .obj/exec/exec.o .obj/run.o .obj/core/core.o .obj/core/gif/gifstd.o .obj/core/ogl/oglstd.o .obj/lib.o -o ../macos.app/Contents/MacOS/DPE -framework OpenGL
ld: warning: building for macOS 10.6.0 is deprecated
ld: warning: passed two min versions (10.6, 10.6.0) for platform macOS. Using 10.6.0.
ld: library not found for -lcrypto
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [elink] Error 1

I tried to fix with brew to no avail. I unfortunately have zero experience with C in the Apple ecosystem. I can keep digging but I'd rather ask you how you got -lcrypto to work. Maybe I have to click things on XCode?

Warning: No available formula with the name "libcrypto". Did you mean libscrypt, libgcrypt, bcrypt or libcroco?
==> Searching for similarly named formulae...
These similarly named formulae were found:
libscrypt                     libgcrypt ✔                   bcrypt                        libcroco

[hidefromkgb]

Damn, that`s unexpected.
For the sake of 10.6-to-10.15 compatibility (god I do love me some compatibility) I build on 10.10 with just the XCode command line kit, but I promise I`ll test on 10.13 this weekend.

[hidefromkgb]

In the meantime, could you please test my pre-built binary? I repacked it so it has both X86-32 and X86-64 now.

[Liz4v]

I tested 0.2.3a and it has the same problem. I don't see anything newer?

[Liz4v]

I have followed this workaround and I get much further into the linking process but it still fails.
vernemq/vernemq#206 (comment)

DPengine/macos   master ±  make
clang -march=core2 -mstackrealign -fno-stack-protector -fvisibility=hidden -fconstant-cfstrings -mmacosx-version-min=10.6.0 -m32 -Wl,-macosx_version_min -Wl,10.6.0 -lcurl -lcrypto -framework AppKit -headerpad_max_install_names -L.. -L/usr/local/opt/libressl/lib -I/usr/local/opt/libressl/include .obj/exec/exec.o .obj/run.o .obj/core/core.o .obj/core/gif/gifstd.o .obj/core/ogl/oglstd.o .obj/lib.o -o ../macos.app/Contents/MacOS/DPE -framework OpenGL
ld: warning: building for macOS 10.6.0 is deprecated
ld: warning: passed two min versions (10.6, 10.6.0) for platform macOS. Using 10.6.0.
ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS)
ld: warning: ignoring file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libcurl.tbd, missing required architecture i386 in file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libcurl.tbd (3 slices)
ld: warning: ignoring file /usr/local/opt/libressl/lib/libcrypto.dylib, building for macOS-i386 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/crt1.10.6.o, building for macOS-i386 but attempting to link with file built for unknown-x86_64
ld: warning: ignoring file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks//AppKit.framework/AppKit.tbd, missing required architecture i386 in file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks//AppKit.framework/AppKit.tbd (3 slices)
ld: warning: ignoring file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks//OpenGL.framework/OpenGL.tbd, missing required architecture i386 in file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks//OpenGL.framework/OpenGL.tbd (3 slices)
ld: warning: ignoring file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libSystem.tbd, missing required architecture i386 in file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/libSystem.tbd (3 slices)
Undefined symbols for architecture i386:
  "_CFAbsoluteTimeGetCurrent", referenced from:
      _rInternalMainLoop in run.o
      _lRunMainLoop in lib.o
  "_CFArrayCreate", referenced from:
      _rOpenContextMenu in run.o
      _ChooseFileDir in run.o
  "_CFArrayGetValueAtIndex", referenced from:
      _ChooseFileDir in run.o
      _main in run.o
(… snip several hundred similar lines …)
  "_write$UNIX2003", referenced from:
      _rSaveFile in run.o
  "start", referenced from:
     implicit entry/start for main executable
     (maybe you meant: _lRestartEngine)
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [elink] Error 1

Uhhh i386? Has macOS ever built for that? I guess it has.

Look I understand from this project that you love compatibility but us Mac users are used to be told we're SOL when our systems are old. :) That's how Apple treats its users and we just take it in stride. If it supported M1 only it would be awesome even though I don't have access yet to an M1.

[hidefromkgb]

Oh crud, I put the 32-bit target first so it gets selected by default.
Please try to build the RelJoined64 target.

[hidefromkgb]

I tested 0.2.3a and it has the same problem. I don't see anything newer?

So does the binary downloaded from here really refuse to execute?
My virtualized 10.11, 10.13, and 10.15 must be playing some Hackintosh-specific trick on me then, for they run it as if it were nothing, even with decent FPS despite lacking the proper drivers.
I do need to get a real macbook I guess. As a compatibility freak I hate it when such things happen =(

[Liz4v]

make RelJoined64 works! I had to make clean before it would build but it did and then it works. Gallus is happily prancing about with his resting ahole face on one of my monitors right now. 😁 No idea how to make him go to the other monitor though.

The binary downloaded from there fails with the AppTranslocation permission problem. I assume the cryptographic library works, either because it's statically linked or because it holds different dylib include paths that don't match my default XCode configuration.

From what I understand so far, if I were to package my build and send it to you, then you probably would experience the AppTranslocation problem.