search

Interrupt / systemshock

Shockolate - A minimalist and cross platform System Shock source port.
GNU General Public License v3.0
803 stars 62 forks source link

Include precompiled SDL2 libraries with the precompiled releases? #276

Open a-hurst opened 5 years ago

a-hurst commented 5 years ago

Hi everyone,

First of all, I'm so happy to see people doing something with this source code! I was hoping I'd see a project like this spring up as soon as I heard the original mac source was released. Thanks so much for your efforts.

My issue is that I rely on 64-bit SDL2 for my work and thus can't play Shockolate, because I can't install the 32-bit libraries over my brewed 64-bit versions in /usr/local/ (which the install script does by default). Since I'm aware that bringing the code up to 64-bit compatibility is still a ways off, would it be possible to include pre-compiled 32-bit SDL2 libraries with the pre-built Shockolate releases and have the executable link to those, avoiding the need to mess with the system-installed SDL2 libraries? Failing that, would it be possible for there to a flag to the 'install_32bit_sdl.sh' script to install the libraries locally in the Shockolate folder, instead of globally?

Thanks in advance! Can't wait to try it out.

Interrupt commented 5 years ago

Something like this would be a good idea. If we shipped the libraries we might still need to have people set some custom LD_LIBRARY_PATH env vars for the app to find the libs correctly, maybe a wrapper app could help with all this?

a-hurst commented 5 years ago

I'm no expert, but I'm pretty sure Windows will look for .dlls in the folder of an executable by default, and on macOS you can use the install_name_tool utility to specify library linking paths relative to the path of a compiled binary (see here for an example). It looks like you can set relative rpaths similarly under Linux, too.

Hope that helps!

markkurikola commented 5 years ago

For the record, I'm trying to do exactly the local library installation in https://github.com/Interrupt/systemshock/pull/274 -- note however that I'm doing this on Windows so any help from actual Linux/Mac users would be appreciated wink wink

a-hurst commented 5 years ago

With the latest release and CI changes, this is very close to being fixed on macOS. The only remaining issue is that the systemshock binary is expecting the SDL2 .dylib files to be at the exact paths they were at on the CI build machine, so the systemshock binary can't make use of them:

dyld: Library not loaded: /Users/travis/build/Interrupt/systemshock/build_ext/built_sdl/lib/libSDL2-2.0.0.dylib
  Referenced from: /Users/ahurst/Downloads/shockolate/./systemshock
  Reason: no suitable image found.  Did find:
    /usr/local/lib/libSDL2-2.0.0.dylib: mach-o, but wrong architecture
Trace/BPT trap: 5

The fix for this is to add install_name_tool to the CI process to make the linking paths for the dylibs relative to the location of the systemshock binary:

install_name_tool -change /Users/travis/build/Interrupt/systemshock/build_ext/built_sdl/lib/libSDL2-2.0.0.dylib @executable_path/lib/libSDL2.dylib systemshock
install_name_tool -change /Users/travis/build/Interrupt/systemshock/build_ext/built_sdl_mixer/lib/libSDL2_mixer-2.0.0.dylib @executable_path/lib/libSDL2_mixer.dylib systemshock
install_name_tool -change /Users/travis/build/Interrupt/systemshock/build_ext/built_sdl/lib/libSDL2-2.0.0.dylib @loader_path/libSDL2.dylib lib/libSDL2_mixer.dylib

The first two lines point the systemshock binary to the correct relative locations of the SDL2 dylibs, and the last line points the SDL2_mixer dylib to the correct relative location for the SDL2 dylib. After running those lines, System Shock launches and runs just fine with the pre-compiled binaries.

I'd imagine you would need to do something similar with rpath for Linux, but that's outside of my wheelhouse.