So here's the situation: I need to be able to compile binaries from a Linux machine (on Ubuntu, for what it's worth) which are able to run from a SPARC server. The program I'm trying to compile is very simple:
#include <stdio.h>
#include <stdlib.h>
int main() {
printf("Testing the SPARC program...");
return EXIT_SUCCESS;
}
I've tried a number of different compile lines to get it to work, but unfortunately nothing appears to be working.
I tried the traditional:
clang -target sparc blah.c -o blahsparc
But this doesn't work, with a bunch of assembler failures:
/tmp/blah-519e77.s: Assembler messages:
/tmp/blah-519e77.s:7: Error: unknown pseudo-op: '.register'
/tmp/blah-519e77.s:8: Error: unknown pseudo-op: '.register'
/tmp/blah-519e77.s:9: Error: unknown pseudo-op: '.register'
/tmp/blah-519e77.s:10: Error: unknown pseudo-op: '.register'
/tmp/blah-519e77.s:11: Error: no such instruction: 'save %sp,-240,%sp'
/tmp/blah-519e77.s:12: Error: no such instruction: 'st %g0, [%fp+2043]'
...
clang: error: assembler (via gcc) command failed with exit code 1 (use -v to see invocation)
I've tried this also:
clang -cc1 -triple "sparc-unknown-Linux" blah.c -o blahsparc
which complains about the missing headers, so instead of using -cc1, I use -Xclang:
clang -Xclang -triple -Xclang "sparc-unknown-Linux" blah.c -o blahsparc
however, this also fails due to "error: unknown target CPU 'x86-64'".
I'm not sure where to proceed with this. I've tried using crosstool-ng as well with very little success.
As of the 3.4.2 release (June 2014), llvm is missing code necessary to be able to generate object files for sparc targets. Older releases (1.x & 2.x) had support for it, but llvm's framework for emitting object files was less mature back then. When the current framework was rolled out it looks like they didn't migrate all platforms.
The documentation seems to imply that a combination of llvm/gcc is known to work, but I think that table was tabulated based on a much earlier version of llvm when they had a less mature framework for emitting object files.
Support for emitting object files was added to their SVN trunk in revision r198533 (this thread discusses the commit), but as you can see in the 3.4.2 final release, files & changes added in r198533 aren't present.
As an aside, clang currently isn't functional in sparc solaris (not sure about sparc in general). The parser seems to have trouble parsing templates; I get coredumps & the like. I ran across a thread a week or so ago discussing alignment problems in sparc/solaris clang, and this may be one of the reasons clang isn't yet usable on this platform.
If you need a cross compiler for Sparc that runs on an Ubuntu machine, the simplest way I know of is to use Buildroot. Here's a small tutorial on how to obtain a cross compiler and test the generated executables on a Sparc emulator.
LLVM 3.6.2 has some support for sparc now... I was able to build llvm 3.6.2 and clang 3.6.2-r100 on my T2000. I haven't gotten C++ support working but I have built moderately complex C applications like htop.
I did compile LLVM using gcc 5.2 however I lower version should work as well although I'd suggested at least gcc 4.9 and no lower than gcc 4.7.
The LLVM emerge on gentoo crashed during the compile but I was able to resume it by moving to the portage directory with the llvm ebuilds and restarting the build manually:
cd /usr/portage/*/llvm/
ebuild llvm-3.6.2.ebuild merge
I had to override some of the default compiler:
CC="clang -target sparc-unknown-linux-gnu"
CXX="clang++ -target sparc-unknown-linux-gnu"
CFLAGS="-O2 -pipe"
CXXFLAGS="${CFLAGS}"
I don't know if you will be able to use this to build from an x86 machine... though clang is supposed to be able to do that. But worst case you might be able to get this going in qemu-system-sparc64 vm or on some real hardware that you can find cheap on ebay (T5xxx hardware is coming down in price and blades are dirt cheap)
I recently updated to clang 3.8 (which is as yet unreleased) and I was able to compile a c++ application by passing -lstdc++ in addition to the options above. I believe this is the same behavior as gcc when invoked as gcc rather than g++.
Related
When I try to run the go unit test system with the memory sanity checking I get an error message that I am sure I use to solve by setting my compiler to CLANG.
The Go Command Documenation is a little brief on the matter.
-msan
enable interoperation with memory sanitizer.
Supported only on linux/amd64, linux/arm64
and only with Clang/LLVM as the host C compiler.
On linux/arm64, pie build mode will be used.
In the past I was use I got this to work by calling:
CC=clang go test -msan ./..
However when I do that now I get errors such as:
g++: error: unrecognized argument to -fsanitize= option: ‘memory’
What do I need to do in order to run my golang tests with the memory sanitizer under Ubuntu 18:04 ?
I am using the following versions of tools at the moment:
$ go version
go version go1.14 linux/amd64
$ clang --version
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
It requires a version of LLVM that supports -fsanitize=memory on your version of Ubuntu 18.04 that the program runs on. Please try updating and then try it again.
Also do note, on Linux you need at least LLVM 3.8 to get the -fsanitize flag.
The Go tool automatically adds the -fsanitize=memory option to CGO_CPPFLAGS flag as required by clang for linking and that's where it's resulting in an error for you.
Also, make sure to add both CC and CXX (for clang++) flags so to enable compilation using Clang when you're interop your program with C/C++ i.e.,
CC=clang CXX=clang++ go build -msan
Also do refer this link:
https://go.googlesource.com/go/+/go1.7/misc/cgo/testsanitizers/test.bash (bash script)
(or)
https://github.com/golang/go/tree/master/misc/cgo/testsanitizers (*.go files)
It will help you test the sanitizers if they would work on your setup or not.
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 have been using Armadillo 4.2 version (from linux mint package manager) for quite a some time. That version had no problem when compiled with icc, and codes compiled with icc ran very fast (about 10%-15% fast compared to g++).
Recently I have upgraded Armadillo to recent 6.1 version (from the official website). But in this case, all the codes compiled correctly with icc, but gave runtime error.
error: eig_sym(): failed to converge
terminate called after throwing an instance of 'std::runtime_error'
what(): eig_sym(): failed to converge
Aborted
Codes compiled correctly with g++ ran perfectly.
I have also tried previous 5.6 version, but the same problem.
Any solutions?? I had to revert back to old 4.2 version to get that extra speed from icc...
The Intel C++ compiler is known to contain of bugs when dealing with heavily templated libraries like Armadillo (see for example here and here).
You can increase the performance of gcc compiled code by enabling auto-vectorization (using -O3) and using the native machine instruction set (using -march=native). For example:
g++ code.cpp -o code -O3 -march=native -larmadillo
Also make sure that the matrix you're passing to eig_sym() is actually symmetric.
I got my self an ARM based development board (NVIDIA Jetson K1).
The thing is already equipped with Ubuntu system. I was able to use gcc 4.8 directly on the device, but it doesn't contain g++. Installing g++ with apt-get as usual wouldn't work because nobody ever bothered to maintain a complete ppa supporting ARM architecture.
Now I tried to compile the latest GCC manually. Everything went smooth when I compile and installed the requirements (MPC, MPFR, GMP). But I failed building GCC itself, and found out that the mad error in config.log telling me that a working C++ compiler can not be found.
I believe there must be a way to get a working g++ compiler working on the device itself rather than having to cross compile. Does anyone have a clue on how this can be done?
The message is right. GCC 4.8 is written in C++ so it needs to be compiled with a C++ (cross) compiler.