dylibbundler is missing dependencies

[jjeising]

I would like to fix a binary with some more complex GTK dependencies. This kind of works, but the dependencies of pulled in dylibs sometimes get lost. Example:

The binary depends on libatkmm and libatk:

$ otool -L [binary] | grep atk
	/usr/local/opt/atkmm/lib/libatkmm-1.6.1.dylib (compatibility version 3.0.0, current version 3.0.0)
	/usr/local/opt/atk/lib/libatk-1.0.0.dylib (compatibility version 22210.0.0, current version 22210.1.0)

dylibbundler has fixed this link and copied libatkmm-1.6.1.dylib. It also pulled in libatk (the original C library) and fixed it's dependencies. But the dependency on libatk of libaktmm is not fixed:

$ otool -L libatk-1.0.0.dylib
libatk-1.0.0.dylib:
	@executable_path/../libs/libatk-1.0.0.dylib (compatibility version 22210.0.0, current version 22210.1.0)
	@executable_path/../libs/libgobject-2.0.0.dylib (compatibility version 5001.0.0, current version 5001.0.0)
	@executable_path/../libs/libglib-2.0.0.dylib (compatibility version 5001.0.0, current version
…
$ otool -L libatkmm-1.6.1.dylib
libatkmm-1.6.1.dylib:
	@executable_path/../libs/libatkmm-1.6.1.dylib (compatibility version 3.0.0, current version 3.0.0)
	/usr/local/lib/libatk-1.0.0.dylib (compatibility version 21810.0.0, current version 21810.1.0)
	@executable_path/../libs/libglibmm-2.4.1.dylib (compatibility version 5.0.0, current version 5.0.0)
	@executable_path/../libs/libgobject-2.0.0.dylib (compatibility version 4601.0.0, current version 4601.2.0)
…

The commit of @chearon seems to fix this – the build works with this version.

[auriamg]

Hi, I'm no longer actively maintaining dylibbundler, but if someone wants to make a pull request I would be more than happy to merge it. Unfortunately chearon's work might be mergeable as-is since the commit message reads "this should NOT be relied on for new work because I didn't really take
the time to fully understand how it's suppose to work"

[chearon]

Yeah, I saw how I could get it to work in a quick way and didn't go any deeper. I think I see where the problem really is now, though, I'll open a PR soon

[chearon]

@jjeising is there anything else depending on the C library libatk before you bundle? or just libatkmm?

[jjeising]

@chearon The binary itself depends on libatk, but with a different path. The dependencies are a little complex (38 in total) so I've just picked a simple one. But I should have checked this more thorough.

I have updated the post above to reflect this. You can also see the different path for libatk here:

otool -L /usr/local/opt/atkmm/lib/libatkmm-1.6.1.dylib | grep atk
/usr/local/opt/atkmm/lib/libatkmm-1.6.1.dylib:
    /usr/local/opt/atkmm/lib/libatkmm-1.6.1.dylib (compatibility version 3.0.0, current version 3.0.0)
    /usr/local/lib/libatk-1.0.0.dylib (compatibility version 21810.0.0, current version 21810.1.0)

(vs. /usr/local/opt/atk/lib/libatk-1.0.0.dylib in the binary).

Symlinks are at different levels:

/usr/local/opt/atk -> ../Cellar/atk/2.22.0
/usr/local/lib/libatk-1.0.0.dylib -> ../Cellar/atk/2.22.0/lib/libatk-1.0.0.dylib

[chearon]

Thanks, I ask because it actually turns out that my situation is a little different than the one I described in my commit. I think Homebrew had multiple copies of the same library, which my patch fixed because it patches ALL paths with the same base filename.

Just in case your situation is mine, and not a symlink issue, what does:

readlink /usr/local/opt/atk/lib/libatk-1.0.0.dylib
readlink /usr/local/lib/libatk-1.0.0.dylib

output?

[jjeising]

$ readlink /usr/local/opt/atk/lib/libatk-1.0.0.dylib
$ readlink /usr/local/lib/libatk-1.0.0.dylib
../Cellar/atk/2.22.0/lib/libatk-1.0.0.dylib

$ realpath /usr/local/opt/atk/lib/libatk-1.0.0.dylib
/usr/local/Cellar/atk/2.22.0/lib/libatk-1.0.0.dylib
$ realpath /usr/local/lib/libatk-1.0.0.dylib
/usr/local/Cellar/atk/2.22.0/lib/libatk-1.0.0.dylib

[chearon]

those readlinks indicate that the first is a real file, and the second is a symbolic link to a different file. I'd think this would be an issue with Homebrew

[jjeising]

It is a real file because /usr/local/opt/atk is linked to the current version in the cellar:

/usr/local/opt/atk -> ../Cellar/atk/2.22.0

This is expected behaviour from homebrew as far as I know. This path is used for formulas that are keg-only (not linked to /usr/local/lib. Why mixed pathes in a single lib, I don't know.

But as the realpath of both libs points to the same target shouldn't dylibbundler replace both?

[chearon]

My mistake, you're right, the issue is multiple symbolic links pointing to the same file. Which is also my problem. The code uses the same prefix for all symbolic links (it expects them all to be in the same directory) which I think is the issue. If it stored the full path instead then all symbolic links would be correctly patched, is there a reason they are expected to be in the same directory @auriamg ?

[auriamg]

dylibbundler may have limitations simply because I never encountered any such case, I don't think there's any fundamental reason why this couldn't be supported

[jjeising]

@chearon I've tested your pull request #19, it looks like it's still missing something (commenting here for references):

These are fine:

$ otool -L [new-binary] | grep atk
    @executable_path/../libs/libatkmm-1.6.1.dylib (compatibility version 3.0.0, current version 3.0.0)
    @executable_path/../libs/libatk-1.0.0.dylib (compatibility version 22210.0.0, current version 22210.1.0)
$otool -L .../libs/libatk-1.0.0.dylib
.../libs/libatk-1.0.0.dylib:
    @executable_path/../libs/libatk-1.0.0.dylib (compatibility version 22210.0.0, current version 22210.1.0)
    @executable_path/../libs/libgobject-2.0.0.dylib (compatibility version 5001.0.0, current version 5001.0.0)
    @executable_path/../libs/libglib-2.0.0.dylib (compatibility version 5001.0.0, current version 5001.0.0)
    @executable_path/../libs/libintl.8.dylib (compatibility version 10.0.0, current version 10.5.0)
...

But one dependency is untouched:

otool -L .../libs/libatkmm-1.6.1.dylib | grep atk
.../libs/libatkmm-1.6.1.dylib:
    @executable_path/../libs/libatkmm-1.6.1.dylib (compatibility version 3.0.0, current version 3.0.0)
    /usr/local/lib/libatk-1.0.0.dylib (compatibility version 21810.0.0, current version 21810.1.0)

Your old patch didn't show this behaviour. I hope I got the path from the pull request right, but I double checked and it looks like the right version.

[chearon]

@jjeising did you do make clean && make? I made a test program that links against atkmm and it seems to work for me: http://pastebin.ubuntu.com/23447534/

Edit: if you post everything before the first Fixing dependencies on statement, that would help too

[jjeising]

@chearon I did: https://p.rrbone.net/paste/fu7ovGaG#6YAbV4Jz (/usr/local/lib/libatk-1.0.0.dylib does not appear in the dylibbundler output at all).

[chearon]

that's very weird, it doesn't look like /usr/local/lib/libatk-1.0.0.dylib was even picked up at all in your main binary... what's the otool -L of the main binary before you run the bundler?