auriamg / macdylibbundler Goto Github PK

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.

I was investigating how to build widelands for Apple Silicon.
I found your tool and it worked quite fine but the App crashed with EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))
I checked and found that codesign --sign - --force * in .app/Contents/libs actually fixes the issue.

I think you want to incorporate this your tool to fix this issue, before more people get a headache.

New user here. My setup

• macOS Mojave
• Xcode 10.3
• dylibbundler 0.4.1, installed from Homebrew

Tried , on my hello-world app built with GTK+:

dylibbundler -od -b -x hello_gtk_app.app/Contents/MacOS/hello_gtk_app -d hello_gtk_app.app/Contents/Resources/lib/ -p @executable_path/../Resources/lib/

The resulting app simply crashes. Before this, it runs fine on the dev machine.
If I turn to run the executable inside the app bundle from Terminal, then I see

Killed: 9

Any ideas how I can fix this?

This must be due to a change that happened a day or two ago because this successfully built last week. It seems this method might not exist or be declared correctly?

*** Action: compile for libs/macdylibbundler ***
entering the source directory!
executing command: "/usr/bin/make" -j2
/usr/bin/clang++ -c -I./src ./src/Settings.cpp -o ./Settings.o
/usr/bin/clang++ -c -I./src ./src/DylibBundler.cpp -o ./DylibBundler.o
/usr/bin/clang++ -c -I./src ./src/Dependency.cpp -o ./Dependency.o
/usr/bin/clang++ -c -I./src ./src/main.cpp -o ./main.o
/usr/bin/clang++ -c -I./src ./src/Utils.cpp -o ./Utils.o
/usr/bin/clang++ -o ./dylibbundler ./Settings.o ./DylibBundler.o ./Dependency.o ./main.o ./Utils.o
Undefined symbols for architecture x86_64:
"isRpath(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&)", referenced from:
collectDependencies(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >) in DylibBundler.o
collectSubDependencies() in DylibBundler.o
Dependency::Dependency(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >) in Dependency.o
ld: symbol(s) not found for architecture x86_64

After I've updated libcurl (brew update curl) dylibbundler doesn't works.

$ otool -LD my-app
...
        /usr/local/opt/curl/lib/libcurl.4.dylib (compatibility version 12.0.0, current version 12.0.0)

$ otool -LD /usr/local/opt/curl/lib/libcurl.4.dylib
...
	/usr/local/opt/brotli/lib/libbrotlidec.1.dylib (compatibility version 1.0.0, current version 1.0.9)
...
$ dylibbundler -od -b -x my-app ...
...
/!\ WARNING : can't get path for '@loader_path/libbrotlicommon.1.dylib'
Please specify the directory where this library is located (or enter 'quit' to abort):

What have I to do?

PS:

$ ls -l /usr/local/opt/brotli/lib/
total 3272
-r--r--r--  1 atomin  staff  131568 Aug 27 18:12 libbrotlicommon-static.a
-r--r--r--  1 atomin  staff  164848 Dec  9 12:34 libbrotlicommon.1.0.9.dylib
lrwxr-xr-x  1 atomin  staff      27 Aug 27 18:12 libbrotlicommon.1.dylib -> libbrotlicommon.1.0.9.dylib
lrwxr-xr-x  1 atomin  staff      23 Aug 27 18:12 libbrotlicommon.dylib -> libbrotlicommon.1.dylib
-r--r--r--  1 atomin  staff   45632 Aug 27 18:12 libbrotlidec-static.a
-r--r--r--  1 atomin  staff   85344 Dec  9 12:34 libbrotlidec.1.0.9.dylib
lrwxr-xr-x  1 atomin  staff      24 Aug 27 18:12 libbrotlidec.1.dylib -> libbrotlidec.1.0.9.dylib
lrwxr-xr-x  1 atomin  staff      20 Aug 27 18:12 libbrotlidec.dylib -> libbrotlidec.1.dylib
-r--r--r--  1 atomin  staff  617720 Aug 27 18:12 libbrotlienc-static.a
-r--r--r--  1 atomin  staff  615248 Dec  9 12:34 libbrotlienc.1.0.9.dylib
lrwxr-xr-x  1 atomin  staff      24 Aug 27 18:12 libbrotlienc.1.dylib -> libbrotlienc.1.0.9.dylib
lrwxr-xr-x  1 atomin  staff      20 Aug 27 18:12 libbrotlienc.dylib -> libbrotlienc.1.dylib
drwxr-xr-x  5 atomin  staff     160 Dec  9 12:34 pkgconfig

