I build embedded machines that run an RT_PREMPT version of Linux. It's an Ubuntu 10.04 installation running an Linux 2.6 kernel. Yes, it's an old kernel, but I'm stuck with it for awhile.
When I compiled the kernel, I used gcc version 4.4. On this system, there is a kernel module I have been compiling successfully for three years.
From my Makefile...
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) \
modules
My current project requires support for c++14, so I updated gcc and g++ to version 5.1.0 by building from source. All my user-mode software compiles, but when I went to build an updated version of my kernel module, I get the following error right away:
make[1]: Entering directory `/usr/src/linux-headers-2.6.32-54-generic'
CC [M] /home/tbj/srcroot/ctsengine-hg/CtsRt/ctsrt_main.o
In file included from include/linux/compiler.h:40:0,
from include/linux/stddef.h:4,
from include/linux/list.h:4,
from include/linux/module.h:9,
from /home/tbj/srcroot/ctsengine-hg/CtsRt/ctsrt_main.c:31:
include/linux/compiler-gcc.h:86:30: fatal error: linux/compiler-gcc5.h: No such file or directory
In short:
fatal error: linux/compiler-gcc5.h: No such file or directory
If I use gcc 4.4 again (I left it installed on my computer in a different directory), it compiles and runs perfectly.
Obviously, I'm missing something. Is it not possible to compile a kernel module with a newer version of the compiler than what the operating system was compiled with? That seems unlikely to me. Is there a configuration step I'm missing? Is there a system variable I need to update? Are there extra headers I'm supposed to download? I ran apt to update build-essential, but it was up to date. I have the source and headers for the kernel on my system. I'm not sure what else I would download.
Any insights to this problem are greatly appreciated. Thank you in advance.
Your kernel version is too old and it is missing linux/compiler-gcc5.h.
The header is included from linux/compiler-gcc.h and its name is generated by preprocessor macro based on current compiler version:
#define _gcc_header(x) __gcc_header(linux/compiler-gcc##x.h)
This header was introduced around version 3.18.
You might try to get this file from a newer kernel source and put in into include/linux.
Open a terminal and type:
$ ls -r /usr/src/linux-headers-$(uname -r)/include/linux/ | \
grep -P "compiler-gcc\d.h" | \
head -n 1
this will hopefully output the latest gcc header suitable for your linux kernel.
In my case it is compiler-gcc4.h. Now you can link this file to compiler-gcc5.h in the following way:
$ sudo ln -s /usr/src/linux-headers-$(uname -r)/include/linux/compiler-gcc4.h \
/usr/src/linux-headers-$(uname -r)/include/linux/compiler-gcc5.h
Related
I'm getting the following issue when trying to run make on the HTK library:
(cd HTKLib && make HTKLib.a) \
|| case "" in *k*) fail=yes;; *) exit 1;; esac;
make[1]: Entering directory '/home/william/speech/htk/HTK-3.4.1/htk/HTKLib'
gcc -m32 -ansi -D_SVID_SOURCE -DOSS_AUDIO -D'ARCH="x86_64"' -Wall -Wno-switch -g -O2 -I. -DPHNALG -c -o HGraf.o HGraf.c
In file included from HShell.h:40:0,
from HGraf.c:54:
/usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No such file or directory
#include <bits/libc-header-start.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
<builtin>: recipe for target 'HGraf.o' failed
make[1]: *** [HGraf.o] Error 1
make[1]: Leaving directory '/home/william/speech/htk/HTK-3.4.1/htk/HTKLib'
Makefile:96: recipe for target 'HTKLib/HTKLib.a' failed
make: *** [HTKLib/HTKLib.a] Error 1
I'm unsure what to do about this error. The libc-header-start.h file is present on my system:
$ find /usr -name libc-header-start.h
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h
Running gcc -H -fsyntax-only /usr/include/stdio.h appropriately returns
. /usr/include/x86_64-linux-gnu/bits/libc-header-start.h
.. /usr/include/features.h
... /usr/include/x86_64-linux-gnu/sys/cdefs.h
etc.
Also, compiling and running a sanity-check C file works fine (simply executing printf("hello!"); in its main method).
Apologies if this is a well-known error - my experience with C libraries stops at compiling and installing them using make.
UPDATE
Per the accepted answer below I executed sudo apt-get install gcc-multilib to install the missing 32 bit libraries.
Afterwards I got an error with a similar cause: "/usr/bin/ld: cannot find -lX11" error when installing htk. I resolved this by executing sudo apt-get install libx11-dev:i386 libx11-dev to retrieve the missing 32 bit library.
The -m32 is telling gcc to compile for a 32-bit platform. On a 64-bit machine, gcc normally only comes with 64-bit libraries. You have two options:
Install 32-bit headers and libraries. Here's how you'd do this on Ubuntu.
Run this command:
sudo apt-get install gcc-multilib
Compile for 64-bit instead. Modify this line in the file named configure:
CFLAGS="-m32 -ansi -D_SVID_SOURCE -DOSS_AUDIO -D'ARCH=\"$host_cpu\"' $CFLAGS"
Delete -m32, giving you:
CFLAGS="-ansi -D_SVID_SOURCE -DOSS_AUDIO -D'ARCH=\"$host_cpu\"' $CFLAGS"
Run ./configure, then make clean, then make
However, I would recommend against this approach. The library authors went out of their way to make this build for 32 bits on a 64 bit system, and I can't guarantee that it will work correctly if you do this. (It does compile, though.)
Below is one way to debug and fix this issue. Since most linux installations differ in one way or another, YMMV.
Find which package installed libc-header-start.h.
$ dpkg -S libc-header-start.h
libc6-dev:amd64: /usr/include/x86_64-linux-gnu/bits/libc-header-start.h
On a working system, /usr/include/bits is a symlink to /usr/include/x86_64-linux-gnu/bits. Running dpkg search gives us:
$ dpkg -S /usr/include/bits
libc6-dev-i386: /usr/include/bits
Installing libc6-dev-i386 creates the symlink and the error is addressed.
However, subsequently I ran into a linker error with the linker not being able to find libgcc (-lgcc). Apparently Linux default linker needs libgcc in most cases. Further debugging the issue with linker verbosity enabled lead me to missing lib32gcc-10-dev package.
In short, unless a very controlled build environment is desired, just install gcc-multilib package when using -m32 (needed for gcc or clang). For C++, g++-multilib is also required.
I'm trying to install and test c library c-algorithms from Github.
https://github.com/fragglet/c-algorithms/blob/master/test/test-queue.c
When I try to test the installation from the generated test folder with:
gcc -o test-arraylist `pkg-config --cflags --libs libcalg-1.0` test-arraylist.c
I get the following error massage:
test-arraylist.c:30:23: fatal error: arraylist.h: No such file or directory
compilation terminated.
I use a Vagrant box: ubuntu/xenial32 with Ubuntu 14.04.5 LTS
Prior to installation of c-algorithms:
sudo apt-get install autoconf
sudo apt-get install libtool
sudo apt-get install pkg-config
To install the library I have done following:
sudo ./autogen.sh
sudo ./configure
sudo make
sudo make install
Any help would be highly apriciated
The test-arraylist.c has line #include "arraylist.h" but it is under the libcalg subdirectory not directly in the include path.
libcalg subdir should be added to the include path or you have to modify the include like #include "libcalg/arraylist.h"
If you want only run the tests, then run the
sudo make check from the build root (in your case it is the source root)
This is probably going to be stomped on by process-fetishizers.
But.
When you build in a Unix/Linux operating system (and derivatives like RTEMS), you are building off other people's libraries - so you need those libraries and their header files ( just like c-alg... ) installed in locations that your compiler can find.
To find a file that is associated with a package, use dpkg as explained here:
https://askubuntu.com/questions/481/how-do-i-find-the-package-that-provides-a-file
But you have another problem you might not be aware of. You are trying to compile a test program using a gcc command when the software uses GNU autoconf automake and probably libtool to function PROPERLY.
Perhaps you don't understand you need to make sure autoconf, automake, and then libtool find the right configuration from one directory system to another. Fedora puts files in differing spots from Ubuntu distros.
Instead run:
autoreconf -fvi
first in the top level directory and see if this finds your header file.
THEN you run
./configure
and then
make test/check
(whichever it uses, some use recipe "all-tests", etc.)
make all
This would make all if your system is ready to handle them.
I'm trying to get address sanitizer working on FreeBSD 10.1 Release, but whenever I try to compile a program with -fsanitize=address I get undefined references to _asan_stack_malloc_1 etc, etc. I found
https://forums.freebsd.org/threads/gcc-clang-address-sanitizer.47985/ on google but the suggestion of adding -L/usr/local/lib -I/usr/local/include didn't resolve the linking issue. I tried the llvm binaries for FreeBSD but when I go to compile with that clang I get /usr/bin/../lib/clang/3.6.0/lib/freebsd/libclang_rt.asan-x86_64.a , no such file or directory. . Either way I'm not sure what library I need to link or where it is.
Below is the program I tried compiling and here is the command I used,
clang -fsanitize=address san.c
#include <stdio.h>
int main(void)
{
return 0;
}
As an alternative to building LLVM, as suggested in this answer on Unix SE, you can install llvm37 from ports, which supports AddressSanitizer, and build with that:
# pkg install llvm37
$ clang37 -fsanitize=address san.c
To use asan on FreeBSD you can build llvm with asan support as shown below or you can install from packages/ports like in Kevinoid's answer.
Step one, grab the latest stable llvm source.
fetch http://llvm.org/releases/3.9.0/llvm-3.9.0.src.tar.xz
Now uncompress the llvm source directory.
tar -xvf llvm-3.9.0.src.tar.xz
Next change directory to llvm and grab the clang source files.
cd llvm-3.9.0.src/tools && fetch http://llvm.org/releases/3.9.0/cfe-3.9.0.src.tar.xz
Uncompress clang.
tar -xvf cfe-3.9.0.src.tar.xz
Enter the projects directory and grab compiler-rt.
cd ../projects && fetch http://llvm.org/releases/3.9.0/compiler-rt-3.9.0.src.tar.xz
Uncompress compiler-rt.
tar -xvf compiler-rt-3.9.0.src.tar.xz
Goto the root llvm directory and make a build directory for cmake.
cd ../ && mkdir build && cd build
Use cmake to setup the llvm build.
cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON [-DLLVM_ENABLE_WERROR=ON] [-DLLVM_TARGETS_TO_BUILD=X86] -DBUILD_SHARED_LIBS=ON ../
Build llvm and go grab some tea, it will take a bit.
make -j12
If the build worked you should be left with clang with asan support. Make sure to remove the old compiler, /usr/bin/clang, /usr/bin/clang++ and /usr/bin/cc.
Then install the new clang by doing sudo make install. Finally you will probably want to link /usr/bin/cc to /usr/local/bin/clang by running sudo ln /usr/local/bin/clang /usr/bin/cc.
After doing all these steps you should be able to compile code with the -fsanitize=address compile option.
I have a problem while compiling Vim 7.4 under AIX 6.1.
My options for the configure script are: "--prefix /opt/freeware/bin" and "--enable-pythoninterp".
There where no Errors while running the configure Script but when I try to run "make" I get the error message:
cd src && make first
cc -qlanglvl=extc89 -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_ATHENA -DFUNCPROTO=15 -g -o objects/regexp.o regexp.c "regexp_nfa.c"
line 4410.1: 1506-046 (S) Syntax error.
make: 1254-004 > The error code from the last command is
1.
Stop. make: 1254-004 The error code from the last command is 2.
Stop.
Does anyone know what to do?
I had compiled Vim 7.4 in my home directory so I know that there is a workaround but I can't find it anymore.
AIX's built in make (based on standard AT&T make) is not compatible with the Makefiles built by autoconf tools. Use GNU make (gmake) instead. You may already have it installed (check /opt/freeware/bin), install from the Linux Toolbox for AIX set (from IBM), or from one of the websites providing prebuilt GNU tools for AIX systems (perzl, bullfreeware, etc). Just provide an alias from make to gmake, or override the use of make in the Makefile itself.
I installed liblapack-dev and its dependencies using Synaptic, and I included <lapack.h> in my code.
If I try to compile my program like this...
mpicc program.c -llapack -o output
...I get the following error:
program.c:4:20: fatal error: lapack.h: No such file or directory
compilation terminated.
How can I fix this? I've already spent hours googling for a solution but nothing helped.
I'm using Linux Mint, but I tried the same thing on the latest version of Ubuntu and it still wouldn't work. Same thing when I try "eliminating" MPI from my program and compiling with gcc.
I experienced a similar issue on Debian. I noticed that
dpkg -L liblapack-dev
did not return a single header file. So I did some searching with apt-cache and found what appears to be C headers. After installing via
sudo apt-get install liblapacke-dev
(note the extra e!), I was able to compile a minimal working example, found here. Modifying the include at the top to read
#include <lapacke.h>
and compiling with
gcc -llapack lapack_example.c
successfully runs on my system. Hope this helps someone.
Answering because it doesn't fit in a comment:
The manual says:
Standard C language APIs for LAPACK
collaboration LAPACK and INTEL Math Kernel Library Team
LAPACK C INTERFACE is now included in the LAPACK package (in the lapacke directory)
LAPACKE User Guide
Updated: April 20, 2012
header files: lapacke.h, lapacke_config.h, lapacke_mangling.h, lapacke_utils.h
so perhaps you need to
#include <lapacke.h>