I actually require CLANG tool. Please let me know whether I can build CLANG from GCC 4.1.2 or I need to have LLVM. If so, would GCC 4.1.2 build both LLVM and CLANG?
Also I need some source-to-source translation (C++ code beautification - inserting new code and comments in between) reference - please provide some reference example if possible?
My observation is that downloading LLVM / CLANG from their offical site via svn / git is very time consuming. It takes around 1 hour to download just 5% of their code. What are the tar file I need to deploy so that I can overcome this one?
Thanks in advance
svn: REPORT request failed on '/svn/llvm-project/!svn/vcc/default'
svn: REPORT of '/svn/llvm-project/!svn/vcc/default': Could not read response body: connection timed out. (http://llvm.org)
install_packages/LLVM 1004> git clone http://llvm.org /git/llvm.git
Cloning into llvm...
remote: Counting objects: 655903, done.
remote: Compressing objects: 100% (123416/123416), done.
error: RPC failed; result=18, HTTP code = 200MiB | 2 KiB/s
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
warning: http unexpectedly said: '0000'
I checked out the complete LLVM repository and it took under 10 minutes for me.
Following instructions from their website you can easily build LLVM and CLANG.
There is no issue, in my opinion, in building LLVM and CLANG source code using GCC as I have done it multiple times. LLVM and CLANG use modern C++ and GCC supports it just fine.
GCC is the most used open source compiler in the world and supports more platforms than any other compiler can dream of. So, I am not at all surprised when I see GCC building LLVM or CLANG.
But I use the latest GCC compiler on my system. Try building LLVM and CLANG with GCC 4.1.2(released, February 13, 2007). If it does not work out, which I doubt, try upgrading GCC.
Related
I have spent a few hours trying to get the built-from-sources version of clang (v15) to work with the memtag sanitiser. For those of you who don't know what that is, it is simply a version of the address sanitiser that leverages the Memory Tagging features of ARM.
Anyway, while I can use it normally with the repository version of clang (v10), using the version built from sources just does not work.
Here is the command I use for both: clang main.c -S -march=armv8+memtag -fsanitize=memtag with clang which is either the repository-version or the built-from-sources version. Although the former works seamlessly, the latter does not.
I've tried to built llvm with different parameters, but none seemed to have done the trick. Here's my current building configuration:
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;lld;lldb;openmp;polly;pstl;compiler-rt" -DLLVM_TARGETS_TO_BUILD="AArch64" ../llvm
I wonder if there is some parameter I have to specify to build clang with this sanitiser enabled.
PS: using the -fsanitize=memtag flag does not give any error: with the built version of clang it simply does not insert the instrumentation code.
If anybody is able to give me some insight I would really appreciate it. Thanks ;)
Trying to convert a large gcc/makefile project into clang. Got it roughly working for x86, but now I'm trying to get cross compilation working.
The way it currently works is that we use Linaro's 7.1.1 arm compiler alongside its companion sysroot directory for base libraries/headers. I installed clang-6.0 and then the base clang(not sure if that mattered).
I used some commands I found to redirect clang to clang-6.0 and when I execute 'clang -v' and got
clang version 6.0.0-1ubuntu2~16.04.1 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
....
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/9
....
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.5.0
....
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.4.0
Candidate multilib: .;#m64
Selected multilib: .;#m64
It does not find the current compiler we use which is at
/usr/local/gcc-linaro-7.1.1-2017.08-i686_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++(also a directory for *x86_64*)
I only found references to setting --sysroot, but not to a specific compiler. Definitely still lost about the relationship between clang+llvm+other compilers. I even saw somewhere saying I needed to compile llvm before I could use it?
I very roughly made changes in our make files to get the following output, basically all I had to add was '-target arm-linux-gnueabuhf' and reordered the mcpu/mfloat/marm/march so they came after -target in case it mattered
clang --sysroot=/usr/local/sysroot-glibc-linaro-2.25-2017.08-arm-linux-gnueabihf -c -std=c++0x
-g -DDEBUG_ON -target arm-linux-gnueabihf -mcpu=cortex-a7 -mfloat-abi=hard -marm -march=armv7ve
-Wall -fexceptions -fdiagnostics-show-option -Werror .... -I/usr/local/gcc-linaro-7.1.1-2017.08-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/include .... and many more
I think the problem probably lies with the change I made which is the actual 'clang' call that replaced
/usr/local/gcc-linaro-7.1.1-2017.08-i686_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ ....
End up with
fatal error: 'cstdarg' file not found
#include <cstdarg>
As said before I can already cross-compile with gcc, so I've already come across issues with std libraries that require 'build-essentials', 'g++-multilibs', etc. So they're already installed.
Looked and really haven't found anything too useful to me, I'm on linux mint 18.3 and the closest things I found were issues people had on mac and windows.
So I came across some posts mentioning setting --gcc-toolchain=/your/choice/of/cross/compiler but they also mention it not working. I discovered that if you combine this with the installation of llvm-6.0-dev(or maybe llvm-6.0-tools, tools installed dev so not 100%) it at least worked for me.
Any compiler clang or gcc needs to know where a header file is defined. The standard headers, standard libraries, c-runtime, and libc are all packaged together for each target e.g., arm64, x86 in a directory called 'sysroot'. When we compile a program we need to pass the path to sysroot for a compiler to know where to look for standard headers during compilation, and where to look for common libraries (libc, libstdc++ etc) during linkage.
Normally when we compile a program for the same machine the compiler uses the standard headers available in '/usr/include' and libraries from '/usr/lib'. When cross-compiling programs we should supply the sysroot as compiler flag. e.g. gcc --sysroot="/path/to/arm64/sysroot/usr" test.cpp. Same for clang. Most often pre-packaged cross compilers come with a script/binary that has 'sysroot' path embedded into it. e.g., aarch64-linux-gnu-gcc (https://packages.ubuntu.com/xenial/devel/gcc-aarch64-linux-gnu).
... the closest things I found were issues people had on mac and windows.
On mac the clang compiler will have the similar configuration as linux. So the details you found there should be totally applicable to yours.
More details on sysroot and cross-compilation:
https://elinux.org/images/1/15/Anatomy_of_Cross-Compilation_Toolchains.pdf
While I'm running my COBOL code:
$ cobc hello.cob
I'm getting an error:
clang: error: unknown argument: '-R/opt/local/lib'
(Today,) I installed GnuCOBOL as root with
$ port selfupdate
$ port install open-cobol
Yeah, this has to do with Apple aliasing gcc to clang, but clang isn't a drop-in replacement for gcc yet. So it breaks on a few things. There is no simple way to fix this. If you type gcc you get clang.
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
I'm not going to list all the details here, (and I know links are frowned on here on SO, but the entire thread will need to be read to get to grips with this problem. (Scripts are involved that strip some arguments out).
There is very little the GnuCOBOL compiler authors can do about this. The Mac clang is actually defining GNUC as well, so the compiler code that tests for gcc features is currently ineffective, clang reporting itself as gcc. Under a real gcc, the run-path setting in the ELF output is necessary, so -R can't just be yanked out. I see this as slightly dirty pool on Apple's part, but, it is their system, to wall off as they see fit.
http://sourceforge.net/p/open-cobol/discussion/help/thread/e1b4af35/
Changes to GnuCOBOL will try and workaround the issue, but that may take a while to get out into the wild.
I've compiled Z3 from sources at codeplex. Configuration details:
Operation system Debian 5.0 (Lenny)
GLIBC 2.7
GCC 4.4.3
OpenMP 4.3.4 (package version)
When I try to build the c example I get:
../../lib/libz3.so: undefined reference to `std::ctype<char>::_M_widen_init() const#GLIBCXX_3.4.11'
When I try to build the c++ example I get:
../../lib/libz3.so: undefined reference to `omp_init_nest_lock#OMP_3.0'
../../lib/libz3.so: undefined reference to `omp_unset_nest_lock#OMP_3.0'
../../lib/libz3.so: undefined reference to `omp_set_nest_lock#OMP_3.0'
../../lib/libz3.so: undefined reference to `omp_destroy_nest_lock#OMP_3.0'.
The examples mentioned were downloaded previously from Z3 website. When I build the test_capi example, which comes along with the source code, I get the union of the error messages above.
What is the nature of the problem? Are there any prerequisites for the system for using Z3?
On another Debian 6.0 machine everything goes smoothly.
Thanks in advance.
I'm assuming you are using the official src release or master branch. If that is the case, could you try to compile test_capi using in the test_capi directory?
gcc -o test_capi -I ../lib test_capi.c -L ../bin/external -lz3 -lstdc++ -lgomp
In the command above we are explicitly telling gcc to link with the C++ standard and OMP libraries.
For the c++ example, you just need to include -lgomp, since g++ will link with the C++ standard library by default. You can find other missing dependencies using ldd:
ldd ../bin/external/libz3.o
That being said, I'm working on a new build system for Z3, you can try it by getting the unstable branch from codeplex. Could you give a try? It would be great to have your feedback to make the build to go smoothly in many more platforms.
I'm trying to build Firefox from source and I'm getting hung up on some of the requirements.
I'm trying to build libIDL, which requires glib. I got glib built and installed to /usr/local, but when I try and configure libIDL, I get a failure at:
checking for LIBIDL... configure: error: Package requirements (glib-2.0 >= 2.4.0) were not met:
No package 'glib-2.0' found
I used the very latest version of glib that I can find, ftp://ftp.gtk.org/pub/glib/2.20/glib-2.20.3.tar.gz
However, I've also been searching around and am seeing references to libglib-2.0 such as at http://packages.debian.org/search?keywords=libglib2.0-dev
Are there 2 divergent branches of Glib, like a v1 and v2?
You need to install glib-devel in order to have the glib headers exist on your system. Without the headers, autoconf will mark the library as missing.
You installed glib from source which should have worked. The actual problem was most likely with the paths you chose to install into. The autoconf script may not be looking for glib where you installed it, or it may be looking into another directory first and finding an old version.