Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Enable building against shared libraries (lua, jemalloc). 100% backwards compatible #137
I know this isn't the "redis way"; but distributions generally dislike the notion of upstream bundling 3rd-party packages. This at least gives them (or people wanting to use the benefits of shared libraries) the option. I don't see any harm in having this in, as long as it doesn't disrupt the ordinary build system.
Possible caveat: jemalloc prefix
The two main reasons for statically linking are:
When allowing third party code to be linked dynamically, we lose the second one. If something in those libraries breaks, we are unable to even detect whether the issue is Redis-related, or that the responsibility for the issue fully lies with the third party code. Even if we include the version information of the linked libraries in information dumps, we cannot pinpoint exactly which version of the code was used (think monkey patches against an otherwise clean source tree, distribution-specific version suffixes, etc). This makes debugging issues that may be related to third party code a lot harder, and to be honest, I wouldn't like to go there.
Another problem with that is that we expect a certain version of Redis to have exactly a certain version of Lua, since version x.y.z should be capable of executing exactly the same scripts everywhere.
This also would mainly benefit Linux distributions that are known for having an incredibly outdated of Redis that is mostly of no use... ;) So while this may appear as a good idea at first and is in general perhaps good practice, in the case of Redis we don't like this approach, even if perfectly reasonable.
Thanks for submitting. Closing the issue.
Just wanted to address your arguments:
This isn't a problem - it's actually a feature since thats how shared library versioning is intended to be used. If upstream philosophy is to keep ABI compatibility in versioning [which it seems to do], just link to the specific ABI (liblua.so.5 for instance). Upstream (and your) test suite will verify this.
Not sure what having an outdated redis in a package manager has to do with letting other users keeping up to date. For instance, finding a jemalloc memory corruption would easily let me update and link against it without having to wait for redis to bump it. This is basically the same argument you just used against it ("having an outdated version").
Adding pietern's arguments:
Its just as easy.
I don't think you should expect the same terms from common users as from developers. If someone encounters a bug, the least requirement from your part would be to reproduce with the requirements you suggest. Also, should one find a bug because of different linked versions (disregarding ABI changes) - the patch would most likely benefit your codebase anyway.
Where does one draw the line of versions? Linux/unix kernel? glibc? Shared tcmalloc version we already support but not restrict? Your test suite is excellent and should be used as a safety-net for catching similar errors. Flexibility within software is A Good Thing.
Thanks for reading