Hey I am trying to compile c code that uses functions from the c11 standard library on OS X with clang.
The compiler option -std=c11 allows me to use c11 language features. But when I am using new functions like at_quick_exit I get the following warning implicit declaration of function 'at_quick_exit' is invalid in C99.
The source code has the following line #include <stdlib.h>
The clang option -stdlib does not help.
My Systems:
OS X Yosemite 10.10.3
$ clang -v
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.3.0
Thread model: posix
Ubuntu 14.04 LTS
$ clang -v
Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4)
Target: x86_64-pc-linux-gnu
Thread model: posix
To be more explicit. How can I get on OS X a c11 standard library?
Thanks for any kind of help.
Typically a self-hosted system compiler alone does not provide the full Standard C environment including runtime libraries. Typically the underlying system provides most, if not all, of the libraries (and headers), while the compiler just compiles.
So, if you need some specific functions that are not provided on a given system then you will have to write them yourself, or source them from some portable library that is compatible with your target system.
In this particular case you will also probably find that quick_exit() itself is not provided by the system's libc, and so it should be easy enough to write both functions on your own.
Related
When using clang v8.0.0 on Windows (from llvm prebuilt binaries) with -g or -gline-tables-only source map tables are not being picked up by gdb or lldb debuggers.
Upon including -g flag file grows in size (which is to be expected) yet neither gdb nor lldb pickes the source up
When compiled with gcc though (with -g flag) source files are detected by debugger.
I have tried running the same command (clang -g <codefile>) on macOS High Sierra (clang -v says it is Apple LLVM version 10.0.0 (clang-1000/10.44.4)) where there source files are being picked up by lldb. So I guessed it is localized to my windows instance or llvm for windows build.
P.S. output of clang -v on windows:
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
On Windows, Clang is not self-sufficient (at least not the official binaries). You need to have either GCC or MSVC installed for it to function.
As Target: x86_64-pc-windows-msvc indicates, by default your Clang is operating in some kind of MSVC-compatible mode. From what I gathered, it means using the standard library and other libraries provided by your MSVC installation, and presumably generating debug info in some MSVC-specific format.
Add --target=x86_64-w64-windows-gnu to build in GCC-compatible mode. (If you're building for 32 bits rather than 64, replace x86_64 with i686). This will make Clang use headers & libraries provided by your GCC installation, and debug info should be generated in a GCC-compatible way. I'm able to debug resulting binaries with MSYS2's GDB (and that's also where my GCC installation comes from).
If you only have GCC installed and not MSVC, you still must use this flag.
How do I know this is the right --target? This is what MSYS2's Clang uses, and I assume they know what they're doing. If you don't want to type this flag every time, you can replace the official Clang with MSYS2's one, but I'm not sure if it's the best idea.
(I think they used to provide some patches to increase compatibility with MinGW, but now the official binaries work equally well, except for the need to specify the target. Also, last time I checked their binary distribution was several GB larger, due to their inability to get dynamic linking to work. Also some of the versions they provided were prone to crashing. All those problems come from them building their Clang with MinGW, which Clang doesn't seem to support very well out of the box. In their defence, they're actively maintaining their distribution, and I think they even ship libc++ for Windows, which the official distribution doesn't do.)
I'm trying to build a C program with Windows gcc using Mingw-w64 installation (gcc.exe (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0).
I get undefined reference to `memmem' error. Isn't memmem() a standard glibc function that should be available in all gcc versions?
As this post explains
"MinGW does not build against glibc, it builds against msvcrt. As
such, it uses libmsvcrtXX.a instead." "gcc and glibc are two separate
products."
So, yep, no memmem on Windows and here's the implementation.
I'm trying to build applications for the Sabre i.MX6 development board, that runs QNX OS. I'm using QNX Momentics v6.5 for cross-compiling my code. I wrote a simple "Hello World" code and I'm trying to compile it with new c standards since the project I'm working on requires that.
When I try to compile with any flag, say -std=c99 or -std=c11, it throws an error during the compilation saying
cc: unknown Option -std=c99" or "cc: unknown Option -std=c11".
I can see that the compiler it's using is gcc 4.4.2.
I'm not sure whether this version of gcc doesn't support c99 or whether the flag I'm passing is supposed to be different for QNX Momentics.
QNX 6.5 doesn't support C++11 out of the box, since it is using an old GNU compiler (gcc 4.4.2). However, the QNX Software Center has several updates to QNX 6.5 that will let you update to GCC 4.8.3, which will get you pretty decent C++11 support.
You will need to create an account on the QNX website and then:
Download Binutils 2.24 for your host (e.g. win32-binutils-2.24.zip for WIndows) from http://community.qnx.com/sf/frs/do/listReleases/projects.toolchain/frs.binutils.
Download GCC 4.8.3 for your host (e.g. win32-gcc-4.8.3-qnx65x.zip for Windows) from http://community.qnx.com/sf/frs/do/viewRelease/projects.toolchain/frs.gcc.gcc_4_8.
Expand both archives - this will create host and target folders.
Copy & paste new folders into QNX folder, overwrite files.
Edit host/win32/x86/etc/qcc/gcc/default to change the default compiler: DIR=4.8.3
When compiling add the following flags:
-Vgcc_ntox86_gpp to QCC (for an x86 target) to get gcc 4.8.3 headers.
-Wc,-std=c++11 to QCC to make it use C++ 11.
QNX 6.5 and gcc 4.4.2 don't support C++11. See the QCC docs for more info.
The best you'll get is incomplete and experimental support through -std=c++0x or -std=gun++0x.
QNX 6.6 includes gcc 4.7.3 which does have experimental C++11 support and QNX 7.0 uses gcc 5.4.0 has full C++11 and C++14 support.
Full details of the gcc C++ standards support can be found on the gcc standards page.
As mentioned over here and here
So if your program is using math functions and including math.h, then
you need to explicitly link the math library by passing the ‘-lm’ flag
But I just manage to get the linking without using -lm flag with gcc on my benign C code.
and It work perfectly well.
Any clue.
gcc -version
gcc -v
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
On many systems some parts of what's traditionally in libm are included in the standard C library for various reasons. Other parts may be implemented directly in the math.h header, yet others might be just implemented inline by the compiler.
Whatever code you had, you got away with not linking with libm. You'll often end up in situations where you get away with doing something despite it not being perfectly correct. A good habit is to ignore that luck and still do what the standards/documentation says because it reduces the number of problems in the future.
Clang has a very cool extension named block bringing true lambda function mechanism to C. Compared to block, gcc's nested functions are quite limited. However, trying to compile a trivial program c.c:
#include <stdio.h>
int main() {
void (^hello)(void) = ^(void) {
printf("Hello, block!\n");
};
hello();
return 0;
}
with clang -fblocks c.c, I got
/usr/bin/ld.gold: /tmp/cc-NZ7tqa.o: in function __block_literal_global:c.c(.rodata+0x10): error: undefined reference to '_NSConcreteGlobalBlock'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
seems I should use clang -fblocks c.c -lBlocksRuntime, but then I got
/usr/bin/ld.gold: error: cannot find -lBlocksRuntime
(the rest is the same as above)
Any hints?
On Ubuntu Linux:
sudo apt-get install llvm
sudo apt-get install clang
sudo apt-get install libblocksruntime-dev
test.c:
#include <stdio.h>
int main() {
void (^hello)(void) = ^(void) {
printf("Hello, block!\n");
};
hello();
return 0;
}
compile:
clang test.c -fblocks -lBlocksRuntime -o test
./test
Hello, block!
works fine.
Technical background information:
Blocks themselves are language feature but they also require some runtime support. So either the compiler has to provide a runtime library and statically link it into the build product or the system must provide such a runtime library the build product can be linked against.
In case of macOS, the blocks runtime is part of libSystem and as all executable and dynamic libraries on macOS are linked against libSystem, they all do have blocks support.
On a Linux system, such runtime support would typically added to the libC library (glibc in most cases) if it was considered a core feature of the system or the language, yet as gcc currently has no support for blocks at all and its unknown if blocks will ever become an official C feature, Linux systems don't ship runtime support for blocks by default.
clang itself does offer a target-indepedent blocks runtime as part of the compiler runtime library, yet it is optional and many Linux systems don't seem to include in their clang install package. That's why the project blocksruntime has been created, that builds the clang blocks runtime support as an own library, which you can statically link into your projects or dynamically install onto your systems. The source code is available on GitHub.
Depending on your Linux distribution, a ready-to-use installer package may exist. Note that blocksruntime cannot just be compiled for Linux, it can also be compiled for FreeBSD or Windows (MinGW/Mingw-w64) or even for Mac if you don't want to use the runtime that Apple provides. Theoretically it should be portable to any platform that clang natively supports.
Judging from Which libraries do you need to link against for a clang program using blocks it appears there is no easy way of fixing this, at least as of early 2010.