when compiling on linux it cant find fflush, stdout

including cstdio fixes it

Trying to fix path in a mixed obj-c and Swift project. I cannot ignore libswiftAppKit.dylib. Or I am missing something?

dylibbundler -od -b -x MacOS/MyApp -d ./libs -i libswiftAppKit.dylib
* Collecting dependencies...............
/!\ WARNING : Library libswiftAppKit.dylib has an incomplete name (location unknown)

Running on Travis CI
TRAVIS_COMMIT: 27923fbf6d1bc4d18c18e118280c4fe51fc41a80
$GITHUB_TOKEN missing, please set it in the Travis CI settings of this project
You can get one from https://github.com/settings/tokens

https://travis-ci.org/auriamg/macdylibbundler/builds/389483424#L66

I get this when I try to run your app on my executable. I'm guessing, though I'm not sure, that one of the dependancies depends on something else, which is referenced by @loader_path. Perhapss this type of path should cause dylib bundler to ignore that particular one?

• Collecting dependencies.......................
  /!\ WARNING : Cannot resolve path '@loader_path/liballegro.5.2.dylib'

/!\ WARNING : Library liballegro.5.2.dylib has an incomplete name (location unknown)
Please specify now where this library can be found (or write 'quit' to abort):

Thanks,
-Michael.

after bundling qemu-img installed via homebrew libhogweed still point to /usr/local/Cellar/nettle/3.3/lib/libnettle.6.dylib

$ otool -L libhogweed.4.3.dylib 
libhogweed.4.3.dylib:
    @loader_path/libhogweed.4.3.dylib (compatibility version 4.0.0, current version 4.3.0)
    /usr/local/Cellar/nettle/3.3/lib/libnettle.6.dylib (compatibility version 6.0.0, current version 6.3.0)
    @loader_path/libgmp.10.dylib (compatibility version 14.0.0, current version 14.1.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)

Could somebody help me with this one:
widelands/widelands#5610

   dylibbundler --create-dir --bundle-deps \
        --fix-file $DESTINATION/Widelands.app/Contents/MacOS/widelands \
        --dest-dir $DESTINATION/Widelands.app/Contents/libs \
        --search-path $ASANPATH                                     

Fails with some special resources used by our game only:

codesign --force --deep --preserve-metadata=entitlements,requirements,flags,runtime --sign - "WidelandsRelease/Widelands.app/Contents/MacOS/widelands"
WidelandsRelease/Widelands.app/Contents/MacOS/widelands: replacing existing signature
WidelandsRelease/Widelands.app/Contents/MacOS/widelands: bundle format unrecognized, invalid, or unsuitable
In subcomponent: /Users/klaus/develop/widelands/v1.1-rc1/WidelandsRelease/Widelands.app/Contents/MacOS/data/maps/Finnish_Lakes.wmf
  * Error : An error occurred while applying ad-hoc signature to WidelandsRelease/Widelands.app/Contents/MacOS/widelands

The .app Bundle can be started without issues. For now I Ignored the result. but this doe not seem reasonable?

Coming from this issue:
#40

I've built a sanity-check example, which fails to find the dylib upon running:

• An Xcode project mylib that builds a barebone .dylib, which prints a string.
• Another bare-bone Xcode project hello_dylib that simply uses this dylib.

After successfully building both projects, I then run

(12:44)me@mymac:~/Desktop/_learn/gtk/hello_dylib/build/Debug 
$ dylibbundler -od -b -x hello_dylib.app/Contents/MacOS/hello_dylib -d hello_dylib.app/Contents/Resources/lib/ -p @executable_path/../Resources/lib/
* Collecting dependencies...
/!\ WARNING : Library libmylib.dylib  has an incomplete name (location unknown)
Please specify now where this library can be found (or write 'quit' to abort): /Users/me/Desktop/_learn/gtk/mylib/build/Debug

/Users/me/Desktop/_learn/gtk/mylib/build/Debug/libmylib.dylib  was found. /!\MANUALLY CHECK THE EXECUTABLE WITH 'otool -L', DYLIBBUNDLDER MAY NOT HANDLE CORRECTLY THIS UNSTANDARD/ILL-FORMED DEPENDENCY
.......FOUND libmylib.dylib  in /Users/me/Desktop/_learn/gtk/mylib/build/Debug/


 * libmylib.dylib  from /Users/me/Desktop/_learn/gtk/mylib/build/Debug/

* Checking output directory hello_dylib.app/Contents/Resources/lib/
* Erasing old output directory hello_dylib.app/Contents/Resources/lib/
    rm -r hello_dylib.app/Contents/Resources/lib/
* Creating output directory hello_dylib.app/Contents/Resources/lib/
    mkdir -p hello_dylib.app/Contents/Resources/lib/
    cp -n /Users/me/Desktop/_learn/gtk/mylib/build/Debug/libmylib.dylib  hello_dylib.app/Contents/Resources/lib/libmylib.dylib 
    chmod +w hello_dylib.app/Contents/Resources/lib/libmylib.dylib 
    install_name_tool -id @executable_path/../Resources/lib/libmylib.dylib  hello_dylib.app/Contents/Resources/lib/libmylib.dylib 

* Fixing dependencies on hello_dylib.app/Contents/Resources/lib/libmylib.dylib 
    install_name_tool -change /Users/me/Desktop/_learn/gtk/mylib/build/Debug/libmylib.dylib  @executable_path/../Resources/lib/libmylib.dylib  hello_dylib.app/Contents/Resources/lib/libmylib.dylib 
    install_name_tool -change libmylib.dylib  @executable_path/../Resources/lib/libmylib.dylib  hello_dylib.app/Contents/Resources/lib/libmylib.dylib 

* Fixing dependencies on hello_dylib.app/Contents/MacOS/hello_dylib
    install_name_tool -change /Users/me/Desktop/_learn/gtk/mylib/build/Debug/libmylib.dylib  @executable_path/../Resources/lib/libmylib.dylib  hello_dylib.app/Contents/MacOS/hello_dylib
    install_name_tool -change libmylib.dylib  @executable_path/../Resources/lib/libmylib.dylib  hello_dylib.app/Contents/MacOS/hello_dylib

After this I simply run in Terminal:

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

I got:

(12:45) me@mymac:~/Desktop/_learn/gtk/hello_dylib/build/Debug 
$ hello_dylib.app/Contents/MacOS/hello_dylib 
dyld: Library not loaded: /usr/local/lib/libmylib.dylib
  Referenced from: /Users/me/Desktop/_learn/gtk/hello_dylib/build/Debug/hello_dylib.app/Contents/MacOS/hello_dylib
  Reason: image not found
Abort trap: 6

I wonder where I did wrong.

Seems there is an error when try to copy the same file(full path) to the relative file path.

* Processing dependency GoldenDict.app/Contents/Frameworks/libicuuc.72.dylib
    cp -f "/Users/runner/work/goldendict-ng/goldendict-ng/GoldenDict.app/Contents/Frameworks/libicuuc.72.dylib" "GoldenDict.app/Contents/Frameworks/libicuuc.72.dylib"
cp: GoldenDict.app/Contents/Frameworks/libicuuc.72.dylib and /Users/runner/work/goldendict-ng/goldendict-ng/GoldenDict.app/Contents/Frameworks/libicuuc.72.dylib are identical (not copied).


Error : An error occured while trying to copy file /Users/runner/work/goldendict-ng/goldendict-ng/GoldenDict.app/Contents/Frameworks/libicuuc.72.dylib to GoldenDict.app/Contents/Frameworks/libicuuc.72.dylib

From my experience, any change/adaptation of signed/notarised dylib is recognised by Darwin security system and the loading is blocked. Is that a problem for macdylibbundler ?

Is there any way to use macdylibbundler with unversioned dylibs? I'm using it along with macdeployqt and the last one use unversioned dylibs whereas that macdylibbundler use dylibs verioned.

Any clue about?

Hi,

Please find attached a suggested patch. My issue was that I was trying to package .dylib that are in .framework directories, and this patch allowed me to do this.

Regards,
Anna.
P.S. How do I upload non-supported file types?

Some of the dynamic libraries I build are interlinked with each other, and as part of the build, they get relocated when they are lipoed together to form combined 32-/64-bit libraries. The relocation invalidates the absolute pathnames embedded in them, so macdylibbundler cannot locate them. I added --search-path to my copy of macdylibbundler to get it to look in specific places if the absolute pathname lookup fails. If you like, I will provide the source for this change.

Currently using Homebrew to install dylibbundler installs a very old version. Is it possible to get HEAD tagged and released?

Hello,

I've recently run into an issue while fixing a dylib that is included in my application. When I build for Intel I have no issues, but I recently began working on a Universal build for Intel/M1 and ran into this issue. Every dylib included in the application is also built as a universal binary.

This is the command I am running:
dylibbundler -of -cd -b -x ./MiniMeters.app/Contents/MacOS/MiniMeters -d ./MiniMeters.app/Contents/Frameworks -p @executable_path/../Frameworks/

Output:
* Fixing dependencies on ./MiniMeters.app/Contents/Frameworks/libbrotlicommon.1.0.9.dylib install_name_tool -rpath "/opt/local/lib" "@executable_path/../Frameworks/" "./MiniMeters.app/Contents/Frameworks/libbrotlicommon.1.0.9.dylib" install_name_tool -rpath "/opt/local/lib" "@executable_path/../Frameworks/" "./MiniMeters.app/Contents/Frameworks/libbrotlicommon.1.0.9.dylib" error: install_name_tool: no LC_RPATH load command with path: /opt/local/lib found in: ./MiniMeters.app/Contents/Frameworks/libbrotlicommon.1.0.9.dylib (for architecture x86_64), required for specified option "-rpath /opt/local/lib @executable_path/../Frameworks/" error: install_name_tool: no LC_RPATH load command with path: /opt/local/lib found in: ./MiniMeters.app/Contents/Frameworks/libbrotlicommon.1.0.9.dylib (for architecture arm64), required for specified option "-rpath /opt/local/lib @executable_path/../Frameworks/"

I removed exit(1) on errors in fixRpathsOnFile() and recompiled. When I use otool -l to check the rpath of the offending dylib it appears to be fixed. And in testing the .app bundle produced works perfectly on fresh macOS installations.

Just did a build / test of this and it totally missed a dependent library (libssl & libcrypto) -- also missed a bunch of dylibs in /usr/opt installed from MacPorts as well as a few from Brew.

Ended up having to copy most of the missing libraries over by hand then run the install_name_tool manually.

Let me know how I can help?

I'm figuring out what my options are for cross compiling the dxx-rebirth project are using osxcross on a Linux host, and I'm finding that dylibbundler is behaving differently than I'd expect when I try to use it to bundle libraries in.

