554: build: do not assume that INSTALL is cp r=badboy
INSTALL is supposed to be `install` in most of the cases which
doesn't work with directories, but works perfectly with files.
Don't do this assumption.
Reported-by: Jiří Vymazal <jvymazal@redhat.com>
References: https://bugzilla.redhat.com/show_bug.cgi?id=1506251
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
INSTALL is supposed to be `install` in most of the cases which
doesn't work with directories, but works perfectly with files.
Don't do this assumption.
Reported-by: Jiří Vymazal <jvymazal@redhat.com>
References: https://bugzilla.redhat.com/show_bug.cgi?id=1506251
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
524: Don't pass a negative value to __redisAsyncCommand if redisFormatSdsCommandArgv fails r=badboy
525: Fix compilation on FreeBSD 10.3 with default compiler r=badboy
Given FreeBSD 10.3 with default compiler:
> $ cc -v
> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
> Target: x86_64-unknown-freebsd10.3
Defining _XOPEN_SOURCE to 600 on the fixed line leads to the following errors:
> cc -std=c99 -pedantic -c -O3 -fPIC -Wall -W -Wstrict-prototypes -Wwrite-strings -g -ggdb net.c
> net.c:435:29: error: use of undeclared identifier 'AF_LOCAL'
> if (redisCreateSocket(c,AF_LOCAL) < 0)
> ^
> net.c:460:21: error: use of undeclared identifier 'AF_LOCAL'
> sa.sun_family = AF_LOCAL;
> ^
> 2 errors generated.
>
AF_LOCAL is defined in sys/socket.h within ifdef __BSD_VISIBLE.
__BSD_VISIBLE could be defined in sys/cdefs.h, but it is never done if _XOPEN_SOURCE is defined.
So on FreeBSD _XOPEN_SOURCE shouldn't be defined.
Prevented uv adapter from calling write when context has been freed
The `redisLibuvPoll` function can be called with both the `UV_READABLE` and `UV_WRITABLE` flags set at the same time. Calling `redisAsyncHandleRead` can lead to a disconnect and the context being cleaned up/freed. If this happens then `redisAsyncHandleWrite` should not be called otherwise memory read/write errors and duplicate freeing will occur.
These changes prevent this from happening by having the `redisLibuvCleanup` callback indicate that the context has been cleaned. This is done indirectly by setting the context to a null pointer, maybe someone can come up with a cleaner way.
Remove trailing comma in last value of `redisConnectionType` enum. This causes a compiler warning on Solaris compilers. I'd like to build this on Solaris with `-Werror`. However, due to the trailing comma, I cannot do that.
This PR removes the trailing comma, which should prevent it causing compiler warnings on any architecture.
In case of some glib-2.0 linker error ,
make examples
can't link with glib2.0, in this case -lglib-2.0 to after includes and move to last will solve the issues.
Do not define _XOPEN_SOURCE for OS X
redis@bb1747b appears to have introduced a build regression for OS X (and possibly elsewhere, I've only tested on a local Mac environment) — in master right now `make` reliably fails on OS X as reported in redis#431.
There looks to be another PR to fix the issue in redis#433.
This PR here simply returns to the previous behavior on OS X in a minimally-invasive way. There are of course a few different ways to do this with the directives; feel free to do something different, I just care that master can build on OS X 🙇
this issue is very significant, because not allow the proper execution of the "function redisCommandArgv". The server returns "invalid bulk length".
Thanks!
Fix strerror_r on some esoteric platforms
Defining _XOPEN_SOURCE=1 causes strange behavior on Debian kfreebsd archs -- i.e. the GNU userspace with FreeBSD kernel -- when _GNU_SOURCE is not defined (the default).
Not sure I fully understand the bizarre semantics, but it seems to use the XSI-compliant interface (int strerror_r(int, char*, size_t)) but the GNU implementation (char *strerror_r(int, char*, size_t)) such that strerror_r returns 32-bits of a 64-bit char * on x86_64 kfreebsd. We would expect strerror_r to return zero when using the XSI-compliant strerror_r implementation or a 64-bit char* when using the GNU version. Instead, we get something in between!
Unless I'm missing something, being more explicit about what version of _XOPEN_SOURCE we want seems to be the prudent thing to do here -- and if folks want the GNU implementation of strerror_r for some reason they can always -D_GNU_SOURCE explicitly.
fix: Rename DEBUG to DEBUG_FLAGS
This avoids issues with environments where DEBUG is set to an arbitrary
value to force debug mode in other tools.
BREAKING CHANGE: This breaks builds that explicitely set `DEBUG` to
some value (even the empty value).
To get back the old behaviour change the `DEBUG_FLAGS`
variable now.
Cloes #381
