Retroarch: (OSX) Mac version of RetroArch has no 'Bundle Identifier' since version 1.7.4

Created on 2 Oct 2018  路  23Comments  路  Source: libretro/RetroArch

as mentioned here
https://github.com/libretro/RetroArch/issues/7004#issuecomment-417633545
all RetroArch Mac versions starting from 1.7.4 suddenly have no 'Bundle Identifier' anymore.

(CFBundleIdentifier entry in the Info.plist file)

the Bundle Identifier wasn't missing previously, and had 'always' been set to 'libretro.RetroArch' or 'libretro.RetroArchCg' respectively.

preferences, caching and several other things are probably broken for apps without bundle-identifier, as Apple requires that every app has a (unique) bundle identifier.

the problem also exists in both official 1.7.5 versions here:
https://buildbot.libretro.com/stable/1.7.5/apple/osx/x86_64/

its quite weird that this is missing since its present here:
https://github.com/libretro/RetroArch/blob/master/pkg/apple/OSX/Info.plist

where is the build script that generates the DMGs and how did it change between 1.7.3 and 1.7.4?

osx prs welcome

Most helpful comment

The fix has been merged and I have verified all 3 osx nightlies (starting at 2019-02-08) have the CFBundleIdentifier in the Info.plist.

@orbea I think this can be closed since the main issue was addressed (along with the side Metal issue).

All 23 comments

I will mention this to @bparker06, thanks.

What are the consequences of this not being there, though? Does it not work or what is the issue exactly?

well, only Apple can tell you the full extent of the consequences, as every app is supposed to have the identifier. but it still launches, so it obviously could be worse ;)

automatic caching and native preference mechanisms are certainly broken for apps that don't have an indentifier.

For the Metal version, the dmg is created here:

https://github.com/libretro/RetroArch/blob/master/travis_metal_deploy.sh#L33

For non-Metal the script is not in a public repo but the command is the same.

I just extracted the dmg from the latest nightly Metal build and the identifier is there:

$ 7z x 2018-10-06_RetroArch_Metal.dmg
...
$ 7z x 4.hfs
...
$ grep BundleIdent RetroArch/RetroArch.app/Contents/Info.plist
    <key>CFBundleIdentifier</key>

1.7.5 release:
RetroArch_CG.dmg no bundle identifier
RetroArch.dmg no bundle identifier
RetroArch_Metal.dmg seems to be broken completely, no app, just a bunch of files

latest 2018-10-07 nightly:
RetroArch_CG.dmg no bundle identifier
RetroArch.dmg no bundle identifier
RetroArch_Metal.dmg contains the bundle identifier!

so there must be some difference between metal and non-metal deplopyment

i've had a look at the the new builds.

i can confirm the 'metal' build is fixed. it has both a bundle identifier and a version.

the 'normal' and 'cg' versions still miss their bundle-identifier.

What are the consequences of this not being there, though? Does it not work or what is the issue exactly?

I'd written an Applescript for myself that interfaced with RetroArch. It's now broken because there's no Bundle ID :(

no bundleid = no real app

if something works without bundleid, its only by accident

this is not fixed in 1.7.6. both retroarch and retroarch-cg for macOS in version 1.7.6. still contain no bundle identifier. this should have been a release blocker!

even worse, retroarch-metal contains no binary at all again, its just uncompiled source code.

If no one that can reproduce this issue actually steps up as a maintainer its just not going to be fixed. The reality is that we are all volunteers and maintaining apple hardware we may not even have or ever use is a huge burden. Hopefully an interested person may be able to help...

i already offered to help but no one was able to tell me where the build script that generates the (non metal) mac binaries are located

Also see the travis logs for the metal build, I have no idea about the final errors...

Ld /Users/travis/build/libretro/RetroArch/pkg/apple/build/Release/RetroArch.app/Contents/MacOS/RetroArch normal x86_64 (in target: RetroArchQt)
    cd /Users/travis/build/libretro/RetroArch/pkg/apple
    export MACOSX_DEPLOYMENT_TARGET=10.13
    /Applications/Xcode-10.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -isysroot /Applications/Xcode-10.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -L/Users/travis/build/libretro/RetroArch/pkg/apple/build/Release -F/Users/travis/build/libretro/RetroArch/pkg/apple/build/Release -F/usr/local/opt/qt/lib -filelist /Users/travis/build/libretro/RetroArch/pkg/apple/build/RetroArch_Metal.build/Release/RetroArchQt.build/Objects-normal/x86_64/RetroArch.LinkFileList -Xlinker -rpath -Xlinker @executable_path -Xlinker -rpath -Xlinker @executable_path/../Frameworks -mmacosx-version-min=10.13 -Xlinker -object_path_lto -Xlinker /Users/travis/build/libretro/RetroArch/pkg/apple/build/RetroArch_Metal.build/Release/RetroArchQt.build/Objects-normal/x86_64/RetroArch_lto.o -stdlib=libc++ -fobjc-arc -fobjc-link-runtime -weak_framework QtConcurrent -weak_framework QtCore -weak_framework QtGui -weak_framework QtNetwork -weak_framework QtWidgets -framework QuartzCore -framework IOSurface -framework Metal -framework MetalKit -lz -framework CoreAudio -framework AudioUnit -framework OpenGL -framework AppKit -framework CoreVideo -framework IOKit -Xlinker -dependency_info -Xlinker /Users/travis/build/libretro/RetroArch/pkg/apple/build/RetroArch_Metal.build/Release/RetroArchQt.build/Objects-normal/x86_64/RetroArch_dependency_info.dat -o /Users/travis/build/libretro/RetroArch/pkg/apple/build/Release/RetroArch.app/Contents/MacOS/RetroArch
