I can use libsodium 1.0.7 just fine in Ubuntu but there seems to be some issue when trying to cross-compile the libsodium library to an armv5 architecture (armv5tejl-unknown-linux-gnueabihf).
I have used ./configure --host=armv5tejl-unknown-linux-gnueabihf and then make DESTDIR=/home/myself/ARM/.
All files are generated fine (headers and static & shared library files) and I can compile and link a small test C-program which then generates a segmentation fault when it's executed on my ARMv5 target (toolchain and all is fine, everything else I compile & link not using libsodium runs perfectly fine on my ARM machine):
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "sodium.h"
int main()
{
printf("sodium_init()=%d\n",sodium_init()); // Fine, = 0
unsigned char pbk[crypto_box_PUBLICKEYBYTES];
unsigned char sbk[crypto_box_SECRETKEYBYTES];
crypto_box_keypair(pbk,sbk); // <-- Segmentation fault.
}
I have also tried the official cross-compile for ARM instructions at https://download.libsodium.org/doc/installation/index.html but configure fails due to a missing nosys.specs file. Is there somewhere I can download this (I have goggled it and it seems that it has to be specifically generated for the libsodium package)?
I managed to solve it with some help here : github.com/jedisct1/libsodium/issues/331
– Tias
Right, I finally managed to make it run on my ARMv5 target by doing
the following, many thanks for pointing me to the ARM toolchain that
contained the nosys.spec & libnosys.a files :
Downloaded ARM toolchain
gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 from
https://launchpad.net/gcc-arm-embedded
Downloaded libsodium-1.0.7 from https://download.libsodium.org/libsodium/releases/
Note: This is for making a static
libsodium.a Example below assuming home folder =
/home/user tar xvjf gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2
tar xvzf libsodium-1.0.7.tar.gz
cp ./gcc-arm-none-eabi-4_9-2015q3/arm-none-eabi/lib/nosys.spec ./libsodium-1.0.7/
cp ./gcc-arm-none-eabi-4_9-2015q3/arm-none-eabi/lib/libnosys.a ./libsodium-1.0.7/ Folder gcc-arm-none-eabi-4_9-can
be deleted at this point. cd ./libsodium-1.0.7/
mkdir ARMv5
export LDFLAGS='-static -g --specs=nosys.specs -L/home/user/libsodium-1.0.7/ -lnosys -lc'
./configure --host=armv5tejl-unknown-linux-gnueabihf --enable-static --prefix=/home/user/libsodium-1.0.7/ARMv5/
make DESTDIR=/home/user/libsodium-1.0.7/ARMv5/ Key
discoveries for me : Hint from jedisct1 where to get the
ARM toolchain containing both the nosys.spec and
libnosys.a files. Found out to add linker flag
-lc to make libsodium with libc (contaning
__libc_start_main, abort,
__libc_csu_fini and __libc_csu_init)
Related
I am trying to compile some C code with the intention of executing it on a Mips Linux o32 embedded system. I have simple C code,
#include <stdio.h>
void main(){
printf("Hello world");
}
and compiled it with
mips-linux-gnu-gcc -mfp32 helloworld.c
I know I cant run it on my linux machine so to test it first I got qemu and tried to run it with
qemu-mips ./a.out
But I am getting an error
qemu-mips: Could not open '/lib/ld.so.1': No such file or directory
Which I suspect has to do with the fact that I am including stdio.h but did not link it. How could I fix this.
I expected the code to run.
I am getting an error
qemu-mips: Could not open '/lib/ld.so.1': No such file or directory
Which I suspect has to do with the fact that I am including stdio.h but did not link it.
This is because you have compiled a dynamically linked executable. You should be able to see it in the readelf -l a.out | grep interpreter output. So when you run it the QEMU needs the target dynamic linker, but it cannot find one, because the /lib contains your host binaries and there's no ld.so.1 in it.
It can be fixed by building static executable (mips-linux-gnu-gcc -mfp32 -static helloworld.c), or by supplying the location of the target MIPS rootfs (containing lib/ld.so.1 and other needed libraries) in the QEMU command line (qemu-mips -L<path to directory with MIPS rootfs> ./a.out).
I'm trying to link the c++ library, libraw, into my c program.
windows 10 msys2. Using clion, but also trying to compile from mingw64 terminal using gcc and clang
At first, I was using the version of libraw that i got from msys2 pacman. The issue is that the version in the repo is the latest release, but it is quite old and I need the beta release of libraw to support one of my newer cameras.
I've built the libraries from source (https://github.com/LibRaw/LibRaw) in mingw, and moved the libraw.a file, and .h files into the mingw64/lib and /include folder respectively, just as they appeared when added using pacman.
The issue is that now when I compile, a long list of errors is spit out including things such as undefined references to '__cxa'
I'm wondering what is causing these compile errors and what I can do to fix them, so that I can use libraw in my project. I assume it has something to do with how I'm compiling libraw, since using the version from pacman, the exact same c and cmake code works perfectly.
Here a simplified version of my c program (note that libtiff is working just fine, can can be ignored from the samples):
#include <stdio.h>
#include <tiffio.h>
#include <libraw.h>
int main(void);
int main(void)
{
const char* libtiffVersion;
const char* librawVersion;
libtiffVersion = TIFFGetVersion();
if(libtiffVersion)
printf("%s\n", libtiffVersion);
else
printf("libtiff not found!\n");
librawVersion = libraw_version();
if(librawVersion)
printf("%s\n", librawVersion);
else
printf("libraw not found!\n");
return 0;
}
and my cmake (tried with various c standards from 90 to 23, although i don't think it mattres):
cmake_minimum_required(VERSION 3.23)
project(MyProject C)
set(CMAKE_C_STANDARD 90)
find_library(LIBRAW libraw)
find_library(LIBTIFF libtiff)
add_executable(MyProject main.c)
target_link_libraries(MyProject ${LIBTIFF} ${LIBRAW})
The linker command generated by cmake is:
cmd.exe /C "cd . && C:\msys64\mingw64\bin\gcc.exe -g CMakeFiles/MyProject.dir/main.c.obj -o MyProject.exe -Wl,--out-implib,libMyProject.dll.a -Wl,--major-image-version,0,--minor-image-version,0 C:/msys64/mingw64/lib/libtiff.dll.a C:/msys64/mingw64/lib/libraw.a -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
I read that what could be causing some of the issue, is that libraw is a c++ library (includes a c wrapper), while I'm trying to compile a c program, but trying to compile from the command line with g++, clang++, gcc with -lsupc++ with no luck. doing it this way gives me different errors, many of them including undefined reference to '__imp'
I've also tried copying the libraw.a file into my source directory compiling with a path to the .a file, with the no success.
I've tried using the binary release of the older version of libraw that I know was working, by copying the libraw.lib file to my source directory and changing my cmake file:
cmake_minimum_required(VERSION 3.23)
project(MyProject C)
set(CMAKE_C_STANDARD 90)
find_library(LIBTIFF libtiff)
add_executable(MyProject main.c)
target_link_libraries(MyProject ${LIBTIFF} ${PROJECT_SOURCE_DIR}/libraw.lib)
This time it compiles, but immediatly segfualts. Might have something to do with the binaries being built for windows using msvc while in using msys2/mingw64
Here's the error that I am getting and none of the online solutions are effectively fixing the issues that I am having. Just adding #include <stdint.h> breaks the compilation of my code. I tried installing multilib but the library seems to have no support on Ubuntu. I also tried some of the compatibility libraries but to no avail.
clang -O2 -target bpf -c hello.c -o hello.o
In file included from hello.c:2:
In file included from /usr/lib/llvm-11/lib/clang/11.0.0/include/stdint.h:52:
/usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found
#include <bits/libc-header-start.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
The code for reference. I am trying to run a compiled version of uBPF on an ARM device
#include <stdint.h>
static int idouble(int a)
{
return (a * 2);
}
int bpf_prog(void *ctx)
{
int a = 1;
a = idouble(a);
return (a);
}
This question is based on this Klyr's tutorial on how to setup user input with uBPF.
I was able to have my issue fixed actually. ARM does not have a gcc-multilib equivalent so you must install gcc-multilib-arm-linux-gnueabihf for this to work. When trying to compile and target with Clang, you must first
cd /usr/include/aarch64-linux-gnu
then
sudo cp -r . ..
It's a hacky solution but it will let you import libraries as you see fit
I am trying to cross compile Apache Portable Run-time library APR-1.5.2 lib for ARM platform. I am following below steps.
./configure --host=aarch64-unknown-linux-gnu CC=aarch64-unknown-linux-gnu-gcc
make
I am not getting any error in configure and make but when i try to link it to my code i am getting linking error.
#include <iostream>
#include <stdio.h>
using namespace std;
#include "apr_general.h"
#include "apr_network_io.h"
#include "apr_strings.h"
int main(){
apr_initialize();
std::cout<<"Welcome Program compiling "<<std::endl;
return 0;
}
When i am compiling the code using cross compiler getting error.
aarch64-unknown-linux-gnu-g++ -o Test -I ../../../../Static_APR/apr-1.5.2/include DAS.cpp ../../../../Static_APR/apr-1.5.2/.libs/libapr-1.a -lpthread
**apr-1.5.2/.libs/libapr-1.a(start.o): Relocations in generic ELF (EM: 62)**
Code compiles fine with g++.
g++ -o Test -I ../../../../Static_APR/apr-1.5.2/include DAS.cpp ../../../../Static_APR/apr-1.5.2/.libs/libapr-1.a -lpthread
Why APR lib didn't built for arm (cross compiler) even though i have used CC=aarch64-unknown-linux-gnu-gcc
Can anyone help me with correct way to build APR for cross compilation?
I am following below steps.
./configure --host=aarch64-unknown-linux-gnu CC=aarch64-unknown-linux-gnu-gcc
make
Your ./configure should include a --build. --host is the machine you are compiling for. Also see How To Configure for Android? on the Autoconf mailing list. Maybe something like:
export CPP=aarch64-unknown-linux-gnu-cpp
export CC=aarch64-unknown-linux-gnu-gcc
export CXX=aarch64-unknown-linux-gnu-g++
export LD=aarch64-unknown-linux-gnu-ld
export AR=aarch64-unknown-linux-gnu-ar
export AS=aarch64-unknown-linux-gnu-as
export RANLIB=aarch64-unknown-linux-gnu-ranlib
export CFLAGS="..."
export CXXFLAGS="..."
./configure --build=`config.guess` --host=aarch64-unknown-linux-gnu
The snippet above should ensure all the tools are available. You may need to add CFLAGS and CXXFLAGS with the appropriate header location; and an LDFLAGS with the appropriate library location.
You should verify the program for RANLIB. Its may not be what you think. For example, on one version of Ubuntu for ARM it is:
export RANLIB=aarch64-unknown-linux-gcc-ranlib-4.7
You may need to find config.guess:
$ find /usr -name 'config.guess'
/usr/lib/rpm/redhat/config.guess
/usr/share/automake-1.15/config.guess
...
Finally, you might find these scripts useful. They help build another library by setting paths and setting tools: setenv-android.sh and setenv-embedded.sh.
I'm new to developing for embedded systems, but I have installed arm-linux-gnueabi-gcc via the Linux Mint package manager and managed to build a few programs successfully.
I'm currently struggling with getting a program to compile using libusb. I've done the following:
Downloaded and unpacked the libusb 1.0.20 sources from https://sourceforge.net/projects/libusb/.
Compiled and installed them using the following commands:
~/Downloads/libusb-1.0.20 $ ./configure --host=arm-linux-gnueabi --prefix=/opt/ --disable-udev
~/Downloads/libusb-1.0.20 $ sudo make
~/Downloads/libusb-1.0.20 $ sudo make install
(The reason for sudo-ing the make commands was because I encountered permission problems related to removing old files.)
Copied a small sample file from somewhere on the internet:
#include <libusb-1.0/libusb.h>
#include <stdio.h>
int main()
{
int i=0;
libusb_context **c = NULL;
i = libusb_init(c);
printf("\nusing libusb.h\n");
return 0;
}
Tried to build it and run it with gcc:
~/Desktop/libtest $ gcc libtest1.c -o libtest1 -lusb-1.0
~/Desktop/libtest $ ./libtest1
using libusb.h
However, when I try to do the same with arm-linux-gnueabi-gcc, it can't find the library:
~/Desktop/libtest $ arm-linux-gnueabi-gcc libtest1.c -o libtest1 -lusb-1.0
/usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/bin/ld: cannot find -lusb-1.0
collect2: error: ld returned 1 exit status
Where did I go wrong? Is there something else I need to do in order to use the library? Did I fail at compiling the library for the arm compiler? I didn't include the compiler output here since it's quite long, but there are no obvious errors. This might be a very stupid question, but I'm completely clueless.