Because dylibbundler relies on Mac-native tools (some of which don't have Linux equivalents), I copied my resulting app bundle to my Mac along with the libraries the build process used. I use Homebrew on my Mac, but osxcross gets libraries from MacPorts, hence copying the libraries over.

What I'm seeing is that when dylibbundler calls install_name_tool, it passes the location it actually found the library in as the value of the -change parameter, which doesn't end up doing anything, since the value there has to match what the binary already has as a library location.

For example, running the following:

dylibbundler -od -b -x build/D1X-Rebirth.app/Contents/MacOS/d1x-rebirth -d build/D1X-Rebirth.app/Contents/libs -s /Users/kreeblah/macports_libs/

Part of the output there is:

    install_name_tool -change "/Users/kreeblah/macports_libs/libpng16.16.dylib" "@executable_path/../libs/libpng16.16.dylib" "build/D1X-Rebirth.app/Contents/MacOS/d1x-rebirth"
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: warning: changes being made to the file will invalidate the code signature in: build/D1X-Rebirth.app/Contents/MacOS/d1x-rebirth

Note the -change "/Users/kreeblah/macports_libs/libpng16.16.dylib" part. However, if I run otool -l build/D1X-Rebirth.app/Contents/MacOS/d1x-rebirth, this is part of the output:

Load command 13
          cmd LC_LOAD_DYLIB
      cmdsize 64
         name /opt/local/lib/libpng16.16.dylib (offset 24)
   time stamp 2 Wed Dec 31 16:00:02 1969
      current version 56.0.0
compatibility version 56.0.0

From the man page for install_name_tool:

       -change old new
              Changes the dependent shared library install name old to new in
              the specified Mach-O binary.  More than one of these options can
              be specified.  If the Mach-O binary does not contain the old
              install name in a specified -change option the option is
              ignored.

So, it seems that by using the -s option to look for libraries in an alternative path, those libraries do get copied into the bundle, but nothing gets its paths updated (this impacts libraries that have dependencies as well).

In Dependency.cpp at around line 130:

    //check if file is contained in one of the paths
    for( int i=0; i<searchPathAmount; ++i)
    {
        std::string search_path = Settings::searchPath(i);
        if (search_path[ search_path.size()-1 ] != '/') search_path += "/";  // Add this line to fix missing "/" from path in next line
        if (fileExists( search_path+filename ))
        {
            std::cout << "FOUND " << filename << " in " << search_path << std::endl;
            prefix = search_path;
            missing_prefixes = true; //the prefix was missing
            break;
        }
    }

"As part of this change, copies of dynamic libraries are no longer present on the filesystem." (62986286)
https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-beta-release-notes/

When dylibbundler started I've had the error:

* Collecting dependencies..
/!\ WARNING : Cannot resolve path '/usr/lib/libSystem.B.dylib'

/!\ WARNING : Library libSystem.B.dylib has an incomplete name (location unknown)
Please specify the directory where this library is located (or enter 'quit' to abort)

As you can see, the build with 9cf053f works fine, whereas with the current master it asks for manual path input and times out eventually.

The last version you released on SourceForge is 0.4.4 but it still contains this line:

const std::string VERSION = "0.4.1";

This line remains in the current version of the code in this github repository.

By default, QT installs itself on /usr/local/Qt-VERSION/VERSION/ etc...

When I use it to fix a binary, it correctly brings the binary's own libraries, but ignores Qt frameworks. (maybe because they don't have the .dylib on their name?)

I want to use it exactly to save me the work of adding QT's frameworks to my binary...

The reason this is happening is that using 'otool -L' on a dylib includes the ID in the output !!!

So you need to find out if there is an ID and remove it from the output line list !

Here is a quick fix I did, that you may like to use, or your own variation on this. Note I use 'auto', so put -std=c++11 on your makefile lines !

Best regards

Chris

void collectDependencies(std::string filename, std::vectorstd::string& lines)
{
// execute "otool" on the given file and collect the command's output
std::string cmd = "otool -D " + filename;
std::string id_output = system_get_output(cmd);
auto start = std::find(id_output.begin(), id_output.end(), '\n') + 1;
auto end = std::find(start, id_output.end(), '\n');

cmd = "otool -L " + filename;
std::string output = system_get_output(cmd);

if(output.find("can't open file")!=std::string::npos or output.find("No such file")!=std::string::npos or output.size()<1)
{
    std::cerr << "Cannot find file " << filename << " to read its dependencies" << std::endl;
    exit(1);
}

//remove id we don't want !!!
if (start != end)
{
  start = std::find(output.begin(), output.end(), '\n') + 1;
  end = std::find(start, output.end(), '\n') + 1;
  output = std::string(output.begin(), start) + std::string(end, output.end());
}

// split output
tokenize(output, "\n", &lines);

}

Hi,
Using Catalina.
make fails because PATH_MAX is not defined.
It doesn't seem to be defined in any of the sources, so I guess this is some sort of system constant that make, on my system, is failing to find.
What is the recommended solution?

I ran the following command:

dylibbundler -od -b -x ./myapp -d ./libs/

I got the following output:

