How to ship release version

[mokiat]

Go version: 1.21.3
Go-SDL2 version: v0.4.35
SDL2 version: 2.28.5
OS: MacOS
Architecture: ARM

Hi,

I installed sdl2 + sdl2 mixer via brew. I then built a binary and then uninstalled sdl2 to simulate the environment of a potential user of my app. When running the executable I get the following error:

dyld[54995]: Library not loaded: /opt/homebrew/opt/sdl2_mixer/lib/libSDL2_mixer-2.0.0.dylib
  Referenced from: <SOME-GUID-HERE> /Users/momchil/Workspace/sdl-audio/demo
  Reason: tried: '/opt/homebrew/opt/sdl2_mixer/lib/libSDL2_mixer-2.0.0.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/opt/sdl2_mixer/lib/libSDL2_mixer-2.0.0.dylib' (no such file), '/opt/homebrew/opt/sdl2_mixer/lib/libSDL2_mixer-2.0.0.dylib' (no such file)

I can't seem to find dylib distributables in the official SDL releases. There are dmg files but those contain extensionless files. Any idea where I could get the dylib files from? Also, once I do get a hold of them, what needs to be done to trick the app to search for such files in the same directory as the binary and not in homebrew?

I am trying to ensure that an app can easily be packaged afterwards, without having to put for MacOS run brew install ....; for Linux run apt install documentation and expecting users to know what to do and want to do it.

[veeableful]

Hi @mokiat, app bundle could be a way. I'm not too familar with it but perhaps this could help? #574

[gen2brain]

@mokiat You can use https://github.com/auriamg/macdylibbundler to pack libraries that app depend on in the bundle. Also, you can use install_name_tool -change to change @executable_path, you can see where it currently points with otool -L. Here is an example script I was using for some project:

#!/bin/sh

mkdir -p mupen64plus/Contents/MacOS/

cp test/*.dylib mupen64plus/Contents/MacOS/

APP_CONTENTS="./mupen64plus/Contents"

FIX_LIST="-x $APP_CONTENTS/MacOS/libmupen64plus.dylib \
 -x $APP_CONTENTS/MacOS/mupen64plus-audio-sdl.dylib \
 -x $APP_CONTENTS/MacOS/mupen64plus-input-sdl.dylib \
 -x $APP_CONTENTS/MacOS/mupen64plus-rsp-hle.dylib \
 -x $APP_CONTENTS/MacOS/mupen64plus-rsp-z64.dylib \
 -x $APP_CONTENTS/MacOS/mupen64plus-video-arachnoid.dylib \
 -x $APP_CONTENTS/MacOS/mupen64plus-video-rice.dylib \
 -x $APP_CONTENTS/MacOS/mupen64plus-video-z64.dylib \
 -x $APP_CONTENTS/MacOS/mupen64plus-video-glide64mk2.dylib"

dylibbundler -cd -b $FIX_LIST -d $APP_CONTENTS/MacOS/ -p '@executable_path/'

rm -rf $APP_CONTENTS/Resources
rm -rf $APP_CONTENTS/SharedSupport
mkdir -p $APP_CONTENTS/Resources
mkdir -p $APP_CONTENTS/Frameworks
cp test/*.ini test/*.ttf test/*.txt $APP_CONTENTS/Resources
cp -r test/doc $APP_CONTENTS/SharedSupport
cp -r /Library/Frameworks/SDL2.framework $APP_CONTENTS/Frameworks

FILES="$APP_CONTENTS/MacOs/libmupen64plus.dylib
$APP_CONTENTS/MacOs/mupen64plus-audio-sdl.dylib
$APP_CONTENTS/MacOs/mupen64plus-input-sdl.dylib
$APP_CONTENTS/MacOs/mupen64plus-video-rice.dylib
$APP_CONTENTS/MacOs/mupen64plus-video-glide64mk2.dylib
$APP_CONTENTS/MacOs/mupen64plus-video-z64.dylib"

for file in $FILES; do
    install_name_tool -change @executable_path/libSDL2-2.0.0.dylib @executable_path/../Frameworks/SDL2.framework/Versions/A/SDL2 ${file}
done

Hope this helps, all in all, the issue is not really related to this repo.

[mokiat]

@veeableful , I am familiar with app bundles. I already have a tool that builds such a bundle with glfw. The benefit there is that I don't need to package any libs, since the OS already has them by default.

I am looking into using SDL2 for a number of reasons (sound being one of them), however, but the library part is making the whole process painful.

@gen2brain , thanks for the ideas. I managed to use otool and install_name_tool to get something working. The problem is that it only works if I copy the dylib files from homebrew into the app folder and use install_name_tool with them. It does not work with the Framework that is officially released by SDL2.

I think that it has to do with the fact that brew says it has installed one version of SDL but the dylibs are a totally different version. And when I use install_name_tool to point to the official ones with the same version, it complains that there is a mismatch. I should probably open a bug to SDL2.

Do you know if there is a way to force Go to ignore pkg-config and use the lib inside the framework? I tried all sorts of flags on the go compiler and environment variables but could not get it to work.

[mokiat]

In the end I went with static linking of SDL2. Closing this.