Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raspberry Pi 4 - compilation error #141

Closed
Talkabout opened this issue Feb 11, 2020 · 6 comments
Closed

Raspberry Pi 4 - compilation error #141

Talkabout opened this issue Feb 11, 2020 · 6 comments

Comments

@Talkabout
Copy link

Describe the bug
When trying to compile KeyDB (RELEASE_5 and unstable) I am facing the following error:

/tmp/cc8z9Ig1.s: Assembler messages:
/tmp/cc8z9Ig1.s:2877: Error: selected processor does not support `yield' in ARM mode
make[1]: *** [Makefile:308: fastlock.o] Fehler 1
make[1]: Verzeichnis „/home/xxx/KeyDB/src“ wird verlassen
make: *** [Makefile:6: all] Fehler 2

To Reproduce
Try to compile recent KeyDB source on Raspberry Pi 4

@JohnSully
Copy link
Collaborator

As a quick workaround you can comment out asm volatile ("yield"); in src/fastlock.cpp

Yield is only to make the lock more efficient, but the lock will work fine if it it is not supported. I will work on a patch to detect this features availability.

@Talkabout
Copy link
Author

Hi @JohnSully ,

thanks for the quick answer!

Your suggestion works, but there was one more issue to solve. After the change in "fastlock.cpp" the compilation process was giving me this:

/usr/include/c++/8/bits/atomic_base.h:396: undefined reference to `__atomic_load_8'
/usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:336: undefined reference to `__atomic_fetch_or_8'
/usr/bin/ld: t_stream.o: in function `xreadCommand(client*)':
/usr/include/c++/8/bits/atomic_base.h:396: undefined reference to `__atomic_load_8'
/usr/bin/ld: tracking.o: in function `disableTracking(client*)':
/usr/include/c++/8/bits/atomic_base.h:396: undefined reference to `__atomic_load_8'
/usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:328: undefined reference to `__atomic_fetch_and_8'
/usr/bin/ld: tracking.o: in function `enableTracking(client*, unsigned long long)':
/usr/include/c++/8/bits/atomic_base.h:396: undefined reference to `__atomic_load_8'
/usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:336: undefined reference to `__atomic_fetch_or_8'
/usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:328: undefined reference to `__atomic_fetch_and_8'
/usr/bin/ld: tracking.o: in function `trackingInvalidateKey(redisObject*)':
/usr/include/c++/8/bits/atomic_base.h:396: undefined reference to `__atomic_load_8'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:272: keydb-server] Fehler 1
make[1]: Verzeichnis „/home/xxx/KeyDB/src“ wird verlassen
make: *** [Makefile:6: all] Fehler 2

I was able to compile by executing the following "make"-command:

make LDFLAGS='-latomic'

Hope that helps other people facing similar issues. I will now test keydb for my use cases.

Thanks again!

Bye

@Talkabout
Copy link
Author

Hi @JohnSully ,

I have compiled KeyDB with the steps above on 2 different machines and activated active replication. Currently everything seems to work as expected.

Thanks again for your quick help!

Bye

@JohnSully
Copy link
Collaborator

Thanks. We've been testing ARM on AWS instances, but it looks like we'll have to add Raspberry Pi's to the mix.

@Talkabout
Copy link
Author

Yes, seems to be a good idea if you want to support Raspberry PIs also :)

Side question: the repository for Debian packages does not work on Raspbian Buster because it seems to be targeting Ubuntu. Is this a known issue or only something I am facing?

Bye

@JohnSully
Copy link
Collaborator

Change aaca32a modifies the code to only use yield on aarch64. There are some 32-bit arm CPUs that support yield but unless its the rPi I don't think it matters much.

VivekSainiEQ pushed a commit to VivekSainiEQ/KeyDB that referenced this issue Oct 21, 2021
When test stop 'load handler' by killing the process that generating the load,
some commands that already in the input buffer, still might be processed by the server.
This may cause some instability in tests, that count on that no more commands
processed after we stop the `load handler'

In this commit, new proc 'wait_load_handlers_disconnected' added, to verify that no more
cammands from any 'load handler' prossesed, by checking that the clients who
genreate the load is disconnceted.

Also, replacing check of dbsize with wait_for_ofs_sync before comparing debug digest, as
it would fail in case the last key the workload wrote was an overridden key (not a new one).

Affected tests
Race fix:
- failover command to specific replica works
- Connect multiple replicas at the same time (issue Snapchat#141), master diskless=$mdl, replica diskless=$sdl
- AOF rewrite during write load: RDB preamble=$rdbpre

Cleanup and speedup:
- Test replication with blocking lists and sorted sets operations
- Test replication with parallel clients writing in different DBs
- Test replication partial resync: $descr (diskless: $mdl, $sdl, reconnect: $reconnect

(cherry picked from commit 32a2584e079a1b3c2d1e6649e38239381a73a459)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants