Sebastian wrote: > Ok, maybe I had a wrong idea of how OpenMP works. I thought that the > thread handling is realized somehow within OpenMP without the need for > an operating system, because in the end you run an application > directly on top of the hardware without an OS in between... You can't have threads without something to schedule them and provide the other general bookkeeping/resource management tasks, which is the job of the kernel/OS. > Let's assume I'll take uClinux, what are the additional steps I have to take? Well that's really just the start of a long process. Next you need to decide which ABI you want, the old ABI (--target=arm-uclinux) or EABI (--target=arm-uclinux-gnueabi). This generally concerns how floating point is handled: oABI uses hardfloat FPA with software emulation on systems without FPA, which is slow. EABI allows for softfloat as the default with the option to mix in hardfloat that's appropriate for the specific device (VFP, iWMMXt, etc.) so that emulation is avoided. There are other differences between the two, so you'll need to research it. Next you need to decide which libc you want to use, e.g. uClibc, EGLIBC, glibc, newlib, etc. You're currently using newlib, but I don't know if that is the best choice. And now for the really bad news: doing this all from scratch is really hard; you're building a full operating system from nothing after all. There's a chicken and egg problem in that to build a full gcc, you need the libc headers already. But normally you don't have a libc yet if you don't have a compiler, so you can't build a full gcc as the first step. So you have to go through this process of first building a stripped down gcc, then using that to build your libc, and then finally rebuilding a full gcc with everything enabled. The kernel presents a further wrinkle in this plan because the libc usually has a dependence on kernel headers, which means you need those available before you start to build your libc -- a three way chicken and egg problem between compiler, kernel, and libc. If you want to continue down this line I suggest you check out the crosstool-NG script (and the crossgcc mailing list) which automates most of this awful process. However I think that crosstool-NG supports only linux, not uclinux. You'd have to double check that. There's a much easier way of course. Just take an existing uclinux distro/binary image that's appropriate for your device and install it. Someone else has already gone through the pain of working out which kernel version works with which libc version and which ABI, and which gcc version and with what options, and has built everything already. You can then take a sysroot of this existing system: that is replicate the /usr/include and /usr/lib (and whatever else, e.g. /usr/lib64) of the target system under some directory on the host system. Then add --with-sysroot=foo to your options and you can build gcc in one step. Of course this means that you're obligated to use that same system on the device; if you try to use the resulting cross compiler with some other combination of kernel/libc/ABI you could be in for all kinds of strange breakage. But this is the general theme of the whole message: gcc does not exist in a vacuum, it exists in a context of a specific target which represents a lot of other software and configuration details as well. When building gcc it's not about "I'd like it for target architecture <x>", it's "I'd like it for target <x,y,z> operating system". Brian
