I am trying to run some programs on a BeagleBone Black on the 'out of the box' operating system but I keep getting issues when compiling with gcc. This is best illustrated when trying to compile a simple hello world program:
#include <stdio.h>
int main(void)
{
printf("Hello World\n");
return 0;
}
The output from compiling and running this is:
debian#beaglebone:~$ g++ helloworld.c -o test
debian#beaglebone:~$ ./test
Hello World
debian#beaglebone:~$ gcc helloworld.c -o test
debian#beaglebone:~$ ./test
./test: line 27: typedef: command not found
./test: line 36: typedef: command not found
./test: line 37: typedef: command not found
./test: line 38: typedef: command not found
./test: line 39: typedef: command not found
./test: line 42: typedef: command not found
./test: line 43: typedef: command not found
./test: line 44: typedef: command not found
./test: line 45: typedef: command not found
./test: line 46: typedef: command not found
./test: line 47: typedef: command not found
./test: line 52: __extension__: command not found
./test: line 53: __extension__: command not found
./test: line 61: __extension__: command not found
./test: line 62: __extension__: command not found
./test: line 68: __extension__: command not found
./test: line 69: __extension__: command not found
./test: line 70: __extension__: command not found
./test: line 71: __extension__: command not found
./test: line 72: __extension__: command not found
./test: line 73: __extension__: command not found
./test: line 74: __extension__: command not found
./test: line 75: __extension__: command not found
./test: line 76: __extension__: command not found
./test: line 77: __extension__: command not found
./test: line 78: syntax error near unexpected token `}'
./test: line 78: `__extension__ typedef struct { int __val[2]; } __fsid_t;'
debian#beaglebone:~$
My gcc and g++ versions are:
debian#beaglebone:~$ gcc --version
gcc (Debian 4.7.2-5) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
debian#beaglebone:~$ g++ --version
g++ (Debian 4.7.2-5) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Has anyone come across this problem before? I've had a look around but none of the fixes seem applicable. Thanks in Advance.
edit: output of gcc -v helloworld.c -o outputFile
debian#beaglebone:~$ gcc -v helloworld.c -o outputFile
Using built-in specs.
COLLECT_GCC=gcc
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
COLLECT_GCC_OPTIONS='-E' '-v' '-o' 'outputFile' '-march=armv7-a' '-mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mthumb' '-mtls-dialect=gnu'
/usr/lib/gcc/arm-linux-gnueabihf/4.7/cc1 -E -quiet -v -imultilib . -imultiarch arm-linux-gnueabihf helloworld.c -o outputFile -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -mtls-dialect=gnu
ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf"
ignoring nonexistent directory "/usr/lib/gcc/arm-linux-gnueabihf/4.7/../../../../arm-linux-gnueabihf/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/arm-linux-gnueabihf/4.7/include
/usr/local/include
/usr/lib/gcc/arm-linux-gnueabihf/4.7/include-fixed
/usr/include/arm-linux-gnueabihf
/usr/include
End of search list.
COMPILER_PATH=/usr/lib/gcc/arm-linux-gnueabihf/4.7/:/usr/lib/gcc/arm-linux-gnueabihf/4.7/:/usr/lib/gcc/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/4.7/:/usr/lib/gcc/arm-linux-gnueabihf/
LIBRARY_PATH=/usr/lib/gcc/arm-linux-gnueabihf/4.7/:/usr/lib/gcc/arm-linux-gnueabihf/4.7/../../../arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/4.7/../../../:/lib/arm-linux-gnueabihf/:/lib/:/usr/lib/arm-linux-gnueabihf/:/usr/lib/
COLLECT_GCC_OPTIONS='-E' '-v' '-o' 'outputFile' '-march=armv7-a' '-mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mthumb' '-mtls-dialect=gnu'
The secret is revealed in the verbose compiler output:
COLLECT_GCC_OPTIONS='-E' [...]
-E provokes GCC just to preprocess the input, so the resulting 'test' file actually is the input file with the single include resolved (recursively).
Since you did not add the -E parameter explicitely, gcc obviously did so implicitely. According to this discussion on gcc.gnu.org, your version of gcc seems to have this compiled in, so I assume you would have to recompile gcc from fixed source code - or get a properly compiled gcc version from whichever source (Debian repositories?).
You can try to use \gcc instead of gcc. The leading backslash tells the shell to ignore any aliases which might shadow the executable of the same name. You can also use the full gcc path to achieve the same.
You can also check there is no aliases or functions named gcc using type gcc, whatis gcc or maybe which gcc or even using a lower level set|grep gcc.
Related
I installed MinGW-w64 using win-builds.
It all went ok but then when I compile a file using
gcc -Wall -o prog.exe main.c
I get this error
cc1.exe: fatal error: Files/win-builds-1.5.0/include: No such file or directory
compilation terminated.
I have updated gcc path. I get the same error when I try to build on eclipse.
The location where win-builds put all the files is C:\Program Files\win-builds-1.5.0\ and the folder \include\ exists.
My guess is that cc1.exe is trying to access C:\Program Files\win-builds-1.5.0\include but, for some reason it is separating C:\Program of Files\win-builds-1.5.0\include.
How can I get the compiler to work?
EDIT:
Here is the code to be compiled
/*
* main.c
*
* Created on: 13/06/2018
* Author: haslima
*/
#include <stdio.h>
int main()
{
printf("Hello World");
return 1;
}
EDIT:
when I run gcc -v -c -o prog.exe main.c I get this output:
Reading specs from c:/program files/win-builds-1.5.0/bin/../lib64/gcc/x86_64-w64-mingw32/4.8.3/specs
COLLECT_GCC=gcc
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.8.3/configure --prefix=/opt/windows_64 --with-sysroot=/opt/windows_64 --libdir=/opt/windows_64/lib64 --mandir=/opt/windows_64/man --infodir=/opt/windows_64/info --enable-shared --disable-bootstrap --disable-multilib --enable-threads=posix --enable-languages=c,c++ --enable-checking=release --enable-libgomp --with-system-zlib --with-python-dir=/lib64/python2.7/site-packages --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --with-gnu-ld --verbose --enable-java-home --with-java-home=/opt/windows_64/lib64/jvm/jre --with-jvm-root-dir=/opt/windows_64/lib64/jvm --with-jvm-jar-dir=/opt/windows_64/lib64/jvm/jvm-exports --with-arch-directory=amd64 --with-antlr-jar='/home/adrien/projects/win-builds-1.5/slackware64-current/d/gcc/antlr-*.jar' --disable-java-awt --disable-gtktest --build=x86_64-slackware-linux --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
Thread model: posix
gcc version 4.8.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-o' 'prog.exe' '-mtune=generic' '-march=x86-64'
c:/program files/win-builds-1.5.0/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.3/cc1.exe -quiet -v -iprefix c:\program files\win-builds-1.5.0\bin\../lib64/gcc/x86_64-w64-mingw32/4.8.3/ -D_REENTRANT -IC:/Program Files/win-builds-1.5.0/include main.c -quiet -dumpbase main.c -mtune=generic -march=x86-64 -auxbase-strip prog.exe -version -o C:\Users\hasli\AppData\Local\Temp\ccnpAzB7.s
GNU C (GCC) version 4.8.3 (x86_64-w64-mingw32)
compiled by GNU C version 4.8.3, GMP version 5.1.3, MPFR version 3.1.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "c:/program files/win-builds-1.5.0/lib64/gcc/../../lib64/gcc/x86_64-w64-mingw32/4.8.3/include"
ignoring nonexistent directory "/opt/windows_64/opt/windows_64/lib64/gcc/x86_64-w64-mingw32/4.8.3/../../../../include"
ignoring duplicate directory "c:/program files/win-builds-1.5.0/lib64/gcc/../../lib64/gcc/x86_64-w64-mingw32/4.8.3/include-fixed"
ignoring duplicate directory "c:/program files/win-builds-1.5.0/lib64/gcc/../../lib64/gcc/x86_64-w64-mingw32/4.8.3/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "/opt/windows_64/mingw/include"
ignoring nonexistent directory "C:/Program"
#include "..." search starts here:
#include <...> search starts here:
c:\program files\win-builds-1.5.0\bin\../lib64/gcc/x86_64-w64-mingw32/4.8.3/include
c:\program files\win-builds-1.5.0\bin\../lib64/gcc/x86_64-w64-mingw32/4.8.3/include-fixed
c:\program files\win-builds-1.5.0\bin\../lib64/gcc/x86_64-w64-mingw32/4.8.3/../../../../x86_64-w64-mingw32/include
End of search list.
cc1.exe: fatal error: Files/win-builds-1.5.0/include: No such file or directory
compilation terminated.
From [MinGW]: Getting Started (including bolds):
MinGW may have problems with paths containing spaces, and if not, usually other programs used with MinGW will experience problems with such paths. Thus, we strongly recommend that you do not install MinGW in any location with spaces in the path name reference. You should avoid installing into any directory or subdirectory having names like "Program Files" or "My Documents", etc.
So, the solution is pretty straightforward:
Uninstall your current version (might not be necessary, but there's no point keeping something broken)
Make sure to read all installation requirements / notes
Install it in a SPACE free dir
I should have thought of this sooner, as I don't install stuff in default dirs (e.g. I have MinGW installed in "f:\Install\pc064\MinGW\MinGW-W64\x86_64-8.1.0-posix-seh-rt_v6-rev0").
I'm trying to install LISTSERV by lsoft.com on redhat. The package comes with a compiler test, and this test is failing.
The OS is:
Red Hat Enterprise Linux Server release 6.8 (Santiago)
The Arch is:
x86_64
The compiler is:
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-17)
Here's the full "gcc -v":
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)
compilertest.c:
main()
{}
The compiler test command:
gcc -O compilertest.c
The error message:
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../crt1.o: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
The file exists as a real file (i.e. not a symbolic link):
-rw-r--r-- 1 root root 1240 Jan 28 2016 /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../crt1.o
So, what am I missing? Was something compiled using 32b instead of 64b? Am I missing a library or have the wrong version of one?
$ readelf -h /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../crt1.o
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 288 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 13
Section header string table index: 10
$ env -i PATH=/usr/bin gcc -O compilertest.c
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../crt1.o: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
$ gcc -v compilertest.c
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic'
/usr/libexec/gcc/x86_64-redhat-linux/4.4.7/cc1 -quiet -v compilertest.c -quiet -dumpbase compilertest.c -mtune=generic -auxbase compilertest -version -o /tmp/ccGTjhJB.s
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.4.7/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/include
/usr/include
End of search list.
GNU C (GCC) version 4.4.7 20120313 (Red Hat 4.4.7-17) (x86_64-redhat-linux)
compiled by GNU C version 4.4.7 20120313 (Red Hat 4.4.7-17), GMP version 4.3.1, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2e79a9448b1040fd1e442d3c6bfaea69
COLLECT_GCC_OPTIONS='-v' '-mtune=generic'
as -V -Qy -o /tmp/cc4clAj5.o /tmp/ccGTjhJB.s
GNU assembler version 2.20.51.0.2 (x86_64-redhat-linux) using BFD version version 2.20.51.0.2-5.44.el6 20100205
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.4.7/:/usr/libexec/gcc/x86_64-redhat-linux/4.4.7/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/:/usr/lib/gcc/x86_64-redhat-linux/:/usr/libexec/gcc/x86_64-redhat-linux/4.4.7/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.4.7/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-mtune=generic'
/usr/libexec/gcc/x86_64-redhat-linux/4.4.7/collect2 --eh-frame-hdr --build-id -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../crti.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../.. /tmp/cc4clAj5.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../crtn.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../crt1.o: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
$ file /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../crt1.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../crt1.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.18, not stripped
This error message:
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../crt1.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status
Indicates that the linker found a 32-bit object file where it expected a 64-bit one, or vise versa. You can determine which by examining the file in question with the file command. readelf is a little bit overkill for this purpose, but it gets the job done, too. We know as a result that yours is a 32-bit ELF object file, so presumably the compiler expected a 64-bit one.
The path you present canonicalizes to /usr/lib/crt1.o. On RHEL6, that belongs to the 32-bit glibc-devel package (the 64-bit analog lives in /usr/lib64). A 32-bit ELF object is exactly what that file should be, so if the compiler expected a 64-bit object then something is seriously wrong with it.
My best guess is that an installation from source or from a package for some other RPM-based distribution (maybe even a different version of RHEL) has produced an unusable environment for you. If you have an installed-from-source copy of GCC somewhere other than /usr/bin, then removing that (from the path, at least) might be sufficient to solve your problem. The command which gcc might be useful in determining whether you're getting a rogue gcc instead of RHEL's standard one.
Otherwise, your best bet is to remove all copies of gcc and your development libraries, and then reinstall from the official package repositories. The main packages to remove and reinstall are 'gcc' and 'glibc-devel'; removing these may cause other tools and development libraries to be removed as well. I recommend also removing any 'compat-gcc' package. Do not attempt to remove the main 'glibc' package, however, for if you somehow managed to do that, it would render your system inoperable.
I am trying to compile a large C file (specifically for MATLAB mexing). The C file is around 20 MB (available from the GCC bug tracker if you want to play around with it).
Here is the command I am running and the output to screen, below. This has been running for hours, and as you can see, optimization is already disabled (-O0). Why is this so slow? Is there a way I can make this faster?
(For reference: Ubuntu 12.04 (Precise Pangolin) 64 bit and GCC 4.7.3)
/usr/bin/gcc -c -DMX_COMPAT_32 -D_GNU_SOURCE -DMATLAB_MEX_FILE -I"/usr/local/MATLAB/R2015a/extern/include" -I"/usr/local/MATLAB/R2015a/simulink/include" -ansi -fexceptions -fPIC -fno-omit-frame-pointer -pthread -O0 -DNDEBUG path/to/test4.c -o /tmp/mex_198714460457975_3922/test4.o -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.3-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04)
COLLECT_GCC_OPTIONS='-c' '-D' 'MX_COMPAT_32' '-D' '_GNU_SOURCE' '-D' 'MATLAB_MEX_FILE' '-I' '/usr/local/MATLAB/R2015a/extern/include' '-I' '/usr/local/MATLAB/R2015a/simulink/include' '-ansi' '-fexceptions' '-fPIC' '-fno-omit-frame-pointer' '-pthread' '-O0' '-D' 'NDEBUG' '-o' '/tmp/mex_198714460457975_3922/test4.o' '-v' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.7/cc1 -quiet -v -I /usr/local/MATLAB/R2015a/extern/include -I /usr/local/MATLAB/R2015a/simulink/include -imultilib . -imultiarch x86_64-linux-gnu -D_REENTRANT -D MX_COMPAT_32 -D _GNU_SOURCE -D MATLAB_MEX_FILE -D NDEBUG path/to/test4.c -quiet -dumpbase test4.c -mtune=generic -march=x86-64 -auxbase-strip /tmp/mex_198714460457975_3922/test4.o -O0 -ansi -version -fexceptions -fPIC -fno-omit-frame-pointer -fstack-protector -o /tmp/ccxDOA5f.s
GNU C (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04) version 4.7.3 (x86_64-linux-gnu)
compiled by GNU C version 4.7.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/MATLAB/R2015a/extern/include
/usr/local/MATLAB/R2015a/simulink/include
/usr/lib/gcc/x86_64-linux-gnu/4.7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04) version 4.7.3 (x86_64-linux-gnu)
compiled by GNU C version 4.7.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c119948b394d79ea05b6b3986ab084cf
EDIT: a follow-on: I followed chqrlie's advice and tcc compiled my function in <5 seconds (I had to remove the -ansi flag only and turn "gcc" to "tcc"), which is pretty remarkable, really. I can only imagine the complexity of GCC.
When trying to then mex it, however, there is one other command mex typically needs. The second command is typically:
/usr/bin/gcc -pthread -Wl,--no-undefined -Wl,-rpath-link,/usr/local/MATLAB/R2015a/bin/glnxa64 -shared -O -Wl,--version-script,"/usr/local/MATLAB/R2015a/extern/lib/glnxa64/mexFunction.map" /tmp/mex_61853296369424_4031/test4.o -L"/usr/local/MATLAB/R2015a/bin/glnxa64" -lmx -lmex -lmat -lm -lstdc++ -o test4.mexa64
I cannot run this with tcc as some of these flags are not compatible. If I try to run this second compilation step with GCC, I get:
/usr/bin/ld: test4.o: relocation R_X86_64_PC32 against undefined symbol `mxGetPr' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
EDIT: The solution appears to be clang. tcc can compile the file, but the arguments in the second step in mexing are incompatible with tcc's argument options. Clang is very fast and produces a nice, small, optimized file.
Nearly the entire file is one expression, the assignment to double f[24] = .... That's going to generate a gigantic abstract syntax tree tree. I'd be surprised if anything but a specialized compiler could handle that efficiently.
The 20 megabyte file itself may be fine, but the one giant expression may be what is causing the issue. Try as a preliminary step, splitting the line into double f[24] = {0} and then 24 assignments of f[0] = ...; f[1] = ... and see what happens. Worst case, you can split the 24 assignments into 24 functions, each in its own .c file, and compile them separately. This won't reduce the size of the AST, it will just reorganize it, but GCC is probably more optimized at handling many statements which together add up to a lot of code, vs. one huge expression.
The ultimate approach would be to generate the code in a more optimized manner. If I search for s4*s5*s6, for example, I get 77,783 hits. These s[4-6] variables don't change. You should generate a temporary variable, double _tmp1 = s4*s5*s6; and then use that instead of repeating the expression. You've just eliminated 311,132 nodes from your abstract syntax tree (assuming s4*s5*s6 is 5 nodes and _tmp1 is one node). That's that much less processing GCC has to do. This should also generate faster code (you won't repeat the same multiplication 77,783 times).
If you do this in a smart way in a recursive manner (e.g. s4*s5*s6 --> _tmp1, (c4*c6+s4*s5*s6) --> (c4*c6+_tmp1) --> _tmp2, c5*s6*(c4*c6+s4*s5*s6) --> c5*s6*_tmp2 -> _tmp3, etc...), you can probably eliminate most of the size of the generated code.
Upon testing, I found that the Clang compiler seems to have less problems compiling large files. Although Clang consumed almost a gigabyte of memory during compilation, it successfully turned OP's source code form into a 70 kB object file. This works for all optimization levels I tested.
gcc was also able to compile this file quickly and without consuming too much memory if optimization is turned on. This bug in gcc comes from the large expression in OPs code which places a huge burden on the register allocator. With optimizations turned on, the compiler performs an optimization called common subexpression elimination which is able to remove a lot of redundancy from OPs code, reducing both compilation time and object file size to manageable values.
Here are some tests with the testcase from the aforementioned bug report:
$ time gcc5 -O3 -c -o testcase.gcc5-O3.o testcase.c
real 0m39,30s
user 0m37,85s
sys 0m1,42s
$ time gcc5 -O0 -c -o testcase.gcc5-O0.o testcase.c
real 23m33,34s
user 23m27,07s
sys 0m5,92s
$ time tcc -c -o testcase.tcc.o testcase.c
real 0m2,60s
user 0m2,42s
sys 0m0,17s
$ time clang -O3 -c -o testcase.clang-O3.o testcase.c
real 0m13,71s
user 0m12,55s
sys 0m1,16s
$ time clang -O0 -c -o testcase.clang-O0.o testcase.c
real 0m17,63s
user 0m16,14s
sys 0m1,49s
$ time clang -Os -c -o testcase.clang-Os.o testcase.c
real 0m14,88s
user 0m13,73s
sys 0m1,11s
$ time clang -Oz -c -o testcase.clang-Oz.o testcase.c
real 0m13,56s
user 0m12,45s
sys 0m1,09
This is the resulting object file size:
text data bss dec hex filename
39101286 0 0 39101286 254a366 testcase.clang-O0.o
72161 0 0 72161 119e1 testcase.clang-O3.o
72087 0 0 72087 11997 testcase.clang-Os.o
72087 0 0 72087 11997 testcase.clang-Oz.o
38683240 0 0 38683240 24e4268 testcase.gcc5-O0.o
87500 0 0 87500 155cc testcase.gcc5-O3.o
78239 0 0 78239 1319f testcase.gcc5-Os.o
69210504 3170616 0 72381120 45072c0 testcase.tcc.o
Try Fabrice Bellard's tiny C compiler tcc from http://tinycc.org:
chqrlie$ time tcc -c test4.c
real 0m1.336s
user 0m1.248s
sys 0m0.084s
chqrlie$ size test4.o
text data bss dec hex filename
38953877 3170632 0 42124509 282c4dd test4.o
Yes, that's 1.336 seconds on a pretty basic PC!
Of course I cannot test the resulting executable, but the object file should be linkable with the rest of your program and libraries.
For this test, I used a dummy version of file mex.h:
typedef struct mxArray mxArray;
double *mxGetPr(const mxArray*);
enum { mxREAL = 0 };
mxArray *mxCreateDoubleMatrix(int nx, int ny, int type);
gcc still has not finished compiling...
EDIT: gcc managed to hog my Linux box so badly I cannot connect to it anymore:(
This is a long but simple basic question. So anyone familiar could answer to my questions.
I have a simple program below on my CentOS 6.4 system. (have it unnder ~/test)
I wanted to test insmod and rmmod.
#include <linux/module.h>
static int __init hello_world( void )
{
printk( "hello world!\n" );
return 0;
}
static void __exit goodbye_world( void )
{
printk( "goodbye world!\n" );
}
module_init( hello_world );
module_exit( goodbye_world );
When I did
gcc -o hello_world hello_world.c
I got
hello_world.c:1:26: error: linux/module.h: No such file or directory
hello_world.c:3: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'hello_world'
hello_world.c:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'goodbye_world'
hello_world.c:14: warning: data definition has no type or storage class
hello_world.c:14: warning: parameter names (without types) in function declaration
hello_world.c:15: warning: data definition has no type or storage class
hello_world.c:15: warning: parameter names (without types) in function declaration
So I figured the include path is not setup correctly. I searched where this linux/module.h is located and found linux/module.h is under /usr/src/kernels/2.6.32-358.2.1.el6.x86_64/include/linux/module.h.
(When I give 'uname -a', I get
Linux stph45.etri.re.kr 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed Mar 13 00:26:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
So this /usr/src/kernels/2.6.32-358.2.1.el6.x86_64/include is the right kernel header directory.)
Then I tried again like this
gcc -I/usr/src/kernels/2.6.32-358.2.1.el6.x86_64/include/ -o hello_world hello_world.c
and got
In file included from /usr/src/kernels/2.6.32-358.2.1.el6.x86_64/include/linux/list.h:7,
from /usr/src/kernels/2.6.32-358.2.1.el6.x86_64/include/linux/module.h:9,
from hello_world.c:1:
/usr/src/kernels/2.6.32-358.2.1.el6.x86_64/include/linux/prefetch.h:14:27: error: asm/processor.h: No such file or directory
/usr/src/kernels/2.6.32-358.2.1.el6.x86_64/include/linux/prefetch.h:15:23: error: asm/cache.h: No such file or directory
... more lines ...
I found this architecture dependent header file in /usr/src/kernels/2.6.32-358.2.1.el6.x86_64/arch/x86/include/asm/processor.h. So this time I did
gcc -I/usr/src/kernels/2.6.32-358.2.1.el6.x86_64/arch/x86/include -I/usr/src/kernels/2.6.32-358.2.1.el6.x86_64/include -o hello_world hello_world.c
providing the separate header path for the arch dependent files. Now I have these errors..
In file included from /usr/src/kernels/2.6.32-358.2.1.el6.x86_64/arch/x86/include/asm/percpu.h:45,
from /usr/src/kernels/2.6.32-358.2.1.el6.x86_64/arch/x86/include/asm/current.h:5,
from /usr/src/kernels/2.6.32-358.2.1.el6.x86_64/arch/x86/include/asm/processor.h:15,
from /usr/src/kernels/2.6.32-358.2.1.el6.x86_64/include/linux/prefetch.h:14,
from /usr/src/kernels/2.6.32-358.2.1.el6.x86_64/include/linux/list.h:7,
from /usr/src/kernels/2.6.32-358.2.1.el6.x86_64/include/linux/module.h:9,
from hello_world.c:1:
/usr/src/kernels/2.6.32-358.2.1.el6.x86_64/include/linux/kernel.h:949:2: warning: #warning Attempt to use kernel headers from user space, see http:
In file included from /usr/src/kernels/2.6.32-358.2.1.el6.x86_64/arch/x86/include/asm/processor.h:15,
from /usr/src/kernels/2.6.32-358.2.1.el6.x86_64/include/linux/prefetch.h:14,
from /usr/src/kernels/2.6.32-358.2.1.el6.x86_64/include/linux/list.h:7,
from /usr/src/kernels/2.6.32-358.2.1.el6.x86_64/include/linux/module.h:9,
from hello_world.c:1:
/usr/src/kernels/2.6.32-358.2.1.el6.x86_64/arch/x86/include/asm/current.h:12: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'struct'
.... more lines ....
I think this 'Attempt to user kernel headers' is ok in this case. and I have to find the cause of "error: expected '=', ',', ';', 'asm' or 'attribute' before 'struct'" error.
I think my gcc (I guess it came with the CentOS.) seems to have some problem. Can anybody tell me what's wrong with my gcc installation? Seeing below message, there are some mismatches and I don't know the procedures for the cures. (afraid to ruin the whole development tool chain which is dependent on gcc)
ckim#stph45:~/testprog] echo "" | gcc -o /tmp/tmp.o -v -x c -
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
COLLECT_GCC_OPTIONS='-o' '/tmp/tmp.o' '-v' '-mtune=generic'
/usr/libexec/gcc/x86_64-redhat-linux/4.4.7/cc1 -quiet -v - -quiet -dumpbase - -mtune=generic -auxbase - -version -o /tmp/ccWAQshz.s
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.4.7/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/include
/usr/include
End of search list.
GNU C (GCC) version 4.4.7 20120313 (Red Hat 4.4.7-4) (x86_64-redhat-linux)
compiled by GNU C version 4.4.7 20120313 (Red Hat 4.4.7-4), GMP version 4.3.1, MPFR version 2.4.1.
warning: GMP header version 4.3.1 differs from library version 4.3.2.
warning: MPFR header version 2.4.1 differs from library version 2.4.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 11481e4aa93ef024f1be70ed47ae45e3
COLLECT_GCC_OPTIONS='-o' '/tmp/tmp.o' '-v' '-mtune=generic'
as -V -Qy -o /tmp/ccTYQoBw.o /tmp/ccWAQshz.s
GNU assembler version 2.20.51.0.2 (x86_64-redhat-linux) using BFD version version 2.20.51.0.2-5.36.el6 20100205
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.4.7/:/usr/libexec/gcc/x86_64-redhat-linux/4.4.7/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/:/usr/lib/gcc/x86_64-redhat-linux/:/usr/libexec/gcc/x86_64-redhat-linux/4.4.7/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.4.7/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' '/tmp/tmp.o' '-v' '-mtune=generic'
/usr/libexec/gcc/x86_64-redhat-linux/4.4.7/collect2 --eh-frame-hdr --build-id -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /tmp/tmp.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../.. /tmp/ccTYQoBw.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crtn.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
To compile a kernel module, you are supposed to write a Makefile to setup the kernel path and other environment variable.
You can use the below Makefile to build you kernel module
obj-m := hello_world.o
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
Copy the above contents to file name Makefile in the same directory as that of the source.
Just enter $ make command to build the module. The output would be hello_world.ko in the same directory.
Concerning the header/library mismatch
warning: GMP header version 4.3.1 differs from library version 4.3.2.
warning: MPFR header version 2.4.1 differs from library version 2.4.2.
it may not be a problem here. I suppose that GCC was compiled with GMP 4.3.1 and MPFR 2.4.1, but after that, the GMP and MPFR shared libraries were upgraded to ABI-compatible versions 4.3.2 and 2.4.2 respectively. If this is the case, this is allowed.
I am attempting to build SGABIOS on my Macbook Pro. Unfortunately, I am getting some strange compilation errors that I am not familiar with. When I attempt to run make, here is the output I get:
Ajax-2:sgabios-read-only dash$ make
rm -f .depend
cc -E -M -Wall -Os -m32 -nostdlib sgabios.S >.tmpdepend && mv .tmpdepend .depend
make clean
rm -f sgabios.bin csum8 sgabios.o *.elf *.srec *.com version.h
touch sgabios.S
cc -Wall -Os -m32 -nostdlib -DBUILD_DATE="\"Fri Aug 31 19:10:03 UTC 2012\"" -DBUILD_SHORT_DATE="\"08/31/12\"" -DBUILD_HOST="\"Ajax-2.local\"" -DBUILD_USER="\"dash\"" -c -o sgabios.o sgabios.S
sgabios.S:24:Unknown pseudo-op: .type
sgabios.S:24:Rest of line ignored. 1st junk character valued 95 (_).
sgabios.S:30:Unknown pseudo-op: .size
sgabios.S:30:Rest of line ignored. 1st junk character valued 95 (_).
sgabios.S:33:Unknown pseudo-op: .type
sgabios.S:33:Rest of line ignored. 1st junk character valued 108 (l).
sgabios.S:156:Alignment too large: 15. assumed.
make: *** [sgabios.o] Error 1
My GCC version information is as follows:
Ajax-2:sgabios-read-only dash$ gcc -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.1~22/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.1~22/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
I have done extensive googling and monkeying and nothing seems to work. I have also tried the whole mess in cygwin, and I get nearly the same thing. For your reference, I've uploaded some files from the latest release:
sgabios.S
sgabios.h
Makefile
Update: Posted output of make in cygwin:
dash#Ajax_virtual ~/sgabios-read-only
$ make
rm -f .depend
cc -E -M -Wall -Os -m32 -nostdlib sgabios.S >.tmpdepend && mv .tmpdepend .depen d
make clean
make[1]: Entering directory `/home/dash/sgabios-read-only'
rm -f sgabios.bin csum8 sgabios.o *.elf *.srec *.com version.h
make[1]: Leaving directory `/home/dash/sgabios-read-only'
touch sgabios.S
cc -Wall -Os -m32 -nostdlib -DBUILD_DATE="\"Fri, Aug 31, 2012 10:14:21 PM\"" -DB UILD_SHORT_DATE="\"08/31/12\"" -DBUILD_HOST="\"Ajax_virtual\"" -DBUILD_USER="\"d ash\"" -c -o sgabios.o sgabios.S
sgabios.S: Assembler messages:
sgabios.S:22: Error: junk at end of line, first unrecognized character is `"'
sgabios.S:24: Warning: .type pseudo-op used outside of .def/.endef ignored.
sgabios.S:24: Error: junk at end of line, first unrecognized character is `_'
sgabios.S:30: Warning: .size pseudo-op used outside of .def/.endef ignored.
sgabios.S:30: Error: junk at end of line, first unrecognized character is `_'
sgabios.S:33: Warning: .type pseudo-op used outside of .def/.endef ignored.
sgabios.S:33: Error: junk at end of line, first unrecognized character is `l'
<builtin>: recipe for target `sgabios.o' failed
make: *** [sgabios.o] Error 1
This is because the assembler file is written for GNU as but OS X does not use it but rather its own assembler.
Furthermore, according to the documentation on the .type directive the meaning of the directive in GNU as depends on the target platform. The directives in the linked file are only valid for ELF targets as used on linux (and other unices) but cygwin is a COFF target.