I have downloaded a cross compiler from https://docs.embeddedarm.com/TS-7400-V2#Cross_Compiling and cant see any way to install this on a linux (ubuntu) machine. I have tried using the compiler as is after extracting the files and have got part of the way there in that I can get the compiler to run after a bit of permission adjustment but there are issues with the paths it uses by default so it still fails to compile which tells me Im going down the wrong path.
Ive had a look on the site and in the forums and don't see any guidance on this kind of thing.
I'm actually not sure if there is any specific location that they need to be placed in. These are normally in /include it looks like; but I wouldn't recommend clobbering this directory on your workstation.
When building kernel modules out of tree, these usually allow you to specify a kernel or kernel header directory. This can be the root of the kernel directory in this case.
You can also build the device's kernel, and let it install to the normal location on your workstation (e.g. /lib/modules/<kernel version>/) and you should be able to point at this directory as well.
The headers_install ends up being a directory that looks a lot like /usr/include/, so you should be to install the headers anywhere and then add this directory to the cross compiler. No matter the cross compiler you use, I don't think any of them have a default kernel_headers location and you would need to either point them at the kernel directory or the install location that you used. This would be either with "-I" (capital i) to gcc or "M=" to make when building an external module.
The first thing I want to point out is that if you are using our 4.9 Debian Stretch image, you will want to follow the compiler instructions here: https://docs.embeddedarm.com/TS-7400-V2#Debian_Stretch_Cross_Compilation And you will not want to use the toolchain from the section you linked to. While the instructions should mostly work the same on an Ubuntu workstation, we do recommend using Debian if possible since it guarantees the build and destination environments are matching.
If you are using our stock TS-7400-V2 image then we're going to want to see more information/errors that you are seeing so we can better diagnose.
As a quick test (I did not test this on a booted unit, just that I could compile a binary which it sounds like that is where you are currently stuck) I took the sqlite3 example in the manual with some modifications and was able to compile without issue.
I've got the aforementioned compiler extracted to "~/ts/usr/local/opt/crosstool/arm-fsl-linux-gnueabi/" however the compiler is agnostic of the directory its located in. When done as a standard user, no permissions adjustments were required after un-tarring the toolchain. Also, all below commands can and should be run as a normal user.
Download and extract libraries for ARM on my host Debian Stretch system (NOTE! This would be the reason the binary would not run on the target once built as its being built against a different library than is present on the TS-7400-V2 stock image)
apt-get download libsqlite3-dev:armel mkdir sqlite cd sqlite/ dpkg -x ../libsqlite3-dev_3.16.2-5+deb9u2_armel.deb . cd - cp sqlite/usr/include/sqlite3.h . # Note this is used because our example includes "sqlite3.h" not <sqlite3.h> since the example is intended to have files copied over from the SBC. It would be possible to use <sqlite3.h> and then pass -I/path/to/include/ to the command line
Create the file as outlined in the wiki.
Compile the test:
~/ts/usr/local/opt/crosstool/arm-fsl-linux-gnueabi/bin/arm-linux-gcc sqlitetest.c ~/sqlite/usr/lib/arm-linux-gnueabi/libsqlite3.a -I~/sqlite/usr/include/ -o sqlitetest -ldl -lpthread -lm
From the output of the 'file' command, you can see that its been correctly compiled:
# file sqlitetest sqlitetest: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.26, not stripped
As I said, please let me know what kinds of errors you are seeing and we can better assist you.
Thanks for the information.
The compiler will generate assembler ok but will fail to generate object files as it will fail to load libz.so.1. The output of arm-linux-gcc -v shows that its configured using --with-system-zlib
Full output is shown here.
Using built-in specs.
Configured with: /work/arm-toolchains/tmp/src/gcc-4.4.4/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=arm-fsl-linux-gnueabi --prefix=/work/arm_fsl_gcc_4.4.4_multilib --with-sysroot=/work/arm_fsl_gcc_4.4.4_multilib/arm-fsl-linux-gnueabi/multi-libs --enable-languages=c,c++ --with-pkgversion=4.4.4_09.06.2010 --enable-__cxa_atexit --disable-libmudflap --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-gmp=/work/arm-toolchains/tmp/arm-fsl-linux-gnueabi/build/static --with-mpfr=/work/arm-toolchains/tmp/arm-fsl-linux-gnueabi/build/static --with-ppl=/work/arm-toolchains/tmp/arm-fsl-linux-gnueabi/build/static --with-cloog=/work/arm-toolchains/tmp/arm-fsl-linux-gnueabi/build/static --enable-threads=posix --enable-target-optspace --with-local-prefix=/work/arm_fsl_gcc_4.4.4_multilib/arm-fsl-linux-gnueabi/multi-libs --disable-nls --enable-symvers=gnu --enable-c99 --enable-long-long --enable-multilib --with-system-zlib --enable-lto
Thread model: posix
gcc version 4.4.4 (4.4.4_09.06.2010)
That is the root cause of the failure to compile as shown below, the compiler needs a 32 bit shared library libz.so to run.
~/millentech/ts-7400-v2/imx28-cross-glibc/arm-fsl-linux-gnueabi/bin/arm-linux-gcc -c donothing.c
/home/john/millentech/ts-7400-v2/imx28-cross-glibc/arm-fsl-linux-gnueabi/bin/../lib/gcc/arm-fsl-linux-gnueabi/4.4.4/../../../../arm-fsl-linux-gnueabi/bin/as: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
The compiler needs a 32 bit shared library to compile.
The earlier issues with permissions was corrected by re-extracting the original tar.bz2 file which fixed permission and link issues.
Ah, I understand. Yes, the compiler require either an x86 Linux installation or x86 compatibility on an x86_64 installation. See the documentation for your distribution on how to add this compatibility and install libraries.
An example of this in Debian can be found here: https://wiki.debian.org/Multiarch/HOWTO you will want to use the Debian cross arch of "i386" to add the needed support. From there you should be able to install "zlib1g:i386" (or similar, I cannot recall the exact package name of zlib off the top of my head, and you may need the zlib1g-dev:i386 package as well).
Hope this helps! Please let us know if you run in to any further issues or have additional questions.
An extension to this question: What is the correct way to install or setup the kernel header files so the compiler can handle include asm include files for external libraries like libxml2 and so on?
I am presuming the compiler will support that directly if the include files are located in the right place in the directory structure.