Using MinGW and CMake I've compiled LLVM, Clang and Compiler-RT both via SVN or using the released source code (3.2).
I've modified InitHeaderSearch.cpp (in tools/clang/lib/frontend) to find GCC 4.7.2 headers.
I've set the compile options to Release and disabled assertions.
Clang seems to work properly, but it takes 4-5 seconds to start: even typing "clang --version" in the console does this. Compiling a projects takes a lot of time.
What am I missing? I've used rubenvb's old MinGW+Clang build (GCC 4.6), and it didn't have this problem. Is there any compilation flag I need to use?
This issue is discussed here http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-April/020651.html
AFAIK problem is caused by large relocation table and inefficient MinGW implementation (http://sourceforge.net/p/mingw/bugs/1747/).
Adding -static flag to linker flags should resolve this issue. You should invoke cmake with
-DCMAKE_EXE_LINKER_FLAGS=-static -DCMAKE_MODULE_LINKER_FLAGS=-static
Related
I tried almost a hundred things to make this works but nothing seems to be working.
I recently acquire a Mac book pro M1 MAX (so arm64 architecture), system provided by default with clang g++.
I wanted to install boost library. Using homebrew the 1.80 version was installed but I need to work on a project with the 1.65.1 version (I tried compiling my project with 1.80 version and tons of undefined symbols and errors were raised from boost library even if I have all of them, so I'm guessing I need to install the exact same version required)
so I decided to build and compile boost by myself following the boost guide
https://www.boost.org/doc/libs/1_65_1/more/getting_started/unix-variants.html
Following section 5.1 I tried to use the bootstrap script and this one fails using Darwin toolset. (apparently some Clang warning caused error). I resolve then by changing the boost source code like this :
https://github.com/boostorg/build/commit/48e9017139dd94446633480661e5447c7e0d8b1b
But there's still lot of issues during the compilation
I don't know what to do to be able to compile with clang, I don't even know if this will be compiled for arm64 architecture.
anyway I install gcc compiler and tried with gcc toolset.
./bootstrap --with-toolset=gcc
The bootstraps works but then running the b2 script cause a segmentation fault instantly and on every commands I tried (even the --help options raised an exception...).
Why is building boost so complicated on arm chipset ?
What can I do to build boost (either clang or gcc, arm or cross compiled universal library) ?
I'm desperate at this point.
Thanks for the help.
I tried everything
with clang (darwin)
with gcc
with options to add arm64 as architecture
changing the source code of boost to fix
I have a cc_library (tbb) that requires the compiler flag -mwaitpkg on some compilers (Clang) to compile successfully. At the same time, there are older versions of GCC (4.9) that do not know this flag, and therefore the compilation via GCC 4.9 leads to an error:
gcc: error: unrecognized command line option '-mwaitpkg'
In a more advanced Bazel setup, I guess one would work around this using hermetic toolchains. This way every toolchain could provide its own set of compiler flags. Nevertheless, I do not want to enforce any specific toolchain and I am not sure if this is the right way to go (move copts to toolchain?).
Also introducing a config would be a way to solve this problem. E.g. bazel build --config=waitpkg //.... But this would require that a user is aware of this config and also knows the details of using waitpkg.
What is a proper "Bazel-way" to handle different compiler flags for different compilers?
The flag '-mwaitpkg' is supported by GCC version 9.3, Clang* 12, and newer versions of those tools.
If you build Bazel with earlier versions of GCC, you should remove the flag otherwise it gives compilation errors.
I have a code running on a PowerPC e500v2 embedded Linux and I want to measure its performance since it is running in an infinite loop. I tried gcc's gprof which was simply by adding -pg option to gcc. When I run the binary on the target device I get this:
./main: /lib/libc.so.6: version GLIBC_2.16 not found (required by ./main)
I am using ELDK 5.6 toolchain with the default CFLAGS and LDFLAGS and these flags: -Wall -lrt -pthread -D_GNU_SOURCE nothing else. Some article suggested defining FORTIFY_SOURCE along with an optimization level but it did not work. I searched for some gcc's feature test macros and tried defining some GLIBC 2.16 specific macros but it did not work.
I faced similar issue with GLIBC 2.17 when I used some structures and functions from <sched.h>, adding _GNU_SOURCE resolved it. Any idea on how to resolve it?
When I run the binary on the target device I get this
Your tool chain targets a version of GLIBC that is newer than what is installed on the target.
This doesn't bite you in non-pg compiles only by accident. An "innocent" change to your source can cause the same problem.
You need to upgrade your target to the version of GLIBC which your toolchain actually builds for.
I'm trying to compile CMake using a non-default GCC installed in /usr/local/gcc530, on Solaris 2.11.
I have LD_LIBRARY_PATH=/usr/local/gcc530/lib/sparcv9
Bootstrap proceeds fine, bootstrapped cmake successfully compiles various object files, but when it tries to link the real cmake (and other executables), I get pages of "undefined reference" errors to various standard library functions, because, as running the link command manually with -Wl,-verbose shows, the linker links with /usr/lib/64/libstdc++.so of the system default, much older GCC.
This is because apparently CMake tries to find curses/ncurses libraries (even if I tell it BUILD_CursesDialog:BOOL=OFF), finds them in /usr/lib/64, and adds -L/usr/lib/64 to build/Source/CMakeFiles/cmake.dir/link.txt, which causes the linker to use libstdc++.so from there, and not my actual GCC's own.
I found a workaround: I can get the path to proper libraries from $CC -m64 -print-file-name=libstdc++.so then put it with -L into LDFLAGS when running ./configure, and all works well then.
Is there a less hacky way? It's really weird that I can't tell GCC to prioritize its own libraries.
Also, is there some way to have CMake explain where different parts of a resulting command line came from?
So I just downloaded mingw-w64-bin_i686-mingw_20110410.zip from here (GCC 4.7 apparently), and discovered it had a very recent version of the GCJ compiler.
I tried using it, but apparently gcj requires ecj1.exe, which is the Eclipse compiler for Java... so, where do I find a compatible version of the binaries of ECJ and the associated Java libraries that are needed (libgcj, etc.)?
Ideally this would be found on the MinGW-w64 project page, but it doesn't seem to exist.
(I've already tried copying them from a slightly older GCC version; it doesn't work.)
The cause for an openSUSE version of the gcc is basically this:
If the configure step of the compilation of gcc did not find the ecj.jar
file, ecj1 will be missing at the time when gcj, which has just been build,
is called.
ecj.jar can be taken from ftp://sourceware.org/pub/java/ecj-4.8.jar
for example.
The two options are:
i) Put ecj.jar in $HOME/share/java/ecj.jar, reconfigure gcc with
./configure .... --with-ecj-jar=$HOME/java/ecj.jar
and recompile gcc. Future compilations with that gcc will not require
ecj1 .
ii) Put ecj.jar in $HOME/share/java/ecj.jar and create ecj1(.exe)
through a compilation like
gcj -o$HOME/bin/ecj1(.exe) --main=org.eclipse.jdt.internal.compiler.batch.GCCMain $HOME/share/java/ecj.jar
assuming that the $HOME/bin is in the PATH for subsequent calls of gcj.
The thing that is actually "broken" here the fact that gcc 4.8.* is not shipped
by default with ecj.jar at some standard place.
That is a very old version of a MinGW-w64 toolchain.
I would suggest downloading one of my builds, I've had reports of gcj working (without libgcj, which does not work on Windows), although I can't seem to find a link to the discussion I had long ago with a user. The user's case had something to do with creating a JNI interface or something, which didn't require libgcj.
My old builds can be found here for 32-bit and here for 64-bit. I checked the 4.8 release build, and it contains the gcj compiler.
Would you be opposed to downloading the source and building it? I looked over the build doc in basic and advanced build docs. I didn't see anything about the GCJ compiler or ECJ, but you'll need gcc 4.5.1 in order to build it.