search

redis / redis

Redis is an in-memory database that persists on disk. The data model is key-value, but many different kind of values are supported: Strings, Lists, Sets, Sorted Sets, Hashes, Streams, HyperLogLogs, Bitmaps.
http://redis.io
Other
66.38k stars 23.73k forks source link

Unable to build redis-server 3.2.7 on Debian 7. #3790

Open matjdom opened 7 years ago

matjdom commented 7 years ago

The most recent stable sources 3.2.7 fail to build on: gcc (Debian 4.7.2-5) 4.7.2 GNU ld (GNU Binutils for Debian) 2.22

... LINK redis-server ../deps/jemalloc/lib/libjemalloc.a(nstime.o): In function nstime_get': /opt/redis_src/current/redis-stable/deps/jemalloc/src/nstime.c:120: undefined reference toclock_gettime' collect2: error: ld returned 1 exit status make[1]: *** [redis-server] Error 1 make[1]: Leaving directory `/opt/redis_src/current/redis-stable/src'

Adding -lrt to src/MakeFile: FINAL_LIBS+= -lrt ../deps/jemalloc/lib/libjemalloc.a seems to fix it.

antirez commented 7 years ago

Hello, looks like this is related to the glibc version. We upgraded Jemalloc to 4.4.0, it uses clock_gettime that should be available in recent (and not very recent) Linux systems. What Debian version are you using? Btw I'm sure @lamby knows better... in case he has a few minutes to comment. Thanks.

Hmily-LCG commented 7 years ago

Me too,centos 6.8

antirez commented 7 years ago

Ok, this is starting to sound bad... I bet there is already some open issue in the jemalloc repository.

antirez commented 7 years ago

Looks like this one? https://github.com/jemalloc/jemalloc/issues/257

IMPORTANT: Did you make distclean before compiling? Could you kindly retry?

davkg commented 7 years ago

Hey, I had the same problem on (the ancient) RHEL5 with glibc 2.5. I think this is the related issue: jemalloc/jemalloc#349 jemalloc links with librt if it detects an old version of glibc. Starting glibc 2.17, the clock_* functions were moved from librt to the main C library.

Adding -lrt to the end of FINAL_LIBS worked for me: FINAL_LIBS+= ../deps/jemalloc/lib/libjemalloc.a -lrt

matjdom commented 7 years ago

Hi, It is Linux Debian 7.11 (/etc/debian_version) glibc-2.13 (Version: 2.13-38+deb7u11)

Running 'make distclean' and 'make' results in the same error.

We build redis on remote hosts using fabric task. Script downloads stable tar.gz and builds using make, make install. Apparently I got error with recent deployment when new version of stable redis showed up. In the same environment 3.2.6 builds just fine. I tested it as well on vagrant (with puphpet/debian75-x64).

Please let me know if you want any more information or any testing from my side.

Thank you.

leehanwool commented 7 years ago

Hi I also experienced same situation on CentOS 6.8 with redis 3.2.7 redis 3.2.6 has no problem. and with redis 3.2.7, @davkg 's solution seems to be ok. (no error duing "make") with "-lrt" option is enough for using redis cluster? or need to wait fix this issue?

Thank you.

antirez commented 7 years ago

Hello @leehanwool no need to wait, -lrt totally fixes the problem.

antirez commented 7 years ago

@davkg I think you are right, but the Jemalloc issue you signaled predates the release of 4.4.0 that is what we are using in Redis 3.2.7. So I guess the fix is not working properly?

leehanwool commented 7 years ago

@antirez Thanks for confirmation!!!

davkg commented 7 years ago

Jemalloc's fix works, but it adds a librt dynamic dependency to jemalloc if it detects an old glibc version. I believe this requires you to put -lrt after the jemalloc static lib to satisfy the dependency.

With a plain Makefile, I don't think there's an easy way to automatically link a static lib's dynamic dependencies. Adding -lrt to the Makefile for everyone should be "okay" since the linker should check if -lrt is used and automatically ignore it. I'm really not sure what the best practice is here, however.

lamby commented 7 years ago

Hm, didn't we hit this -lrt issue before?

itamarhaber commented 7 years ago

Definitely seen it recently somewhere

On Feb 3, 2017 10:12 PM, "Chris Lamb" notifications@github.com wrote:

Hm, didn't we hit this -lrt issue before?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/antirez/redis/issues/3790#issuecomment-277350113, or mute the thread https://github.com/notifications/unsubscribe-auth/AFx1_Fgp4YDa80qrBN0yqGifW-H6sQ5yks5rY4otgaJpZM4L0qWB .

jinleileiking commented 7 years ago

cento6. same problem , add -lrt resolve