What's different between the "GNU MCU Eclipse ARM
Embedded GCC " and "GNU ARM Embedded toolchain"? I'm new in Linux world and I need to programming STM32F4DISCOVERY board. And I can't understand what toolchain need is .
I would take a look at this article if you're curious about getting started with toolchains. It's from Nordic, not ST Micro, but it's very helpful to understand how the toolchain, makefile, and IDE all work together.
https://devzone.nordicsemi.com/tutorials/b/getting-started/posts/development-with-gcc-and-eclipse
I believe the brief answer to your question is that:
GNU MCU Eclipse ARM Embedded GCC is a family of extensions to the Eclipse IDE to develop code for ARM devices
GNU ARM Embedded toolchain is from ARM, and it's purely the compiler, linker, etc. needed to make a command line call to compile a C file and generate a binary for an ARM processor
If you're just looking to crank something out on your STM32, I would look to see if they have an IDE for your board/ application, as they're usually pre-bundled with the toolchain and an SDK.
GNU MCU Eclipse ARM Embedded GCC is based on the GNU ARM Embedded toolchain. From the README:
Compared to the ARM distribution, the build procedure is more or less the same and there should be no functional differences.
The only addition affects newlib, which was extended with printf()/scanf() support for long long and C99 formats (--enable-newlib-io-long-long and --enable-newlib-io-c99-formats).
The Docker images used to create the GNU MCU Eclipse ARM Embedded GCC release are also available on the project page, should you ever need it (probably not).
You should be fine with either of them installed along with the rest of the GNU MCU Eclipse suite.
Related
I have created a bare-bone Linux ARM system. It boots to a busybox shell without any issues on my ARM system.
Now I want to build a working gcc/glibc environment that I can use on my ARM system.
My development machine is x86. I have read tutorials talking about doing a "cross-compiler", but that does not seem what I want. Seem that is just a compiler that runs on x86, but can generate ARM binaries.
I need to create a compiler that runs on ARM and creates ARM binaries. But I need to build it on my x86 machine and then copy it over to my ARM one. Then going forward, I can extend the system by compiling natively on the ARM machine.
So, I probably need to use "cross-compiling" to create this gcc/glibc, but the result should be ARM for ARM and not a ARM for x86. Am I correct? Is it just a matter of playing around with the "taget", "host" variables?
All tutorials I have read shows how you build the system into an isolated target directory, but they don't explain what parts I need to copy to the target ARM system root.
So, I probably need to use "cross-compiling" to create this gcc/glibc, but the result should be ARM for ARM and not a ARM for x86. Am I correct?
This is correct, but not the complete workflow. You need more compilers than you might imagine.
Is it just a matter of playing around with the "target", "host" variables?
This is more complex than you might first imagine. I would like to refer you to
crosstool-NG's Toolchain Types and Wikipedia's Canadian Cross for reference.
A little reading will reveal that you are trying to make a cross native compiler with, I assume, build as x86-glibc-linux, host as arm-glibc-linux and target as arm-glibc-linux. You need a native compiler (x86-glibc-linux) to make a cross arm-glibc-linux that runs on x86 (host). This is because the cross native arm-glibc-linux needs to build a glibc as part of the toolchain that will run on the ARM. You need more than a compiler; linker (gold?), libraries (shared/static), etc.
Crosstool-ng supports this and generally yocto and distros use it some where to create their version. There are often more efficient ways to do this than with crosstool-ng as sometimes only a bootstrap compiler will suffice and/or you can reuse code built for a previous compiler build. See for example,
A “cross-native” toolchain can be built as a trivial case of the “canadian” toolchain. It is suboptimal, as it makes crosstool-NG build the tools targeting the host machine twice (first, as a separate toolchain which is a prerequisite for all canadian builds; and second, as a part of temporary toolchain created as a part of the canadian build itself). This will likely be improved in the future.
However, if this is rarely done you can do this building while you are doing other things. I took several days to make a Canadian cross of "x86-64-linux/x86-mingw/arm-linux" to allow Windows development for an ARM Linux device. If you think you will create this compiler many times (to track gcc development for instance) you might want to look at a custom script instead of crosstool-NG.
In our system, we write the code on C++ without using Qt libraries.Actually, we write the on Windows machine, but finaly, this code must to be rebuilded for Linux Embedded machine. At first stage we did it successfully with Makefile-s, but "old style debugging" with gdb utility killed us. So I want to use Qt Creator to debug the application.
I successfully use Qt Creator to build all libraries and applications for ARM machine(of couse I have an ARM toolchain). But I cannot remotely debug the system.
I do not understand, what I do wrong.
The questions:
1. For system debuging, do I need Qt Libraries buld for ARM machine? (as I wrote above, I do not use Qt Libraries for my applications or for my libraries)
2. Do I need to redefine Mkspec for ARM compiler?
Thanks, Slava
You generally don't need Qt libraries for your system to use Qt Creator as a debugger frontend for your plain C++ program on an embedded device. However, if you use qmake as a build system, the associated Qt version must (roughly) match your target.
I'm trying to build a native ARM GDB for an ARM board to use. Since it lacks a lot of the tools GDB needs for compilation, I'm trying to build it on my x86 machine.
./configure --host=arm-linux-gnueabi --target=arm-linux-gnueabi && make
However, half way through the build process, it complains that "termcap library" is missing. I think it means it couldn't find an ARM version of the library for it to use. So, is there a possible workaround, or should I not bother with this approach and think of another way?
You should be able to do this for your "ARM board". You need to compile GDB library dependencies (e.g. the termcap library) and install them where the cross compiler can find them before you can build GDB. Without a more specific description about the cross compilation toolchain and board it's hard to give more specific advice that will be helpful to you.
I cross build GDB for several Linux targets for my ELLCC cross development tool project (http://ellcc.org). You do need a few libraries built for the target to do a build. In addition to the standard C library, I used libedit, zlib, expat, and ncurses.
I've read that mingw can be used on Linux to build a windows executable from C/C++.
Can other languages do this, and how about popular GUI libraries?
In particular I'm interested in OCaml and Haskell as languages and libSDL, wxWdgets, and GTK as libraries.
It doesn't matter whether the language has support - what matters is the compiler (unless you're using a WORA language like Java). To answer your question, it is possible to build a cross compiler on Linux to target the Windows platform. SDL, wxWidgets, and GTK all have Windows versions to my knowledge, but you have to compile them with a compiler targeting Windows to be able to get object code that can run.
Cross compiling is very messy because you need to have one copy of a library of each architecture and platform that you want to target, and they all have to be installed in different places, so you need to play with linker flags a lot.
Here's a blog post explaining how to get a GCC distribution for Linux targeting Windows. And regarding Haskell and OCaml, sadly I'm not knowledgable in these areas, but the general case will hold true.
If I have a windows compiler based dll and .lib, can I link them with a app that I am compiling with cygwin g++ ? If not, will it work with a linux g++ library build ?
Are libraries generated from windows compiler, cygwin g++ and linux g++ cross linkable ??
No there are not. Libraries and executable files are specific to an operating system and to a processor. The only thing you can consider porting is source code, if it is written with great care. Some libraries (e.g. QtCore, Gtk/Glib, ...) are abstracting a platform and give you a common API (usable on many OSes), but you still have to compile for each system.
You could target a virtual machine (like JVM thru Java, or Lua bytecode, or Ocaml bytecode, ...) to get additional portability (at the expense of the cost of the VM implementation). You could also code software as scripts (e.g. using Python).