auriamg / macdylibbundler

Utility to ease bundling libraries into executables for OSX
MIT License
550 stars 83 forks source link

simplified makefile, corrected text parsing #5

Closed alecjacobson closed 3 years ago

alecjacobson commented 9 years ago

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.

auriamg commented 9 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?

alecjacobson commented 9 years ago

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.

auriamg commented 9 years ago

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

CodeGuro commented 9 years ago

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.

auriamg commented 9 years ago

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

CodeGuro commented 9 years ago

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.

SCG82 commented 4 years ago

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)

SCG82 commented 4 years ago

The otool -l improvement from this PR is included in #49. Good work @alecjacobson

SCG82 commented 3 years ago

The Makefile simplification from this PR is included in #58.