Skip to content

Enable building against shared libraries (lua, jemalloc). 100% backwards compatible #137

Closed
wants to merge 3 commits into from

4 participants

@jbergstroem

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 --with-jemalloc-prefix=je_

@pietern
pietern commented Oct 13, 2011

The two main reasons for statically linking are:

  • Hassle-free compilation
  • Trace back exact version of linked code when debugging

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.

@jbergstroem

@pietern:
I respect your choices and won't turn this into a pro/con shared-libraries. The way I see it, it is up to the person linking to match your version (or deal with consequences). As long as its optional (and basically mandatory for some distributions - see for instance this thread as to why http://groups.google.com/group/mongodb-dev/browse_thread/thread/38e8c30606a300c3) it should be ok, no?

@antirez
Owner
antirez commented Oct 17, 2011

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.

@antirez antirez closed this Oct 17, 2011
@jbergstroem

Just wanted to address your arguments:

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 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.

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.

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:

Hassle-free compilation

Its just as easy. USE_JEMALLOC=yes vs JEMALLOC_SHARED=yes.

Trace back exact version of linked code when debugging

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

@lericson
lericson commented Dec 8, 2011

It is apparent that the authors simply do not trust ABI versioning. I for one blame the euro crisis if this is what the world has come to.

@mpalmer mpalmer added a commit to mpalmer/redis that referenced this pull request Nov 30, 2013
@mpalmer mpalmer Description: Use system jemalloc
 Upstream seem to be "difficult" on this matter. See:
  antirez#137
Author: Chris Lamb <lamby@debian.org>
f841cfc
@JackieXie168 JackieXie168 pushed a commit that referenced this pull request Sep 16, 2014
@timmaxw timmaxw Made key-value store keep track of queries that have been started but…
… have not reached their destination cores yet. Closes #137. Closes #145.
ca5472a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.