Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

i386 __sync_add_and_fetch_4 build error #786

Closed
wants to merge 5 commits into
from

Conversation

Projects
None yet
4 participants
Contributor

charsyam commented Nov 22, 2012

add 32bitsync label for some people who are suffering from __sync_add_and_fetch_4

these days, many people experienced this build failure and adding CFLAGS=-march=i686 is not intuitive . because make 32bit overload user define CFLAGS. so 32bitsync will be useful for some people who wants to solve this problem.

While this obviously fixes the issue, I wonder if you don't want to just do the following, which completely eliminates the need of the user to call another target:

ARCH := $(shell getconf LONG_BIT)

CFLAGS_32 := -D32_BIT ... 32 bit specific compiler flags ...
CFLAGS_64 := -D64_BIT ... 64 bit specific compiler flags ...
CFLAGS := $(CFLAGS_$(ARCH))      ... all the other flags ...

You don't need the -D32_BITor the -D64_BIT part. It was just added to better show the usage.

I haven't looked at the current Makefile yet, but I suppose that it would make sense to adapt it to this auto-detection style.

Just my 2 cents ...

Owner

charsyam replied Nov 22, 2012

@moreaki thank you !!!

You're welcome. Are you planning on submitting a new version of your patch?

s/WARINIG/WARNING/

Also, you might want to rephrase it a bit:

@echo "WARNING: if make fails with undefined reference to `__sync_add_and_fetch_4' ,  invoke 'make 32bitsync'."
Owner

antirez commented Nov 28, 2012

Hello, I don't have full understanding about the cause of the error to merge this.

Why the 32 bit build is failing? If it is a problem in the build system of the user, probably it is not worth fixing it.
If instead we can change the Makefile so that it always works as expected with "mak 32bit" it is worth doing it.

But adding a new target IMHO is not the right solution. Comments?

Contributor

charsyam commented Nov 28, 2012

@antirez I agree with you. it doesn't look the right solution.

there are some problems..
First. "-m32" makes 32bit code. and it is different from CPU arch.
I don't know the exact reason. but maybe I think it is because of gcc version.

so. some gccs just make i386 arch code when -m32 is given. and it cause "__sync_add_and_fetch_4"
and some gccs make newer than i386 arch code.

so, it's solution is giviing -march=native or -march=i686.
but there is another problem.
gcc supports -march=native from version 4.2, but RHEL 5.x use gcc 4.1.x

so , and -march=i686 , but it cann't reflect the new cpu model. so I am nervous to add this option directly.

but. many users encounter this problem.

that's why I add new compile label for this problem. I know it is not elegant.

moreaki commented Nov 28, 2012

The explanation for this phenomena is offered here:

http://stackoverflow.com/questions/130740/link-error-when-compiling-gcc-atomic-operation-in-32-bit-mode

Now, my suggestion above in this thread is non-intrusive and solves the issue at hand without a new target. I'm a bit busy with another project at the moment, otherwise I'd prepare a patch myself. @charsyam 👍 I'm sure you can prepare a patch and I'll happily review it.

@charsyam charsyam closed this Mar 30, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment