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.
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.)
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.
I'm trying to compile a program to run on a Linux powered board, which has an ARM926EJ-S processor. So I've installed Debian embedded cross-development toolchain, and tried compiling an Hello World with in gcc with -march=armv5te . When I tried running the binary on the board it crashed with file not found errors (due to library versions), after that I've tried compiling with -static flag and I got a seg fault (0x0000827c in __libc_start_main (), said mr gdb trough gdbserver).
Any idea on what to do here to get something running?
Apparently the solution is to try as many toolchains as you can find. Eventually you'll find the one that works, after spending a few too many hours compiling toolchains. uClibc buildroot in this case.
You can find toolchains which support ARM926EJ-S on Linaro Page. Use the most recent arm-linux-gnueabi from Linaro project. I am currently using a version with gcc 4.9.4 which you can find here
It is recommended to use -mcpu=arm926ej-s instead of -march and -mtune. See gcc documentation because it combines -march and -mtune for your specified processor. It was deprecated for x86, but not for arm.
Other possibility could be building your own toolchain via crosstools-ng. But the Linaro toolchains are working out of the box if you don't need some specific setting (for example only using static libraries).
Has someone infos how to build a llvm+clang toolchain using binutils and newlib and how to use it?
host: Linux, AMD64
target: cortex-m3, stm32
c-lib: newlib
assembler: gnu as
I created a firmware framework - PolyMCU https://github.com/labapart/polymcu - that is based on CMake that support GCC and LLVM. Because it is based on CMake you can build your firmware on Linux/Windows/MacOS.
It also uses Newlib - it looks all your requirements are there!
I also wrote a blog where I compared GCC and LLVM build size on ARM Cortex-M: http://labapart.com/blogs/3-the-importance-of-the-toolchain-version-in-embedded-space
Interesting results, Clang generated code is not much bigger than GCC on Cortex-M...
Unfortunately, right now clang does not support flexible cross-compilation settings. So, most probably you will need to invoke necessary tools with all necessary arguments.
Start with building llvm + clang using --target=thumbv7-eabi configure argument (note that you will need llvm + clang as of yesterday for this). You might want to specify --enable-targets=arm as well. This will instruct clang to generate code for thumb by default. After this you can invoke clang -mcpu=cortex-m3 to generate the code for you.
You will have to provide all necessary include / library paths by hands via -I / -L, etc.
If you're happy with some C++ hacking, you can write necessary "HostInfo", so it will invoke the right tools and provide right paths automagically.
I have some old hardware with an old version of say SuSE linux running on it. Now I have this fancy development machine running Ubuntu 9.10. Some of the tools I use to compile my C app (written in Python 2.6.x) are not available on the old SuSe box. So... is it possible to compile for that old machine on my dev box?
I have the following steps in mind, but would like to cross-check before venturing off into this quest:
1. Find out which static/shared libs my app needs and find/build target version of them
2. Also find the corresponding header files
3. Feed the correct flags to gcc to use the target headers and libraries
4. Feed the correct flags to gcc to use the correct architecture (i386/i686), or do I need a cross-compilation toolchain.
5. Compile, upload and enjoy ;-)
I regularly use avr-gcc and cc65, both are cross compiling. I know that you set up a coss compiler for developing something like a gumstix, so it should be possible to do the same for old/other Linux distros, not?
C
The way I would approach this is grab your oldmachine:/usr/lib and oldmachine:/usr/include so you have e.g. newmachine:/oldmachinecompiler/usr/{lib|include} then build a cross compiler setting --sysroot to newmachine:/oldmachinecompiler/
This is really the only way to ensure that any library requirements (including libc) in your program are compatible with oldmachine.