There are two issues I've found with the makefile that is breaking make && make install on a fresh redis tarball.

First, there is the Makefile.dep file. The file is getting created as expected but the following persist-settings target has a dependency on distclean which has a dependency on clean which deletes the file. This means that any two invocations of make all will rebuild everything as you're creating a new Makefile.dep each run, dirtying the entire process.

Second, the deps/Makefile target for jemalloc calls ./configure. This means that any build that uses jemalloc gets a new deps/jemalloc/Makefile each time, dirtying the entire jemalloc build. This dirties all of the redis objects that depend on jemalloc.

Note that this is going to mess with people trying to package redis with the new BUILD_TLS option in redis 6. If you ran make like make BUILD_TLS=yes && make install (which is what everyone is basically going to be doing) you are rebuilding redis without TLS the second time because it's triggering a rebuild and BUILD_TLS is not set.

Comment From: joancafom

I am facing this issue too, when I try to compile redis using make BUILD_TLS=yes && make install, binaries do not support TLS. If I take a look at the shared object dependencies of redis-server I obtain the following:

$ ldd ./redis-server
    linux-vdso.so.1 (0x00007fffc8329000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2eb9647000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2eb9642000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f2eb9638000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2eb9617000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2eb9456000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2eb9bca000)

Now, I'll recompile with make BUILD_TLS=yes && make install BUILD_TLS=yes and voilà:

$ ldd ./redis-server
    linux-vdso.so.1 (0x00007ffdd9d25000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8e951c7000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8e951c2000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f8e951b8000)
    libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f8e95126000)
    libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f8e94e3d000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8e94e1c000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8e94c59000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f8e95750000)

TLS related dependencies now appear.

Comment From: javsalgar

I found a weird issue. I'm compiling redis with BUILD_TLS=yes in both Ubuntu and Debian. In Debian all the binaries are linked to libssl and libcrypto. However, this is not the case of Ubuntu, where all the binaries are linked to libssl and libcrypto except redis-benchmark.

Debian:

ldd redis-benchmark
        linux-vdso.so.1 (0x00007ffed55fa000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6f9685a000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6f96855000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6f9684b000)
        libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f6f967b9000)
        libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f6f964d0000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6f964af000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6f962ec000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6f96d29000)

Ubuntu:

 ldd bin/redis-benchmark
        linux-vdso.so.1 (0x00007ffef473c000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f68d74ee000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f68d72ea000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f68d70e2000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f68d6ec3000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f68d6ad2000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f68d7dd8000)

Both are compiling redis 6.0.6, and the openssl versions are

Debian:

ii  openssl                   1.1.1d-0+deb10u3            amd64        Secure Sockets Layer toolkit - cryptographic utility

Ubuntu:

ii  openssl                     1.1.1-1ubuntu2.1~18.04.6            amd64        Secure Sockets Layer toolkit - cryptographic u

Any clue?

Comment From: yossigo

I noticed the double make issue recently. I'll take a closer look at these issues.

Generally speaking, I'm not very happy with the .persist-settings mechanism which is fragile and somewhat unexpected. It has no benefit for anyone who's running a one-off build, so it's only there for Redis developers who iterate builds. But then a more explicit and predictable configuration mechanism might do better.