Library doesn't compile for ubuntu-64bit on RPi3 & RPi4 #642
Comments
|
npm?! This library has nothing to do with node.js. You may be experiencing an issue with some 3rd-party wrapper for node.js that uses this library as a code-base (there are many of those on npm). How/Why are you using Ubuntu 20.04 on a RPi B+? The download page at Ubuntu only offers images for the RPi2, RPi3, & RPi4. The RPi1 (B+) is not listed. Unless you're trying to say you're running Ubuntu on RPi3B+. I have no idea what librf24 is referring to. Its certainly not this library. |
|
I meant Ubuntu 20.04.1 on Raspberry Pi 3B+. I should have explained it better. I did a manual install of RF24LIB library as listed in the steps for RF24LIB/Linux.html. After this, my gettingstarted and other files compiled successfully, but I'm unable to execute them. The OS doesn't recognise them as executables. I tried in sudo mode as well. I tried to install 'nrf' module (natevw/node-nrf) as part of my node server - npm install nrf. This goes through the compile of various modules of RF24, RF24MESH, etc. but after a few steps fails due to this incompatible .so file. |
|
Thank you for more details. My first instinct is to try and re-create the issue, but... Its been A LONG TIME since I used node.js or npm on my RPi (I'm working with Raspbian on an RPi2), so I'm waiting on
You can see that the "SPI bindings" link is yet another node.js library titled "pi-spi" (written by the same author of "nrf" library). I'm not convinced that "nrf" library actually looks for the DLL file in "usr/local/bin/" folder seen as how it's not listed under the "nrf" lib's dependencies. Additionally, if I'm looking at the wrong library, the other library titled "node-rf24" is based on a different fork of maniacbug's RF24 library. All of these libraries are 6-years stale or just no longer maintained. Please send a link to the exact library you're referring to. ps.s did the automatic install.sh script not work for your RPi3? |
|
Thank you for your time. Before the npm package install issue, I would like to solve the Rf24 basic C++ compile issue - so feel it's linked to this basic compilation issue. |
|
sorry I have no idea. It installs and executes fine for me. Personally I don't use the C++ code due to restriction on the CSN pin options. |
|
OK. I got to the bottom of this. This is my version of what's going on! The make files were invoking the cross compiler installed on my system, and it wasn't producing an executable that I could run - same issue with the rf24lib.so as well as the gettingstarted executable. Output of ./config command detects the arm OS and sets up the C++ cross compiler. Makefile.inc in RF24 directory Am I correct? Let me know if this work around is the right thing to do! Now, onto the next challenge of making sure that my nrf interface works. I will use the gettingstarted and other files to test. |
And that left what? What did it not understand? |
|
The modified Makefile.inc: This let me avoid using the cross-compiler. Did I clarify? |
|
Run |
|
Same issue. Ran ./configure with --soc=BCM2836 These are the steps that I followed |
What's the error message now? |
Same as before - doesn't recognize the files as executables.$ sudo ./gettingstarted
|
|
It must output something during compilation, that's the error message I'm interested in. What you cause after that, not so much. |
|
There are absolutely no error messages. This is the dump of all the things that happened. Hope this helps. devuser@ubuntu:~/b/nrftest3$ mkdir rf24libs
devuser@ubuntu:~/b/nrftest3$ cd rf24libs
devuser@ubuntu:~/b/nrftest3/rf24libs$ ls
devuser@ubuntu:~/b/nrftest3/rf24libs$ git clone https://github.com/tmrh20/RF24.git RF24
Cloning into 'RF24'...
remote: Enumerating objects: 60, done.
remote: Counting objects: 100% (60/60), done.
remote: Compressing objects: 100% (40/40), done.
remote: Total 3812 (delta 25), reused 39 (delta 20), pack-reused 3752
Receiving objects: 100% (3812/3812), 1.67 MiB | 1.65 MiB/s, done.
Resolving deltas: 100% (2285/2285), done.
devuser@ubuntu:~/b/nrftest3/rf24libs$ ls
RF24
devuser@ubuntu:~/b/nrftest3/rf24libs$ cd RF24
devuser@ubuntu:~/b/nrftest3/rf24libs/RF24$ ls
COMMON_ISSUES.md Makefile RF24_config.h examples_linux nRF24L01.h utility
CONTRIBUTING.md README.md configure keywords.txt printf.h wikidoc.xslt
Doxyfile RF24.cpp doxygen-custom.css library.json pyRF24
LICENSE RF24.h examples library.properties tests
devuser@ubuntu:~/b/nrftest3/rf24libs/RF24$ ./configure --soc=BCM2836
[SECTION] Detecting arm compilation environment.
[OK] arm-linux-gnueabihf-gcc detected.
[OK] arm-linux-gnueabihf-g++ detected.
[SECTION] Detecting DRIVER
[OK] DRIVER detected:RPi.
[SECTION] Detecting OS.
[INFO] OS detected:LINUX.
[SECTION] Preparing configuration.
[SECTION] Saving configuration.
[SECTION] Cleaning previous builds.
[OK] Finished.
devuser@ubuntu:~/b/nrftest3/rf24libs/RF24$ make
arm-linux-gnueabihf-g++ -fPIC -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -Ofast -Wall -pthread -c RF24.cpp
arm-linux-gnueabihf-g++ -fPIC -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -Ofast -Wall -pthread -c utility/RPi/spi.cpp
arm-linux-gnueabihf-gcc -fPIC -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -Ofast -Wall -pthread -c utility/RPi/bcm2835.c
arm-linux-gnueabihf-g++ -fPIC -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -Ofast -Wall -pthread -c utility/RPi/interrupt.c
utility/RPi/interrupt.c: In function ‘int waitForInterrupt(int, int)’:
utility/RPi/interrupt.c:62:16: warning: ignoring return value of ‘ssize_t read(int, void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
62 | (void) read(fd, &c, 1);
| ~~~~^~~~~~~~~~~
utility/RPi/interrupt.c: In function ‘int attachInterrupt(int, int, void (*)())’:
utility/RPi/interrupt.c:156:13: warning: ignoring return value of ‘ssize_t read(int, void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
156 | read(sysFds[bcmGpioPin], &c, 1);
| ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
arm-linux-gnueabihf-gcc -fPIC -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -Ofast -Wall -pthread -c utility/RPi/compatibility.c
[Linking]
arm-linux-gnueabihf-gcc -shared -Wl,-soname,librf24.so.1 -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -Ofast -Wall -pthread -o librf24.so.1.3.9 RF24.o spi.o bcm2835.o interrupt.o compatibility.o -pthread
devuser@ubuntu:~/b/nrftest3/rf24libs/RF24$ sudo make install
[sudo] password for devuser:
[Installing Libs to /usr/local/lib]
[Installing Headers to /usr/local/include/RF24]
devuser@ubuntu:~/b/nrftest3/rf24libs/RF24$ cd examples_linux
devuser@ubuntu:~/b/nrftest3/rf24libs/RF24/examples_linux$ make
arm-linux-gnueabihf-g++ -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -Ofast -Wall -pthread -I/usr/local/include/RF24/.. -I.. -L/usr/local/lib gettingstarted.cpp -lrf24 -o gettingstarted
arm-linux-gnueabihf-g++ -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -Ofast -Wall -pthread -I/usr/local/include/RF24/.. -I.. -L/usr/local/lib gettingstarted_call_response.cpp -lrf24 -o gettingstarted_call_response
arm-linux-gnueabihf-g++ -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -Ofast -Wall -pthread -I/usr/local/include/RF24/.. -I.. -L/usr/local/lib transfer.cpp -lrf24 -o transfer
arm-linux-gnueabihf-g++ -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -Ofast -Wall -pthread -I/usr/local/include/RF24/.. -I.. -L/usr/local/lib pingpair_dyn.cpp -lrf24 -o pingpair_dyn
devuser@ubuntu:~/b/nrftest3/rf24libs/RF24/examples_linux$ sudo ./gettingstarted
sudo: unable to execute ./gettingstarted: No such file or directory
devuser@ubuntu:~/b/nrftest3/rf24libs/RF24/examples_linux$ ls -al
total 132
drwxrwxr-x 4 devuser devuser 4096 Oct 5 14:41 .
drwxrwxr-x 9 devuser devuser 4096 Oct 5 14:40 ..
-rw-rw-r-- 1 devuser devuser 588 Oct 5 14:26 Makefile
-rw-rw-r-- 1 devuser devuser 1514 Oct 5 14:26 Makefile.examples
drwxrwxr-x 2 devuser devuser 4096 Oct 5 14:26 extra
-rwxrwxr-x 1 devuser devuser 15912 Oct 5 14:41 gettingstarted
-rw-rw-r-- 1 devuser devuser 5558 Oct 5 14:26 gettingstarted.cpp
-rwxrwxr-x 1 devuser devuser 16180 Oct 5 14:41 gettingstarted_call_response
-rw-rw-r-- 1 devuser devuser 5989 Oct 5 14:26 gettingstarted_call_response.cpp
drwxrwxr-x 2 devuser devuser 4096 Oct 5 14:26 interrupts
-rwxrwxr-x 1 devuser devuser 16036 Oct 5 14:41 pingpair_dyn
-rw-rw-r-- 1 devuser devuser 5635 Oct 5 14:26 pingpair_dyn.cpp
-rwxrwxr-x 1 devuser devuser 4490 Oct 5 14:26 pingpair_dyn.py
-rw-rw-r-- 1 devuser devuser 193 Oct 5 14:26 readme.md
-rwxrwxr-x 1 devuser devuser 16204 Oct 5 14:41 transfer
-rw-rw-r-- 1 devuser devuser 5372 Oct 5 14:26 transfer.cpp
devuser@ubuntu:~/b/nrftest3/rf24libs/RF24/examples_linux$ |
|
It does say that |
|
Yes it does! That's what I was saying in my previous comment - It generates an executable but the OS doesn't seem to recognize it as an executable. |
|
Run it as non-root and post what |
|
You mean this "sudo ./gettingstarted" without sudo? BTW, I tried the whole sequence of install with Raspbian OS - swapped another micro-SD card, and that seemed to go very smooth. |
|
@sfouser1 I think @Avamander means pi@b-pi2:~/RF24/examples_linux $ file gettingstarted
gettingstarted: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=4168765ea8ed5e79136f709fa1e88e696097e52a, with debug_info, not stripped |
I had a feeling that was a problem, but I'm not as familiar with Linux as I'd like to be. Raspbian ships with some software that vanilla Ubuntu doesn't. I can't say what Raspbian has that Ubuntu doesn't to cause this error though. I know that the RF24 github action uses "ubuntu-latest", but that docker image has a slew of software pre-installed. Not to mention that the action's workflow file also installs some stuff too. @Avamander Would it be worth it to add compiling the "examples_linux" folder into the RF24 github actions? Maybe we could catch an issue like this before it arises... |
|
I wasn't familiar with what 'file' does. For comparison, for the stripped down version where I modified the Makefile.inc file on Ubuntu, I get this output: To remind you, the second output is where gettingstarted works. Hope this helps. |
|
What's the output of the first one without running it as root? |
|
It seems that it gets built as 32-bit but Ubuntu 20.04 is forced 64-bit, I think. The makefile should probably autodetect that. |
|
Did a fresh install - Let me know if I have missed anything. |
|
@sfouser1 for the fresh install: Did you use the 32-bit Ubuntu image or the 64-bit image? Here is a note directly from the Ubuntu download page for raspberry pi builds:
Not sure if that note affects this scenario. Other issues about running this library on RPi4 (also 64-bit) don't seem to have compilation problems (they also never specify what OS they're using). |
|
I understand that each of you have been responding to me on this. My intention was to point out issues that may help in the upkeep of the good work. @2bndy5 I used the 64-bit image. The reason I went to it is because I have been writing some Node JS code with MongoDB - it runs on a cloud environment now. I wanted to port it to Raspberry but had many issues with Mongo DB compatibility. Ubuntu allowed me to use the code as-is on Raspberry. I have now been able to connect to NRF on Raspberry with Ubuntu - with the work around compile that I had done earlier. |
|
I'm ready to call this issue solved, but @Avamander how would we go about future-proofing the makefile to prevent this from happening again? Does it need to detect the OS's architecture ("bitness")? To recap (according to my understanding), it would seem that @sfouser1 solution was to change
to
While I don't know how
were misunderstood by g++. @sfouser1 reported that "g++ compiler didn't understand most of the options".
apparently fixed whatever g++ was saying about them (@sfouser1 we would appreciate the actual g++ output about that). Please let me know if I've missed or misunderstood something. |
Can be overridden by
Yeah, he gave it a compiler that can't cross-compile to ARMv6. There's no 64bit ARMv8 target in the makefile, but the ARMv7 binary does run if the CPU is not forced 64bit, if I've understood materials on the internet correctly. Solution: add proper 64bit RPi4 target to the makefile. |
just a reminder, RPi3 is also 64-bit (as used by @sfouser1) |
64-bit capable, but requiring 64-bit is an another thing, the Ubuntu image might be doing that. See |
Yes, agree with your summary. |
2bndy5
changed the title
2bndy5
changed the title
|
questing to reproduce this on my RPi4, I found which flags were "unrecognized": the errors were the same when forcing the SPIDEV driver. Above output uses unmodified ps - It took a while to get ubuntu (apt updated/upgraded) to boot to console (required installing |
|
I just tried installing this lib with CMake (using the rp2xxx branch) on ubuntu 64-bit running on my RPi4... So far, our CMake implementation doesn't care about what compiler is used and it will default to the GNU compiler that ships with the OS. I was able to build and run the examples (with required sudo privilege) using the RPi driver (specific to BCM2xxx processors), but the payloads transmitted/received were incorrect (?? probably related to 64-bit vs 32-bit ??). The SPIDEV driver failed to initialize the radio (using the same pins and pin numbers as when trying the RPi driver). I feel like we're getting close to a solution for this; it just needs some polish... |
|
Thank you. Look forward to having this. I currently have a work around done but will be great to have this is a straightforward installation. |
|
making a note here to kind of bookmark my progress towards compiling 32-bit lib (and examples) in ubuntu 64-bit env. Ubuntu 64-bit needs UPDATE 😦
|
|
The main question for me is why anyone would want to run an "arm32" binary on an aarch64 host? On x86_64 it makes sense for historical reasons to support multilib libraries since there might be binary-only programs "from the past" that need 32-bit libraries to work (I know this mainly from Valve's Steam where lots of games are 32bit binaries). |
If my data is not too outdated, Raspbian is 32bit even on aarch64 hosts. |
|
I'm not an architecture expert (even talking about this stuff makes feel like a noob), but I assumed the inaccuracies in the payloads being transmitted were due to the difference in bitness of the nodes' platforms. I'll roll back some changes I made and take a another look at executing in 64-bit (the ackPL example was the most obvious due to the use of dynamic PLs) - this time I'll post my problematic examples' output (hopefully somebody with fresh eyes will pick up on something I overlooked). BTW, specifying the arm compiler in CMake brings another set of problems when linking the examples to the installed lib... It turns out that the way the PicoSDK forces the arm compiler isn't recommended because of reasons with CMake's cache (which is easily avoided since Cmake's build env basically needs to be flushed for each attempted build anyway). @Avamander |
Arduino Nano output (ackPl example)Ubuntu 64-bit output (ackPL example) - using RPi driver |
|
Okay, maybe then I got the problem wrong due to the title of this issue report ;) @2bndy5: You are building and running on a 32bit based RPi and get strange output when building the library with CMake? And if you build it "the old way" without CMake it's fine? |
|
@kripton oh, no the traditional way won't compile on 64 bit Ubuntu (running on RPi3 or RPi4 - which both have 64 bit processors); see #642 (comment) & #642 (comment). I figured I'd finally take a swing at solving this when testing the CMake for Linux implementation because I'm horribly versed in bash script. Adjusting the old configure file is best left to someone who knows what they're doing. But the CMake solution currently isn't considering the python wrapper (yet), so Ubuntu 64 bit users would still be left to their own devices for pyRF24. Testing CMake on raspbian (32 bit running on 64 bit CPUs) is successful. |
|
Alright, that means that the behaviour is incorrect when running on aarch64 (the output you posted above). When compiled by CMake since it's not possible to build it using the old scripts. Would be interesting to see how it behaves on x86_64. I'd bet it's a general problem somewhere in the source code (for example using "int" instead of "int32_t" or something.... |
|
@kripton I looked into your suggestion, but it didn't pan out... I was going to open a separate issue about the corrupted data, but then @dylviz opened a new issue #774 trying to tackle a seemingly similar problem with almost identical context. Seems my problem was the SPI baudrate was set so high (default 10MHz) that data was getting corrupted on the RPi4's SPI bus (tested 4MHz successfully 🎉 ). |
I'm using Ubuntu 20.04.1 on Raspberry Pi Model B+
The text was updated successfully, but these errors were encountered: