-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split squashfuse_ll into a lib and executable #59
Conversation
This makes it easier for people to statically link squashfuse_ll into their application, which can in turn be used to more easily ship self-exectracting binaries (e.g. facebook xar or appimage)
Is it easy to make it so the squashfuse binary links against squashfuse_ll statically rather than dynamically? Having a more portable, self-contained executable is nicer (probably no practical perf benefit but there's that, too). Automake is... challenging... so it may be nontrivial. But if it's easy I think I'd prefer that. |
I was wondering the same thing, but didn't bother looking into it yet. Right now we have
what you mean is to statically link lib/* into bin/*, right? Then the only dynamically linked libs are likely libfuse and compression libs? I don't think we can statically link other libs, since libfuse is LGPL and squashfuse BSD (otherwise we'd have to make squashfuse GPL too). Not very experienced with autotools, but to be honest I don't hate it -- in fact it's better than cmake when it comes to generating static AND shared libraries (and even cross compilation out of the box?). |
Hm, I guess it should just not link at all, but use the object files. |
I think I've figured it out. For what it's worth, the executables and libs can be really tiny:
|
4635aa5
to
6a99d24
Compare
Looks good! |
This makes it easier for people to statically link squashfuse_ll into
their application, which can in turn be used to more easily ship
self-exectracting binaries (e.g. facebook xar or appimage)