Clang Error - stddef file not found? - c

After upgrading to Ubuntu 13.10 "Saucy", Clang now gives me the error message:
clang -Wall -Werror -std=c99 -ggdb -O0 5.1.c -o 5.1
In file included from 5.1.c:1:
/usr/include/stdio.h:33:11: fatal error: 'stddef.h' file not found
# include <stddef.h>
^
1 error generated.
make: *** [5.1] Error 1
BTW the header I included was stdio.h not stddef.h but I am assuming that stdio.h references or #includes stddef.h

This error appeared for me when trying to run clang-tidy without clang installed.
Installing clang fixed this error. IMO this error occurs when clang-tidy looks for headers in GCC and system paths and clang version/symlink of these headers are missing.

It's a know bug in ubuntu. Take a look here: https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug/1242300
It appears that a temporary workaround is to correct the symlink:
For the 3.5 LLVM toolchain it seems that the symlink
/usr/lib/clang/3.5/include erroneously points to
../../llvm-3.4/lib/clang/3.5/include, but should instead point to
../../llvm-3.5/lib/clang/3.5/include
The workaround (of course) is to manually correct the symlink.
For the 3.4 toolchain the /usr/lib/clang/3.4/include doesn't exist at
all. I have not tried LLVM 3.4 on Ubuntu so I don't know if createing
a symlink to ../../llvm-3.4/lib/clang/3.4/include will fix the
problem, but it does seem likely.
Source

Please note that I resolved the above error by performing:
$ sudo apt-get install clang
In my particular case, there is likely an issue with something in my cmake files which I haven't determined yet.

Using clang-tidy from cmake and gcc you can add the following in your CMakeLists.txt
if(CMAKE_EXPORT_COMPILE_COMMANDS)
set(CMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES ${CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES})
endif()
This will result in the "compile_commands.json" file to contain the correct gcc includes.
The solution comes from the kitware issue tracker: Missing c++ header path in compile_commands.json
This answer is a bit off topic but this is the top hit on search engines for my specific issue

Related

macOS llvm can't find stdio.h anymore

I come to you with a weird problem I've been facing.
So last week, I installed llvm and libomp for a C project, and it compiled just fine with this at the start of my makefile:
CC=clang
CFLAGS = -O2 -fopenmp
CFLAGS += -I/usr/local/opt/libomp/include
LDFLAGS = -fopenmp
LDFLAGS += -L /usr/local/opt/libomp/lib
Today I meant to finish that project, I opened vs code (I don't know if that's relevant), added some code left and right, and when I wanted to compile the code again to test if everything was fine, it gave me
me#macbookPro% make
clang -c -O2 -fopenmp -I/usr/local/opt/libomp/include bubble.c -o bubble.o
bubble.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
^~~~~~~~~
1 error generated.
make: *** [bubble.o] Error 1
which has left me dumbfounded since it worked just fine a few days ago.
I tried to do an export CPATH with
export CPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
but I got a bunch of warning and it didn't work either.
Any help is greatly appreciated !
Info: I'm running the latest version of BigSur and VSCode.
Apparently a macOS update had uninstalled the XCode developer tools.
I ended up uninstalling llvm and libomp, and when reinstalling it told me brew didn't have CLT (use brew config to check that).
Then I ran the classic xcode-select --install then brew install llvm and brew install libomp, edited my path to include the llvm's bin and it works again.
My solution:
masOS12.3.1 monterey
"software update" --> "update commandLineTool" if push --> you can compile correctly without 'stdio.h' file not found.

GCC as m68k cross-compiler

I am trying to recompile binutils and GCC as a cross-compiler for m68k architecture. I am following these instructions:
http://darkdust.net/writings/megadrive/crosscompiler
However, the process keeps failing on one part or another. I have tried with binutils 2.16.1 and gcc 3.4.6, binutils 2.15 and gcc 3.4.2 and binutils 2.15 and gcc 3.4.6.
This last attempt fails when running "make" on gcc, after making and installing binutils. It gives the following error:
gcc -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-
prototypes -Wmissing-prototypes -pedantic -Wno-long-long -DHAVE_CONFIG_H
-I. -I. -I../../gcc-3.4.2/gcc -I../../gcc-3.4.2/gcc/. -I../../gcc-
3.4.2/gcc/../include \
-DTARGET_MACHINE=\"m68k-coff\" \
-c ../../gcc-3.4.2/gcc/collect2.c -o collect2.o
In file included from /usr/include/fcntl.h:289:0,
from ../../gcc-3.4.2/gcc/system.h:214,
from ../../gcc-3.4.2/gcc/collect2.c:30:
In function ‘open’,
inlined from ‘collect_execute’ at ../../gcc-3.4.2/gcc/collect2.c:1535:20:
/usr/include/x86_64-linux-gnu/bits/fcntl2.h:50:4: error: call to
‘__open_missing_mode’ declared with attribute error: open with O_CREAT or
O_TMPFILE in second argument needs 3 arguments
__open_missing_mode ();
^
Makefile:1364: recipe for target 'collect2.o' failed
make[1]: *** [collect2.o] Error 1
make[1]: Leaving directory '/home/gabriel/src/gcc-build/gcc'
Makefile:23339: recipe for target 'all-gcc' failed
make: *** [all-gcc] Error 2
I don't expect to fix this error, but does anyone know of a combination of binutils and gcc release that work? Should I be using a certain version of gcc to recompile gcc successfuly?
Thanks for any insight you may have on this!
EDIT:
My linux has GCC 5.4.0 so I just downloaded the 5.4.0 source to try and rebuild that for m68k cross-compiling. I now get the following error when running "make" on the gcc source:
*** Configuration m68k-unkown-coff not supported
What could be the cause of this? Is it because I need an older version of GCC? (the binutils version i'm using definately supports the m68k target). The tutorial I'm using always defines "--target=m68k-coff", should that instead be "--target=m68k-unkown-coff"?
EDIT 2:
So I tried compiling for m68k-elf but now I get this error:
checking for m68k-elf-gcc... /home/gabriel/src/gcc-build/./gcc/xgcc -B/home/gabriel/src/gcc-build/./gcc/ -B/opt/m68k/m68k-elf/bin/ -B/opt/m68k/m68k-elf/lib/ -isystem /opt/m68k/m68k-elf/include -isystem /opt/m68k/m68k-elf/sys-include
checking for suffix of object files... configure: error: in `/home/gabriel/src/gcc-build/m68k-elf/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
I ran download_prerequisites before building so it should not be a problem with the MPC library. Any idea how to move on? I need assembler only so I don't mind what the format of the object files is. Thanks!
I used to do pretty much what you are doing right now.
My advice is to use crosstool-ng (http://crosstool-ng.github.io), as it does pretty much everything in an automated manner.
If you are studying m68k assembly, I used to host a modified version of gcc-explorer by Matt Godbolt (https://godbolt.org/). You can find a runnable docker image here (https://hub.docker.com/r/esantoro/acso-explorer/) and some more details here (https://znpy.wordpress.com/2017/05/08/decommisioning-acso-explorer-santoro-tk/)
Hope it helps,
znpy
you can build most versions with a current Linux. To install the prerequisites have a look at https://github.com/bebbo/amiga-gcc
unpack the gcc archive, e.g. to /opt/cross/gcc-6.5.0
create a separate build folder, e.g. /opt/cross/xcc-6.5.0 - never build inside gcc's source folder!
create the prefix folder, that's where binaries are installed to, e.g. /opt/cross/gcc65
ensure that these folders exist and are writable, then
configure from within that build folder using an absolute path for configure
cd /opt/cross/xcc-6.5.0/
/opt/cross/gcc-6.5.0/configure --target=m68k-elf --program-prefix=m68k-elf- --enable-languages=c,c++ --prefix=/opt/cross/gcc65 --disable-libssp --disable-nls --disable-multilib
make all-gcc
make install-gcc
I'm also running the compiler explorer for 68k gccs at https://franke.ms/cex/

GCC weird error at header file when using linter-gcc at atom editor

I'm getting a weird error at C header files when linting with linter-gcc at atom. The error is this:
cc1: error: output filename specified twice
This error is generated by: gcc 5.2.1, ubuntu 15.10.
The same error is generated by gcc 5.3.0 at my linux arch system 4.5.0-1 ARCH.
When I checked with clang 3.7.1 all went fine.
Note that I can compile the program normally. The error is generated only inside atom editor or when I run this command at my terminal:
/usr/bin/gcc -Wall -fsyntax-only -c -fmax-errors=0 /path/to/headerfile.h
But when I run:
clang -Wall -fsyntax-only -c /path/to/headerfile.h
Nothing was printed.
EDIT: It seems that it's not linter-gcc's bug as I contacted the package's creator via his github account.
So my question is: What's is the source of this error? Is there a way to solve it? What's causing it?

I get "lapack.h: No such file or directory" although I installed liblapack-dev

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>

Using MinGW to compile C code, but error liblto_plugin-0.dll not found?

I'm using MinGW to compile C code. but when I give command "make", appear error : gcc.exe : fatal error: -fuse-linker-plugin, but liblto_plugin-0.dll not found compilation terminated. make: * [all] Error 1. Does anybody know how to solve it?
though a long time since asked, I faced the same issue and I found a fine workaround when compiling.
gcc -fno-use-linker-plugin test.cpp -o test
Check your PATH environment variable and look for a path to another MinGW installation. I have two MinGW installed (first one in Falcon C++ IDE directory), and second one I installed by myself. There was two paths to MinGW in system PATH environment variable and that induced the error.

Resources