OSX port does not include libraries in bundle?!

[darklord42]

I noticed that the current osx bundle does not include necessary libraries inside the app bundle.  This really isn't ideal, as I'm sure you know.  For starters, as I mentioned in another thread, I, like a few others, am already slaved to macports (or someone could be using fink). If you can't link it to standard framework libraries, then might I suggest this very handy tool I use in my xboard work.

https://github.com/auriamg/macdylibbundler/

It checks the linked binaries of the app, copies them from wherever on your system to a specified folder in the bundle, and relinks them to to the binary for you.   It's really handy and I can't recommend it enough!

[luciderous]

I noticed that the current osx bundle does not include necessary libraries inside the app bundle.  This really isn't ideal, as I'm sure you know.  For starters, as I mentioned in another thread, I, like a few others, am already slaved to macports (or someone could be using fink). If you can't link it to standard framework libraries, then might I suggest this very handy tool I use in my xboard work.

Yes, there are no dynamic libraries/frameworks within the bundle. Nor are they needed - the binary is statically linked with all the dependencies. So it doesn't matter whether you use macports or fink or whatever - nothing is loaded dynamically at startup.

[darklord42]

Really? I get this when I try to open the current build.

$ /Users/me/Desktop/OpenXcom.app/Contents/MacOS/OpenXcom ; exit;
dyld: Library not loaded: /usr/local/lib/libSDL_image-1.2.0.dylib
  Referenced from: /Users/me/Desktop/OpenXcom.app/Contents/MacOS/OpenXcom
  Reason: image not found
Trace/BPT trap: 5
logout

That must be a slight on your part.
---
I guess I was confused by this:
https://bitbucket.org/grrussel/openxcomosx
in the nightly builds, which were current at the time of posting.

I suppose you can statically link the libraries, but that is hardly common practice.  Not to mention more work.  I'm not sure, but would it interfere with licensing? as the library isn't represented, despite being used.  I believe SDL to be pretty liberal with their license, but still.

[mmm333]

I'm not sure if this is the right thread, but it's the closest one I can find. I had no problems installing build 0.9. I really want to play 1.0 but I can't get the game to even launch. I get copy the data folders part, but I'm getting an error when I launch the game. I'm running on OSX 10.9, what do I do? This is beyond my comprehension.

Date/Time:       2014-06-15 01:08:48.259 -0400
OS Version:      Mac OS X 10.9 (13A603)
Report Version:  11

Crashed Thread:  0

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  Library not loaded: /usr/local/lib/libSDL_image-1.2.0.dylib
  Referenced from: /Users/USER/Desktop/OpenXcom.app/Contents/MacOS/OpenXcom
  Reason: image not found

Binary Images:
    0x7fff6ee5d000 -     0x7fff6ee90817  dyld (239.3) <D1DFCF3F-0B0C-332A-BCC0-87A851B570FF> /usr/lib/dyld
    0x7fff8ced3000 -     0x7fff8ced3fff  com.apple.Cocoa (6.8 - 20) <E90E99D7-A425-3301-A025-D9E0CD11918E> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa

[luciderous]

I am looking into the matter right now.
There is a temporary solution, however, if you want to play the game right away. Install Homebrew - https://brew.sh/, and afterwards run the following command in your terminal:

Code: [Select]

$ brew install yaml-cpp sdl sdl_gfx sdl_image sdl_mixer --with-flac --with-libmikmod --with-libvorbis
Anyway, I'll post in this thread when the fixed build is ready. Sorry for inconvenience.

[MrK]

Hello I have same problim on OSX 10.8.5. Sme error.
I use macports to get sdl but it didnt't work, I try to cope libsdl... to usr/local/lib no effect.
I don't want to install brew because it can interfere with macports6 can you give me an advice how to mac openxcom see dyld?
Thank you.

[luciderous]

The fixed build is ready, you can get it here - https://www.mediafire.com/download/cezhbh7ba46596c/OpenXcom-1.0.dmg
Or you can wait until SupSuper updates the official Downloads section.

[MrK]

Updated bundle doesn't work

Process:         OpenXcom [2257]
Path:            /Applications/OpenXcom.app/Contents/MacOS/OpenXcom
Identifier:      SupSuper.OpenXcom
Version:         1.0 ()
Code Type:       X86-64 (Native)
Parent Process:  launchd [234]
User ID:         502

Date/Time:       2014-06-15 15:56:58.337 +0400
OS Version:      Mac OS X 10.8.5 (12F45)
Report Version:  10

Interval Since Last Report:          13094398 sec
Crashes Since Last Report:           73
Per-App Crashes Since Last Report:   2
Anonymous UUID:                     

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

Dyld Error Message:
  Symbol not found: ___strlcpy_chk
  Referenced from: /Applications/OpenXcom.app/Contents/MacOS/../Frameworks/libSDL-1.2.0.dylib
  Expected in: /usr/lib/libSystem.B.dylib

[luciderous]

I suppose you can statically link the libraries, but that is hardly common practice.  Not to mention more work.  I'm not sure, but would it interfere with licensing? as the library isn't represented, despite being used.  I believe SDL to be pretty liberal with their license, but still.