• Collecting dependencies.....
• Checking output directory ./libs/
• Erasing old output directory ./libs/
  rm -r ./libs/
• Creating output directory ./libs/
  mkdir -p ./libs/
• Fixing dependencies on ./fs-hasher

Then I checked ./libs/ and there was nothing in it. Your instructions say that the -b flag is supposed to "Cop[y] libaries to a local directory." It does not appear to have done this. (According to the description of the -d flag, if I'm understanding correctly, the local directory is supposed to be the one set by -d.)

I am a total noob, so it's completely possible that I've done something wrong, but I have no idea what. Is this flag in fact not supposed to collect dependencies? If not, how else are we supposed to bundle them with your program?

I created an app with a binary with two names. The space in the app name is escaped, however when I run a tool it doesn't seem to like spaces.

tag4800:macdylibbundler dtakeda$ ./dylibbundler -od -b -x ~/Desktop/Waveform\ Maker.app/Contents/MacOS/Waveform\ Maker -d ~/Desktop/Waveform\ Maker.app/Contents/libs
* Collecting dependencieserror: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool: can't open file: /Users/dtakeda/Desktop/Waveform (No such file or directory)

Hello! Was very excited to find this tool, as it seems like a great replacement for my own brittle, ad-hoc, app-specific script.

Unfortunately, an issue I've recently encountered is that I've had many users report that my app (Tad ) doesn't work on macOS 11 because I built it on macOS 12, and apparently libc++.1.dylib on macOS 11 isn't compatible.
The only robust solution I can think of is to bundle libc++ with my app, and do the appropriate fixups.

Unfortunately, as far as I can tell, there is currently no way to bundle libc++ and do the fixups with macdylibbundler since libc++ is found in /usr/lib/libc++.1.dylib, and it doesn't look like there's a way to disable the check for isSystemLibrary. Is that a correct interpretation, or am I missing something? Any suggestions much appreciated. Would you consider a PR for adding a command line argument to disable the isSystemLibrary check (or perhaps exclude specific libs from the check)?

Hey,

I made an executable that includes a library (FMOD just in case you care)..
When I run the bundler on my app, it does everything correctly for all the other dylibs that it uses, it also copies all the dylibs (including the fmod.dylib!) into the libs folder, it changes all the entries on my executable correctly to be "libs/xxxx.dylib", however it doesnt change the one for fmod.dylib - it stays "@rpath".
The result is that it doesnt run on another machine because the fmod.dylib isnt found. in order to make it work i have to manually use the install_tool to change the @rpath entry to become the same like the other entries, which is terribly annoying.
can this be fixed or is there a way to add the rpath entries to be handled by dylib?

There is an off-by-one error that causes every path processed to have a space at the end of it (mentioned in a comment in #2).

The problem is that you find the position of the string " (" in the output of otool, and then feed that to the second argument of substr, but the second argument of substr expects a length, not a position. If the start position were 0 that wouldn't be a problem, but the start position is 1 (to remove the leading tab character), so you need to substract that 1 from the found position to get the length.

Also, find finds the first occurrence of the string. What if a path for some reason contained that string " ("? Better to use rfind which finds the last occurrence of the string.

This patch fixes these problems:

https://trac.macports.org/browser/trunk/dports/devel/dylibbundler/files/patch-src-DylibBundler.cpp.diff?rev=136949

In addition, you should revert fef319a which is not correct. fef319a will cause problems with files whose names actually do end with a space, though that's of course very unlikely to ever occur in practice.

Running the tool as follows for instance on a linux system where the /usr/lib/libSystem.B.dylib does not exist :

dylibbundler \
   --fix-file <path-to>/SomeProj.app/Contents/MacOS/SomeProj \
   --dest-dir <path-to>/SomeProj.app/Contents/MacOS/lib \
   --bundle-deps --install-path '@executable_path/../lib' \
   --overwrite-dir --create-dir \
   --ignore /usr/lib

The tool fails to ignore a dependency of /usr/lib/libSystem.B.dylib refuses to update the bundle dependencies. I will follow shortly with a pull request to fix this issue.

If a path passed as argument to one of the flags contains a space (that's not uncommon for .app bundles), then the program will fail.