I'm under Ubuntu 12.04 x86 64 bit, I have compiled a 32 bit version of llvm/clang from the official svn repository successfully.
I'm now trying to compile c++ code for ARM, at this point i don't care about platform versions like armv5 vs armv7a, I'm focusing on how the platform switch works for clang:
llvm-config --targets-built
ARM CellSPU CppBackend Hexagon Mips MBlaze MSP430 NVPTX PowerPC Sparc X86 XCore
but the following command doesn't work
clang++ -arch arm soft.cpp -o soft_ARM
the output is
clang-3: warning: argument unused during compilation: '-arch arm'
I have also tried gcc-like variants or other combinations like -arch=arm, -arch=armv7a, -march=armv5 but nothing seems to work.
After reading some docs i noticed that clang works for ARM only under MAC OS X / Darwin and it's not supposed to work for ARM under other OS.
How i can compile for ARM with clang and what the output of llvm-config --targets-built is really about ?
-arch is darwin-only feature. You should use -target on non-darwin platforms. Alternatively, compile llvm/target specifying target triplet or create a link from clang to -clang. In your case the target triplet would be arm-none-linux-gnueabi
Related
Looking for cross compiler that could help me build application for Raspberry Pi on my Ubuntu 20.04 machine. I found official tools on Github and I suppose that folder arm-bcm2708 contains cross compilers:
arm-bcm2708hardfp-linux-gnueabi
arm-bcm2708-linux-gnueabi
arm-linux-gnueabihf -> arm-rpi-4.9.3-linux-gnueabihf
arm-rpi-4.9.3-linux-gnueabihf
gcc-linaro-arm-linux-gnueabihf-raspbian
gcc-linaro-arm-linux-gnueabihf-raspbian-x64
I'm confused what directories names is trying to tell me? I know following words:
arm - processor type used on Pi
bcm2708 - processor model used on pi
gnueabi - cross-compiler for armel architecture (you can build binary for ARM on PC)
linaro - company that creates multimedia for ARM
4.9.3 - I suppose is GCC compiler version (why it is so old?)
Which of compilers I should use for my Pi3 and Pi4?
You can use one of the toolchains provided by ARM for your RPI3/4.
If you are running a 32 bit Linux on your RPI3/4, use one of the arm-none-linux-gnueabihf toolchains, if use are running a 64 bit Linux on your RPI3/4, use one of the aarch64-none-linux-gnu one.
Both 10.2 and 9.2 versions of the two toolchains are working fine on my own Ubuntu 20.04.1 LTS x86_64 system. Of course, you can cross-compile programs with the arm-none-linux-gnueabihf toolchain and run them on the 64 bit Linux running on your RPI3/4 as well.
I have been using the GNU ARM Embedded Toolchain for a while and compiling my embedded C++ code using arm-none-eabi-g++, because it is what we did in my embedded systems university courses. For my computer science courses we used just g++ to compile C++ code. I have been poking around the GCC manual and found that there are ARM architecture compilation options for GCC. My question is what is the difference between using arm-none-eabi-g++binary provided by ARM and g++ with the -mcpu=cortex-m4 -march=armv7compile option for cross-compiling? It appears you can cross-compile for ARM using gcc (gcc that comes with Ubuntu).
I think I figured it out. So using GCC you can build a cross compiler and an associated toolchain. ARM built their own cross compiler and put it up for people to use as the "Official GNU ARM Embedded Toolchain". It's basically a meta "I used the compiler to build the compiler problem". The options -mcpu=cortex-m4 -march=armv7 I was seeing was for targeting architectures when building GCC, not to be when compiling.
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.)
How can I make use of llvm as clang backend to compile C++ files without using gcc as clang's backend?
I am pretty sure clang is using gcc because
$ clang++ --version
clang version 6.0.1 (tags/RELEASE_601/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
it uses gnu as target instead of llvm. My llvm-config output:
$ llvm-config --version --targets-built
6.0.1
X86
I built both clang and llvm from source using standard options for my build target(X86).
EDIT: I think it is using gcc as backend because this code produces error in online ide but works on my machine with clang++ and g++. Code relies on fact that gcc has implementation of policy based data structures which are not part of standard.
The problem is in the interpretation of the data. The target that clang refers to has to do with the platform for which you are generating code.
x86_64 This is a 64 bit processor compatible with Intel/and
unknown I'm uncertain about this one, though I believe it specifies more detail about the processor, which ain't available
linux You are using a Linux kernel/operation system
gnu The object structure should follow the gnu standards, I believe this directly maps on ELF
This will be different if you use BSD or windows as OS, or when your processor is an ARM, Intel 32 bit, Spark ...
The only moment you should be worrying about the target is when you are cross compiling. In other words, if the computer on which you are running the compiler has other requirements for the executable structure than the machine on which you will be running it.
PS: Clang always uses LLVM for it's IR. ignoring the deprecated Clang+C2, it always uses the LLVM optimizer and code generator.
I am attempting to setup a small build cluster at home using distcc. There are two x64 systems and 1 i686 systems. All systems are running Ubuntu 10.10 and are up to date. The system that is initiating the build is x64. Distcc works fine between the two x64 systems but all build tasks sent to the i686 system fail.
So far:
I have installed the multilib package for g++ on that system. I am able to cross-compile to x64 locally using g++ -m64
Changed the link in /usr/lib/distcc/g++ to point to a script that explicity sets the -m64 parameter.
Any suggestions?
Attempting this one again after more research:
GCC has a page describing the i386 and x86-64 options. The -m64 flag says to generate 64-bit code, but you'll also want to specify the type of CPU with -march=i686 or -march=k8 or similar, to use the correct instruction set.
Since distcc sends the GCC command line flags out, you should try adding these to the distcc command running locally and skip the remote script for setting flags.
If you test the architecture flags on your local x64 machine without distcc, just g++, then it should give you the right binaries when using distcc.