Closed alecjacobson closed 3 years ago
Hi, thanks for the pull request, though could you please explain why change otool -L to otool -l ? In which cases could the former be insufficient?
I switched to otool -l
so that I could ignore "weakly" loaded shared libraries: identified by the line cmd LC_LOAD_WEAK_DYLIB
, rather than the usual cmd LC_LOAD_DYLIB
. This showed up in my particular case when trying to bundle the dylib for the "mosek" solver which tries to "weakly" link to some libcilkrts.5.dylib
library which I neither have nor need.
I guess otool -L
will display all shared libraries the file uses regardless of whether the should be "loaded" or "weak loaded". As far as I can tell, "weakly" loaded libraries can (or maybe even must) be ignored.
Okay I understand, I'm just a little wary of this kind of change, things like this seem a little brittle
lines.push_back('\t'+line.substr(found+5,std::string::npos));
hardcoding '5' doesn't seem too robust. Admitedly though most of dylibbundler isn't that robust anyway. Also, possibly whether to include weak links or not should be an option I guess Finally, I have relatively little time to do in-depth testing so I can't confirm this doesn't cause regressions (should have built unit tests I guess!), which is why I'm slightly wary of such core changes :) I'm not saying no though, just making sure this is the best way to go
Very nice. I'm surprised something like this wasn't made sooner. I've been working with GLPK makefiles for mac, and it always hardcodes the install names, with no way to change it. My clients aren't tech savvy, so they don't have GLPK installed which is necessary for my program to run. So I had to use install_name_tool to change the paths for which the binary searches it for. This bundler tool automates that process. So uh yeah, thanks.
Hi CodeGuro , are you able to test that this code works well for you too? If I can get a few success stories I am going to merge this
I'm talking about the project as a whole. I didn't test this particular branch of it yet, I just happened to seen this history.
Okay I understand, I'm just a little wary of this kind of change, things like this seem a little brittle
lines.push_back('\t'+line.substr(found+5,std::string::npos));
hardcoding '5' doesn't seem too robust. Admitedly though most of dylibbundler isn't that robust anyway. Also, possibly whether to include weak links or not should be an option I guess Finally, I have relatively little time to do in-depth testing so I can't confirm this doesn't cause regressions (should have built unit tests I guess!), which is why I'm slightly wary of such core changes :) I'm not saying no though, just making sure this is the best way to go
'5' is to omit name
in the line name @executable_path/../Frameworks/libavcodec.58.dylib (offset 24)
The otool -l
improvement from this PR is included in #49. Good work @alecjacobson
The Makefile simplification from this PR is included in #58.
Thank you very much for this useful piece of code.
I've updated the text parsing to find some libraries that were being missed by your original code. I've also simplified the makefile a bit.