I'm trying to get a working cross-compiler running under Linux (Debian squeeze amd64) but I can't seem to link my files with the installed libsndfile, I'm assuming I need to cross-compile the source to target the Raspberry-Pi and link to that version. But I can't seem to find straightforward instructions on doing the ./configure and make stage to compile to the target.
Note: I followed these steps: How do I build a GCC 4.7 toolchain for cross-compiling? to get the cross compiler built and using Eclipse.
Ok, what you want to do is something which you probably cannot do within Eclipse.
Instead you need a terminal (eg xterm or gnome-terminal). The you need to run the configure script with something along the lines of:
./configure --prefix=$HOME/Arm --build=i386-linux --host=arm-unknown-linux-gnueabi
Watch the configure output to make sure that the configure script picks up the correct compiler and then do:
make && make install
When you then want to build something else that links against the Arm binaries, make sure they get the headers from $HOME/Arm/include and link against the library in $HOME/Arm/lib.
You should be able to find lots of documentation about cross compiling stuff that uses autoconf generated configure scripts on the net.
Related
I have a software (ubertooth host ) that I need to compile on ARM, I have already compiled it on a normal Linux X64 machine and it worked. The process contains :
cmake ..
make
make install
Any help regarding how to cross compile for an armhf processor?
Linux Debian Stretch has some precompiled tools for cross compiling:
crossbuild-essential-armhf
I guess that package is the one that suit your target architecture. Firstly I would try to compile with it. Probably you need to launch the build commands with the variable CROSS_COMPILE assigned properly. Eg:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
Other option is creating your own toolchain. Have a look to this other link https://crosstool-ng.github.io/ where you can see how to create your toolchain. This toolchain is compatible with buildroot.
If it does not work, maybe this link could be useful:
http://www.jumpnowtek.com/beaglebone/BeagleBone-Systems-with-Buildroot.html
It explain how to build buildroot for beaglebone. Buildroot is a build system used for embebed systems. It is easy to integrate new modules (libraries, binaries) to be build as part of the firmware. Once you have generated your binary for your target architecture, you only have to copy the necessary files into your target system.
If you decide to build with buildroot, have a look to the documentation:
https://buildroot.org/downloads/manual/manual.html
Buildroot have support for packages based on cmake, so that, even easier if you decide for it.
I am building a web server using the libwebsockets library on a TS-7800 board using the arm-linux-gcc cross compiler. Using Ubuntu. Installed CMake, OpenSSL, and libwebsockets and built the library per the instructions on Github.
I made a "hello world" C file which #includes libwebsockets.h
When I compile the executable with gcc, it compiles fine and the .exe runs.
When I compile with arm-linux-gcc, I get the following:
root#gordon-MS-7A39:/# arm-linux-gcc -o hellosockets /home/gordon/workspace/HelloCrossWorld/hello_cross.c
/home/gordon/workspace/HelloCrossWorld/hello_cross.c:3:27: libwebsockets.h: No such file or directory
It appears that arm-linux-gcc compiler cannot "see" the header file for libwebsockets. I'm guessing that the installation of the websockets library was successful because gcc can see it.
How do I enable the arm cross compiler to see the libwebsockets.h file?
Thank you for your input!
You'll need to add armhf architecture to your package management system. Perform the following actions as super user:
dpkg --add-architecture armhf
apt update
apt install libwebsockets-dev:armhf
Make sure you're also using the armhf toolchain:
apt install binutils-arm-linux-gnueabihf g++-arm-linux-gnueabihf
Alternatively, take a look at Buildroot
I was unaware of the -I and -L preprocessor options for gcc and arm-linux-gcc.
I was able to add libraries to the project and will look into creating makefiles for the project.
Ive been cross compiling my unit-tests to ensure they pass on all the platforms of interest, e.g. x86-linux, win32, win64, arm-linux
they unit tests require the CUnit library
So I've had to cross compile that also for each platform
That comes with its own autoconf stuff so you can easily cross-build it by specifying --host for configure
The question I have is where is the 'correct' place to have the CUnit libs installed for the various platforms? i.e. what should I set --prefix to for configure?
My initial guess was:
/usr/local/<platform>/lib/Cunit
i.e. setting --prefix /usr/local/<platform>
e.g. --prefix /usr/local/arm-linux-gnueabihf
which on sudo make install gives you:
/usr/local/arm-linux-gnueabihf/doc/CUnit
/usr/local/arm-linux-gnueabihf/include/CUnit
/usr/local/arm-linux-gnueabihf/lib
/usr/local/arm-linux-gnueabihf/share/CUnit
Obviously, if i don't specify a prefix for configure, each platform build overwrites the prev one which is no good
to then successfully link to these platform specific libs i need to specify the relevant lib dir for each target in its own LDFLAGS in the Makefile
Is this the right approach? Have I got the dir structure/location right for this sort of cross-build stuff? I assume there must be a defacto approach but not sure what it is..
possibly configure is supposed to handle all this stuff for me? maybe I just have to set --target correctly and perhaps --enable-multilib? all with --prefix=/usr/local?
some of the error msgs i get suggest /usr/lib/gcc-cross might be involve?
From reading more about cross compilation and the Gnu configure and build system it seems that I should just be setting the --target option for the configure step
but how do you know what the target names are? are they some fragment of the cross compiler names?
The 3 cross compilers I am using are:
arm-linux-gnueabihf-gcc-4.8
i686-w64-mingw32-gcc
x86_64-w64-mingw32-gcc
allowing me to cross-compile for ARM, win32 and win64
my host is 32 bit ubuntu, which I think might be --host i386-linux, but it seems that configure should get this right as its default
This is the procedure I finally figured out and got to work:
for each of my 3 cross-build tools (arm, win32, win64) my calls to configure looked like:
./configure --host=arm-linux-gnueabihf --build=i686-pc-linux-gnu --prefix=/usr/local/arm-linux-gnueabihf
./configure --host=i686-w64-mingw32 --build=i686-pc-linux-gnu --prefix=/usr/local/i686-w64-mingw32
./configure --host=x86_64-w64-mingw32 --build=i686-pc-linux-gnu --prefix=/usr/local/x86_64-w64-mingw32
each of these was followed by make, sudo make install
prior to calling configure for the arm cross build i had to do:
ln -s /usr/bin/arm-linux-gnueabihf-gcc-4.8 /usr/bin/arm-linux-gnueabihf-gcc
this was because the compiler had -4.8 tagged on the end so configure could not correctly 'guess' the name of the compiler
this issue did not apply to either the win32 or win64 mingw compilers
Note an additional gotcha was that when subsequently trying to link to these cross compiled CUnit libs, none of the cross compilers seemed to look in /usr/local/include by default so I had to manually add:
-I/usr/local/include
for each object file build
e.g. i added /usr/local/include to INCLUDE_DIRS in my Makefile
all this finally seems to have given me correctly cross built CUnit libs and I have successfully linked to them to produce cross built unit test binaries for each of the target platforms.
not at all easy and I would venture to call the configure option settings 'counter-intuitive' - as ever it is worth taking the time to read the relevant docs - this snippet was pertinent:
There are three system names that the build knows about: the machine
you are building on (build), the machine that you are building for
(host), and the machine that GCC will produce code for (target). When
you configure GCC, you specify these with --build=, --host=, and
--target=.
Specifying the host without specifying the build should be avoided, as
configure may (and once did) assume that the host you specify is also
the build, which may not be true.
If build, host, and target are all the same, this is called a native.
If build and host are the same but target is different, this is called
a cross. If build, host, and target are all different this is called a
canadian (for obscure reasons dealing with Canada's political party
and the background of the person working on the build at that time).
If host and target are the same, but build is different, you are using
a cross-compiler to build a native for a different system. Some people
call this a host-x-host, crossed native, or cross-built native.
and also:
When people configure a project like './configure', man often meets
these three confusing options, which are more related with
cross-compilation
--host: In which system the generated program will run.
--build: In which system the program will be built.
--target: this option is only used to build a cross-compiling
toolchain. When the tool chain generates executable program, in which target
system the program will run.
An example of tslib (a mouse driver library)
'./configure --host=arm-linux --build=i686-pc-linux-gnu': the
dynamically library is built on a x86 linux computer but will be used
for a embedded arm linux system.
I've compiled clang to use it as a cross compiler for ARM (by configuring it with ./configure --target=armv7l-unknown-linux-gnueabihf ), but when I try to compile any C code, it tries to use /usr/bin/as. I already have binutils compiled for ARM, and they are in a separate directory. How do I direct clang (or llvm) to use the assembler that I specify?
try passing the --host option to configure which will cause all the cc ar etc utilities to prefix with armv7l-unknown-linux-gnueabihf-
eg:
./configure --host=armv7l-unknown-linux-gnueabihf --build=i686-unknown-linux-gnu
Since you are using configure with hopefully autotools take a look at:
automake Cross compiling
I've always had trouble configuring from the source directory using ./configure and gave up in the end. These days I always configure from a separate directory i.e. ..//configure although I'm told it's recommended to use an absolute path for configure.
Your ARM binutils should be installed in the same prefix you're using for clang and make sure that they're in the path when you configure & build clang - i.e. PATH=/some/prefix/bin:$PATH; /configure --target=armv7l-unknown-linux-gnueabihf. If you're keeping them in separate directories for packaging purposes then make install DESTDIR= should help.
I don't generally build clang but the buildscripts I use for devkitARM might be helpful - http://sourceforge.net/p/devkitpro/buildscripts/ci/c372699fc7b4de90eb044314ce5bed04db640291/tree/
I have some old hardware with an old version of say SuSE linux running on it. Now I have this fancy development machine running Ubuntu 9.10. Some of the tools I use to compile my C app (written in Python 2.6.x) are not available on the old SuSe box. So... is it possible to compile for that old machine on my dev box?
I have the following steps in mind, but would like to cross-check before venturing off into this quest:
1. Find out which static/shared libs my app needs and find/build target version of them
2. Also find the corresponding header files
3. Feed the correct flags to gcc to use the target headers and libraries
4. Feed the correct flags to gcc to use the correct architecture (i386/i686), or do I need a cross-compilation toolchain.
5. Compile, upload and enjoy ;-)
I regularly use avr-gcc and cc65, both are cross compiling. I know that you set up a coss compiler for developing something like a gumstix, so it should be possible to do the same for old/other Linux distros, not?
C
The way I would approach this is grab your oldmachine:/usr/lib and oldmachine:/usr/include so you have e.g. newmachine:/oldmachinecompiler/usr/{lib|include} then build a cross compiler setting --sysroot to newmachine:/oldmachinecompiler/
This is really the only way to ensure that any library requirements (including libc) in your program are compatible with oldmachine.