I have a video module and I am compiling with arm-eabi-gcc cross compiler. I used following command to compile
$ arm-eabi-gcc -O2 -DMODULE -D__KERNEL__ -W -Wall -isystem /lib/modules/uname -r/build/include panel-xxxxxxx.c.
I got the following error
In file included from /lib/modules/3.13.0-32-generic/build/include/linux/types.h:5:0,
from /lib/modules/3.13.0-32-generic/build/include/linux/list.h:4,
from /lib/modules/3.13.0-32-generic/build/include/linux/module.h:9,
from panel-gis317.c:17:
/lib/modules/3.13.0-32-generic/build/include/uapi/linux/types.h:4:23: fatal error: asm/types.h: No such file or directory
compilation terminated.
And after searching on google, I found that I need to specify hardware architecture but I could not find the right usage to use arch with gccon the command line.
Can anyone please suggest me the what flags can I use to cross-compile a give .cfile(module) on the command line without using Makefile
Note: I am doing this to do insmod of .ko module on the hardware for test purpose.
BTW with the help of .o file, can we know which cross-compiler is used to compile the .c file
With the linux kernel architecture specific includes are in arch//include. Though it will probably not ensure correct compilation just setting that...
But try adding /lib/modules/$(uname -r)/build/arch/arm/include to your include path.
Here's a simple guide for building your own kernel and modules for a Pi2 on your PC:
http://lostindetails.com/blog/post/Compiling-a-kernel-module-for-the-raspberry-pi-2
They use the makefile approach.
The following link will help you
Cross-compiling of kernel module for ARM architecture
This has an example of the make file approach also.
As a side note if you want to have an Idea about the importance the "asm/types.h" in Linux you can have a look here to see what all functions use this . http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html
For knowing more about your out (.o) file use the command "file"
"file outputfilename.o" If you are cross compiling the file correctly and you are using a 64 bit system as host and your target is 32 bit you can verify it here. Your compiled output will be 32bit in proper working case .
There are a couple of things to change in how you build an out-of-core kernel module.
First, use the kernel Makefile rather than invoking the compiler directly, in order to get all the necessary CFLAGS.
Second, specify CROSS_COMPILE=arm-eabi- because other binutils are needed in the build.
Run the following command from the directory containing your module source code and Makefile:
$ make CROSS_COMPILE=arm-eabi- -C <path_to_kernel_src> M=$PWD
The Makefile for a module consisting of a single source file would contain the following line:
obj-m := panel-xxxxxxx.o
The kernel kbuild Makefile rules would take care of generating a modinfo source file, and compiling and linking those into a .ko module binary.
See Documentation/kbuild/modules.txt for more details.
Related
I'm a beginner in programming embedded devices.
While cross compiling a cryptography algorithm (using openssl), it generates an error as shown below. The program doesn't have a problem, since it runs well in the host system (Ubuntu 14).
Did anyone come across this problem ? I tried some of the already posted related questions on cross compilation but didn't solve my problem.
Thanks.
For headers issue:
Locate the headers and include it using -I switch while compilation.
For linking ussue:
$ locate libcrypto.so
You will get the directory libcrypto resides. Let's say the directory is: target_usr/lib/libcrypto.so
Now use the following command to ensure correct linking:
$ arm-linux-gnueabi-gcc hashSHA.c -Ltarget_usr/lib -lcrypto
Also make sure to add appropriate include flag and prefer to use some warning and optimization flags (-W -Wall -O2 for example)
I am trying to use the libconfig (http://www.hyperrealm.com/libconfig/ ) for a little utility I am trying to write. I am trying to build libconfig then copy the library file (libconfig.a) to my utility's directory. When I build my utility I get warnings about the architecture being incompatible. Here is one of the specific warning messages I receive.
/usr/bin/ld: warning: i386:x86-64 architecture of input file 'libconfig.a(libconfig_la-libconfig.o)' is incompatible with i386 output
I am building on a Red Hat Enterprise Linux Server release 5.10 machine (uname -m produces 'x86_64'). I tried building libconfig with the following:
configure --disable-cxx CFLAGS='-m32' LDFLAGS='-m32'
But unfortunately, this didn't seem to produce the correct library as I still see the same warnings. There are other utilities that are created during the build process and all utilities share make common make directives which are specifying CFLAGS = -m32 -Wextra -Wall -Werror -Os and LDFLAGS = -m32, so I am unable to change this behavior.
I have also tried configure --disable-cxx CFLAGS='-arch i386' LDFLAGS='-arch i386, but this command line will not build the library.
Does anyone know how to build the libconfig as a 32-bit library to be consumed correctly.
Thanks,
Mark
The configure script will ignore arguments like CFLAGS= when passed on the command line. You need to set them for the invocation of configure, i.e. something like:
env CFLAGS=-m32 LDFLAGS=-m32 ./configure --disable-cxx
When this is done, all the symbols listed in the resulting lib/.libs/libconfig.a are listed with 32-bit addresses when the library is rebuilt.
Note in the configure script help output it does say:
Some influential environment variables:
which means that they need to be environment variables, not passed in as parameters to the command
I am trying to install the driver for a serial device, and when I run the installation executable I get this error:
cc -DLINUX -c -DMODVERSIONS -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -m64 -mcmodel=kernel -I/usr/src/linux-3.8.0-27-generic/include -I/usr/src/linux-2.4/include -I/usr/src/linux/include -D__SMP__ npreal2.c
npreal2.c:40:31: **fatal error: linux/modversions.h: No such file or directory**
compilation terminated.
I don't find any solutions to this after searching the forums. I noticed that there is a modversions.h in the /usr/src/linux-3.8.0-27-generic/include/config , but not in the linux folder.
Please help!
Try passing -I /usr/src/linux-3.8.0-27-generic/include/config as an argument to make?
or
Check if the header is a part of a certain package and update the package.
You can compile modversions on your system by navigating to the linux directory (usually usr/src/linux). Inside the linux source directory, there should be a file called Rules.make. Inside this make file are build commands for making modversions.h. You can make it by running:
make update-modverfile
Now, while this will make the modversions.h library, if you compile it with a newer compiler than the libraries that this file relies on, many times you will get an error when trying to run a program that uses this header. This then turns into a nightmare.
Another method, I tried it successfully with Xubuntu 13.10:
Open /etc/default/grub
Add this Line and save it.
GRUB_CMDLINE_LINUX="CONFIG_MODVERSIONS=true"
reboot
(no, sudo update-grub,ok)
open a terminal window, enjoy.
locate modversions.h
(Please don't forget modversion'S')
I want to link an existing shared library (FlashRuntimeExtensions.so) to my C-code while compiling my own shared library. But whatever I try I always get the same error; that the file is in a wrong format. Does anybody have an idea on how to solve this?
Here is my compile command:
$ g++ -Wall ane.c FlashRuntimeExtensions.so -o aneObject
FlashRuntimeExtensions.so: could not read symbols: File in wrong format
collect2: ld gaf exit-status 1 terug
Your command line tries to generate x86 code and link it to ARM code using the native g++ available in your distribution.
This will not work. Use the Android NDK available here: http://developer.android.com/tools/sdk/ndk/index.html
The NDK includes a set of cross-toolchains (compilers, linkers, etc..) that can generate native ARM binaries on Linux, OS X, and Windows (with Cygwin) platforms.
In general .so will be linked using -l.
for example, pthread -lpthread we use.
gcc sample.c -o myoutput -lpthread
But as per #chill's statement, what you are doing in command is correct only.
I suggest you to refer the following link.
C++ Linker Error SDL Image - could not read symbols
It should be an architecture mismatch. I faced this problem once, I have solved it by building the libs in same target platform and it is obvious. If you are using linux or Unix like OS you can see that by file command and if you are using windows you can see that using Dependency Walker. You need to make sure that all the libs matches architecture.
I am trying to do a simulate with Simcore Alpha/Functional Simulator and I need to create an image file but it is giving an error like "This is not Coff Executable" how can I create an Executable Coff file from a C source in linux?
In order to do this, you'll need a cross compiling gcc that is built to output COFF files. You may need to build gcc yourself if you can't find a pre-built one.
After you download gcc, you will need to configure it. The important option is --target; so if you want to target an Alpha architecture you would do:
configure --target=alpha-coff
I would also recommend you add a prefix to the binaries and install them into a different directory so you have no problems with the compiler interacting with the system compiler:
configure --target=alpha-coff --prefix=/opt/cross-gcc --program-prefix=coff-
(this will create coff-gcc in /opt/cross-gcc/bin, you can tweak those if want something different).
Linux executable format is called ELF.
COFF is a common file format for object modules, which are linked to make an ELF file or an EXE file
In your case if you have access to gcc, you can try
gcc mysource.c -o myprogram