Define _XOPEN_SOURCE appropriately on NetBSD.

[ptjm]

At least with NetBSD 5 and 6, _XOPEN_SOURCE needs to be defined as it is for Linux. My inclination would be to use this definition as the default and special case the systems where it doesn't work, but this change works for me. I've tested this on both NetBSD 5 and 6, on 32- and 64-bit systems.

Full disclosure: to link on 32-bit systems, I also had to add a -march setting to CFLAGS. Otherwise I get an undefined error for __sync_add_and_fetch_4. I think that's just a general gcc issue and I don't have a patch for it.

Thanks.

[antirez]

Hello, I just merged and back ported to 2.6, 2.8 braches. Thank you.

About the -march, a different approach could be to switch off atomic increments and use the old mutex code when the target is forced to 32bit... Otherwise there is the generic -march=native that could also be a solution, but I wonder if this is going to create problems when compiling on a system and running on aother system with a different CPU type, even if of the same family.

[charsyam]

@antirez I think using -march=natvie is not a good solution about gcc 4.1.x
I did simple test in gcc 4.1.2(RHEL 5.4)

gcc -march=native test.c
test.c:1: error: bad value (native) for -march= switch
test.c:1: error: bad value (native) for -mtune= switch

and this is manual for gcc
http://gcc.gnu.org/gcc-4.2/changes.html

in document, you can find gcc supports -march=native from 4.2.x

as you know, many IT companies still use RHEL 5.x version yet.

and I'm trying to reproduce this situation now. :)

[antirez]

Thanks @charsyam, maybe we could simply do... -march=486 or alike... that is more past-compatible, this should always be backward compatible unless people are using a true 386 that is no longer supported even by Linux :-)

[charsyam]

@antirez yes, I think it is somewhat complicated problem. that's why I sent you some wired patch. and I have a question. Do you have any plan to support like FAQ for this problem.
In redis, There are 2 common build problems but not bugs.
first, this problem.
second, about "make distclean"
I think it is better way to give FAQ for these problems

[charsyam]

@antirez and, If you want, I can write FAQ just about "build problems" ,
I already posted it in my blog.(http://charsyam.wordpress.com/2012/11/22/%EC%9E%85-%EA%B0%9C%EB%B0%9C-%EC%95%97-redis-%EA%B0%80-%EB%B9%8C%EB%93%9C%EA%B0%80-%EC%95%88%EB%90%98%EB%8A%94-%EA%B2%83-%EA%B0%99%EC%95%84%EC%9A%94-%EC%9D%98-%EB%8C%80%EC%B2%98%EB%B2%95/)
it is written in Korean. but I can translate it for other redis user.

[charsyam]

@antirez I reproduced it. just using rhel 5.4(32bit) and if you want i will give you a mail which contains ip and user and passwd

[antirez]

@charsyam thanks and sorry for not replying early, I had a family problem that took me AFK for some time.

From all your reports I see that:

• We can't use -march=native because it is not just unsupported, but generates errors with older GCC versions.
• We could use -march=pentium, but probably this is going to create the same issue if the processor is of different type, like if we compile under Linux.

At this point I believe the solution you proposed is the best: document the issue.

We can write a FAQ in the documentation "compiling Redis a 32 bit Redis binary using a 64 bit system". However, what about to display a big node about the issues it is possible to encounter when "make 32bit" is performed, directly in the user screen? This seems like the best options we have.

About "make distclean", there are multiple issues about it, what are you referring to exactly? For instance you need make distclean to build a 32 bit executable. But also, you need a make distclean if you want to change from -O2 to -O3 otherwise your switch will be ignored.

Cheers and thanks for your help!

[charsyam]

@antirez it is not only about "compiling Redis a 32 bit Redis binary using a 64 bit system". it can also happen "compiling Redis a 32 bit Redis binary using a 32 bit system.". I sent a patch add it README file

and I just mentioned about "make distclean" issue redis build.
if someone fails redis build, it never retries to build deps folders because of .make-xxx files.