Giters

valkey-io / valkey

A new project to resume development on the formerly open-source Redis project. We're calling it Valkey, since it's a twist on the key-value datastore.

Home Page:https://valkey.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[BUG] Install fails with BUILD_TLS=yes, USE_REDIS_SYMLINKS=no

zuiderkwast opened this issue · comments

commented

I haven't had time to dig into it. What I'm doing is pretty simple, e.g.:

 make BUILD_TLS=yes USE_SYSTEMD=yes 
 make PREFIX=custom/usr USE_REDIS_SYMLINKS=no install

And then it fails with error because it can't find the aforementioned file. I was building from prepackaged version 7.2.5 available here on github.

Originally posted by @furai in #193 (comment)

Installation fails cause it can't find libhiredis_ssl.a.

commented

The problem is that the BUILD_TLS env var being pulled from .make-settings doesn't propagate to the dep build.

It's fixable by appending this after -include .make-settings in src/Makefile:

export BULD_TLS

I'm not sure if that's the right/clean way to fix it though.

commented

@michael-grunder What does this has to do with USE_REDIS_SYMLINKS=no?

commented

@zuiderkwast Nothing, I don't think anyway.

The build was failing because the second invocation of make rebuilt hiredis but without forwarding BUILD_TLS=yes to the dep makefile so Valkiey builds expecting libhiredis_ssl.a but hiredis doesn't build it.

Making the above change fixes the linker error. Isn't USE_REDIS_SYMLINKS just so we symlink redis-server instead of valkey-server, etc?

commented

Isn't USE_REDIS_SYMLINKS just so we symlink redis-server instead of valkey-server, etc?

Yes, but it seemed to be part of the problem.

@furai Do you get the same error without USE_REDIS_SYMLINKS=no?

commented

Do you get the same error without USE_REDIS_SYMLINKS=no

No that also solves the problem which does seem weird.

Interestingly when you include USE_REDIS_SYMLINKS=no the second build does far more work. Basically a complete rebuild without respect to the previously built deps. Perhaps this is actually related to the .make-settings cache.

commented

Interestingly when you include USE_REDIS_SYMLINKS=no the second build does far more work. Basically a complete rebuild without respect to the previously built deps. Perhaps this is actually related to the .make-settings cache.

Yeah, that's it! That USE_REDIS_SYMLINKS variable sets some macro in CFLAGS! We can remove that. We don't need to set that macro in CFLAGS.

See here: https://github.com/valkey-io/valkey/pull/193/files#diff-1abc5651133d108c0c420d9411925373c711133e7748d9e4f4c97d5fb543fdd9R7008

commented

@furai Workaround: Use USE_REDIS_SYMLINKS=no in make and in make install.

commented

Workaround worked for me, thanks!