We can argue about 'common practice' notion and the rationale for different options here, but it is irrelevant right now. I prefer static builds because they help to avoid dependency hell in portable apps. Yet it turned out, that Xcode made its own decision despite my preference, and went with dynamic linking instead. Both ways on Mac have their caveats, but to fix the issue ASAP, I adapted back to dynamic linking for now.
As for the licensing issue - your assumption is wrong. Static linking does not interfere with licensing requirements unless you are linking to strong copyleft code and fail to provide the source for your app under the same copyleft terms. Since OpenXcom project is under GPL - this is a non-issue in our case.

[MrK]

It is me again.
I am able to launch new updated bundle ONLY after I replaces openxcom.app/content/frameworks/libSDL-1.2.0.dylib with libSDL-1.2.0.dylib from my computer.
So I think that libSDL-1.2.0.dylib bundled with new version of bundle is hard coded to other frameworks/dylibs form computer in tas compilated on.
Maybe this advice can help anyone.

[luciderous]

It is me again.
I am able to launch new updated bundle ONLY after I replaces openxcom.app/content/frameworks/libSDL-1.2.0.dylib with libSDL-1.2.0.dylib from my computer.
So I think that libSDL-1.2.0.dylib bundled with new version of bundle is hard coded to other frameworks/dylibs form computer in tas compilated on.
Maybe this advice can help anyone.

It's very odd, because libSystem.B.dylib library should exist on any functional OS X install. Perhaps your fiddling with Macports (e.g. installing/uninstalling different packages) somehow botched the original system.
In any case, I'd need some other people's feedbacks on the new build as well, to see if this is a general issue, or something specific to your environment.

[MrK]

It's very odd, because libSystem.B.dylib library should exist on any functional OS X install. Perhaps your fiddling with Macports (e.g. installing/uninstalling different packages) somehow botched the original system.
In any case, I'd need some other people's feedbacks on the new build as well, to see if this is a general issue, or something specific to your environment.

Thank you for your support.
libSystem.B.dylib is present on my system in usr/lib
Lets hope this problem is only on my system

[darklord42]

I say "Common Practice" because the number of OSX apps I have seen that have done that are quite few, in fact never.

The libSystem.B.dylib error isn't just his system. (of course it's on his system or OSX wouldn't boot) I've seen it before.  The problem is the way the libraries are linked to each other.  I know it doesn't look like it makes sense as the library is suppose to be where it's looking, but there you go.  Welcome to Dependency Hell.

Seriously give that program a try.  It's one command in the commandline and you're done.  No mucking about with dependency hell, that's the whole point after all. This is far more problematic then it's worth, and there is in the end there is no difference if it's statically linked or not given apple's app layout.

[luciderous]

The libSystem.B.dylib error isn't just his system. (of course it's on his system or OSX wouldn't boot) I've seen it before.

Have you tried the newest build I suggested above? I'm curious to get as much feedback from different sources as I can.

Seriously give that program a try.  It's one command in the commandline and you're done.  No mucking about with dependency hell, that's the whole point after all. This is far more problematic then it's worth, and there is in the end there is no difference if it's statically linked or not given apple's app layout.

I'll have a look at it.

[mmm333]

Thanks for the quick support on the build. But the updated build didn't work for me and gave me a different error. I can't find libSDL on my computer to replace the one bundled as  MrK suggested. The error message was very long, let me know if you want me to e-mail you the whole error. Anyways, here's the error for me:

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000

Application Specific Information:
/Users/mchin617/Desktop/OpenXcom.app/Contents/MacOS/OpenXcom

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   SupSuper.OpenXcom                0x00000001024ca6e4 _GLOBAL__I_a + 4
1   dyld                             0x00007fff6cb89c2e ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 268
2   dyld                             0x00007fff6cb89dba ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
3   dyld                             0x00007fff6cb86a62 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) + 308
4   dyld                             0x00007fff6cb868f6 ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 54
5   dyld                             0x00007fff6cb7a1da dyld::initializeMainExecutable() + 189
6   dyld                             0x00007fff6cb7d560 dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 2419
7   dyld                             0x00007fff6cb7927b dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 477
8   dyld                             0x00007fff6cb7905e _dyld_start + 54

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000001  rbx: 0x00000001024ca6e0  rcx: 0x00007fff5d9acd70  rdx: 0x00007fff5d9acd10
  rdi: 0x0000000000000001  rsi: 0x00007fff5d9acd00  rbp: 0x00007fff5d9ab2f0  rsp: 0x00007fff5d9ab2f0
   r8: 0x00007fff6cbac178   r9: 0x00007fff5d9ab200  r10: 0x00007fff92ac8543  r11: 0x00000001025aae21
  r12: 0x000000000000001e  r13: 0x00007fff6cbac0b0  r14: 0x00007fff6cbb2ed8  r15: 0x0000000102597578
  rip: 0x00000001024ca6e4  rfl: 0x0000000000010246  cr2: 0x00000001024ca6e0
 
Logical CPU:     0
Error Code:      0x00000000
Trap Number:     6