GenerateDSYMFile /Users/travis/build/libretro/RetroArch/pkg/apple/build/Release/RetroArch.app.dSYM /Users/travis/build/libretro/RetroArch/pkg/apple/build/Release/RetroArch.app/Contents/MacOS/RetroArch (in target: RetroArchQt)
    cd /Users/travis/build/libretro/RetroArch/pkg/apple
    /Applications/Xcode-10.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/dsymutil /Users/travis/build/libretro/RetroArch/pkg/apple/build/Release/RetroArch.app/Contents/MacOS/RetroArch -o /Users/travis/build/libretro/RetroArch/pkg/apple/build/Release/RetroArch.app.dSYM
WriteAuxiliaryFile /Users/travis/build/libretro/RetroArch/pkg/apple/build/RetroArch_Metal.build/Release/RetroArchQt.build/Script-053FC27621434B7700D98D46.sh (in target: RetroArchQt)
    cd /Users/travis/build/libretro/RetroArch/pkg/apple
    write-file /Users/travis/build/libretro/RetroArch/pkg/apple/build/RetroArch_Metal.build/Release/RetroArchQt.build/Script-053FC27621434B7700D98D46.sh
PhaseScriptExecution Run\ Script /Users/travis/build/libretro/RetroArch/pkg/apple/build/RetroArch_Metal.build/Release/RetroArchQt.build/Script-053FC27621434B7700D98D46.sh (in target: RetroArchQt)
    cd /Users/travis/build/libretro/RetroArch/pkg/apple
    /bin/sh -c /Users/travis/build/libretro/RetroArch/pkg/apple/build/RetroArch_Metal.build/Release/RetroArchQt.build/Script-053FC27621434B7700D98D46.sh
Updating RetroArch.app with Qt deployment
ERROR: Unexpected prefix "@executable_path"
ERROR: Unexpected prefix "@executable_path"
ERROR: Unexpected prefix "@executable_path"
Touch /Users/travis/build/libretro/RetroArch/pkg/apple/build/Release/RetroArch.app (in target: RetroArchQt)
    cd /Users/travis/build/libretro/RetroArch/pkg/apple
    /usr/bin/touch -c /Users/travis/build/libretro/RetroArch/pkg/apple/build/Release/RetroArch.app
RegisterWithLaunchServices /Users/travis/build/libretro/RetroArch/pkg/apple/build/Release/RetroArch.app (in target: RetroArchQt)
    cd /Users/travis/build/libretro/RetroArch/pkg/apple
    builtin-lsRegisterURL /Users/travis/build/libretro/RetroArch/pkg/apple/build/Release/RetroArch.app
** BUILD SUCCEEDED **
The command "xcodebuild -target RetroArchQt -configuration Release -project pkg/apple/RetroArch_Metal.xcodeproj" exited with 0.

https://travis-ci.org/libretro/RetroArch/jobs/488594802

@executable_path shows up here and here
There's also the Travis deploy script, which IIRC you said was the issue earlier: https://github.com/libretro/RetroArch/blob/master/travis_metal_deploy.sh

thanks i'll look into it but won't have time before next week

I looked into this issue a bit - at least the metal build, to start.

I can compile the metal version locally using Xcode 10.1 on Mojave without a problem and run the compiled app. The @executable_path messages are still there but don't seem to impact anything. The build also includes the CFBundleIdentifier as well.

As far as the 1.7.6 release and nightly metal builds: The dmg contains only the contents of the asset bundle (bundle.zip) and nothing else. This appears to be from an issue in the travis_metal_deploy.sh script.

I believe I've found the issue and will be submitting a PR shortly.

I looked around a little regarding the main issue here (CFBundleIdentifier) and was able to locate the problem. I'll submit a PR for the fix tomorrow.

The fix has been merged and I have verified all 3 osx nightlies (starting at 2019-02-08) have the CFBundleIdentifier in the Info.plist.

@orbea I think this can be closed since the main issue was addressed (along with the side Metal issue).

this is broken again.

download RetroArch 1.7.7 for mac, it reports that it is actually version 1.7.6:

    <key>CFBundleShortVersionString</key>
    <string>1.7.6</string>
    <key>CFBundleVersion</key>
    <string>1.7.6</string>

both RetroArch and RetroArch-Metal are affected.

and again this is broken.

download RetroArch 1.8.0 for mac, it reports that it is actually version 1.7.9

the 'metal' version is also affected

Was this page helpful?
0 / 5 - 0 ratings