Failed at a barebone example. about macdylibbundler HOT 6 OPEN

The test projects are attached. Unzip, do not change their relative location, and build them both.
Then you should be able to see what I see, hopefully.
Archive.zip

from macdylibbundler.

I tried something new. After I see the Abort trap, I simply:

install_name_tool -change /usr/local/lib/libmylib.dylib @executable_path/../Resources/lib/libmylib.dylib hello_dylib.app/Contents/MacOS/hello_dylib

Then, run the executable as usual

/Users/me/Desktop/_learn/gtk/hello_dylib/build/Debug/hello_dylib.app/Contents/MacOS/hello_dylib

This gives me exactly what was in #40:

Killed: 9

from macdylibbundler.

After some digging, I solved my problem by doing the whole dance manually through otool and install_name_tool. macdylibbundler by design has a particular problem:

the last op:

install_name_tool -change libmylib.dylib  @exececutable_path/../Frameworks/lib/libmylib.dylib  hello_dylib.app/Contents/MacOS/hello_dylib

in my case should be corrected to:

install_name_tool -change /usr/local/lib/libmylib.dylib  @exececutable_path/../Frameworks/lib/libmylib.dylib  hello_dylib.app/Contents/MacOS/hello_dylib

which means on my machine, the dylibs are first searched under some system paths such as /usr/local/lib, instead of the working directory. The output of otool -L /path/to/hello_dylib gives me

otool -L "/Users/me/Desktop/_learn/gtk/hello_dylib/build/Debug/hello_dylib.app/Contents/MacOS/hello_dylib"
/Users/kakyo/Desktop/_learn/gtk/hello_dylib/build/Debug/hello_dylib.app/Contents/MacOS/hello_dylib:
	**/usr/local/lib/libmylib.dylib** (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1575.17.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1671.60.107)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1575.17.0)

So the executable does assume that my lib to be under /usr/local/lib
I don't know if this has anything to do with my custom $PATH, which has been modified by I don't know how many other apps. But I suspect that macdylibbundler should parse otool output faithfully.

from macdylibbundler.

dylibbundler is a simple tools that works for most basic cases, but it was not meant to handle all the weird special cases. I actually no longer use a mac very often, so this project is a bit in search of a new maintainer.

One possibility is that your "libmylib" has an incorrect (or at least unusual) "internal name", dylibbundler will have trouble handling those

from macdylibbundler.

I have a similar problem when I try to work with a dylib file.

My observation was that when I link as -dynamiclib, as opposed to -bundle, the library file is self-referring in the output of otool -L.

./string-machine.lv2/string-machine_ui.dylib:
	../../bin/string-machine.lv2/string-machine_ui.dylib (compatibility version 0.0.0, current version 0.0.0)

And then dylibbundler fails, indicating that it can't find itself.

/!\ WARNING : Cannot resolve path '../../bin/string-machine.lv2/string-machine_ui.dylib'
/!\ WARNING : Library string-machine_ui.dylib has an incomplete name (location unknown)

This path is identical to the option -o of the compiler.

Do you think it's fine to ignore the first entry in case the file is a dylib?

from macdylibbundler.

I found myself an answer, it's otool -L is showing the load command LC_ID_DYLIB.

For correctness, you have to get dylib ID (otool -D) and remove it from -L output.

from macdylibbundler.