I have installed cmake 2.8.11 and now trying to build llvm with cmake. however I am getting the following build error
Scanning dependencies of target LLVMAArch64Utils
make[2]: *** No rule to make target `lib/Target/AArch64/AArch64GenSubtargetInfo.inc', needed by `lib/Target/AArch64/Utils/CMakeFiles/LLVMAArch64Utils.dir/AArch64BaseInfo.cpp.o'.
Stop.
Does this mean that cmake does not have support for 64-bit architectire? If so, can someone tell me an easy way to add AArch64 patch to cmake 2.8.11.
This seems like a bug in build script.
See this LLVM team bug tracker item.
Tim Northover 2013-07-14 15:57:50 CDT Hi Ray,
I think this has been fixed in r182190, which unfortunately just
missed the 3.3 release itself. I'm now trying to get it into the minor
release we're trying to make.
I'll leave this open, and assigned to me (as a reminder) until that
happens.
Thanks for taking the time to report it, and I'm sorry you had to.
Tim.
Related
I'm attempting to cross-compile from Linux (NixOS) to Windows and encountering some frustrations.
There seem to be two parts that together are breaking the build:
Code in my Rust project requires multithreading, and as such requires a version of libpthread for Windows.
To build properly, I need a build.rs file. For some reason, Rust requires a version of libpthread for Linux for that.
What's the problem? Well, the build.rs has to be built with regular GCC and not MinGW because it needs to execute on my system. But for some reason, GCC is attempting to link to the Windows libpthread library instead of the system one, and as such is failing with an error about not supporting the library format.
(Failed) Alternatives
If I remove the build.rs, the project builds fine. Unfortunately, I need it for full functionality.
If I remove the Windows version of libpthread the build.rs builds and runs correctly, but MinGW fails with a missing library error when building the rest of the project.
Solution Paths?
Either I have to figure out why GCC's linking to the wrong version of libpthread, or I have to disable -lpthread entirely for the build.rs. I have no idea why it would need pthreads, considering for testing I stripped it down to only fn main() {}.
I have no idea where to start on either of these, and I've already spent a couple of days getting the problem down to this. I'd appreciate some help!
Good Morning.
I am compiling Clang, following the instructions here Getting Started: Building and Running Clang
I am on linux and the compilation goes smoothly. But I think I am missing out something...
I want to compile ONLY clang, not all the related libraries. The option -DLLVM_ENABLE_PROJECTS=clang seems doing what I want (check LLVM_ENABLE_PROJECTS here)
If I use the instructions written there, I can compile, but I think I am compiling too much....a build directory of 70GB seems too much to me...
I tried to download the official debian source and compile the debian package (same source code! just using the "debian way" to create a package from official debian source), just to compare...The compilation goes smoothly, is very fast, and the build directory is much much smaller...as I expected...
I noticed in the first link I provided the phrase "This builds both LLVM and Clang for debug mode."...
So, anyone knows if my problem is due to the fact that I am compiling a "debug mode" version? if so, how could I compile the default version? and is there a way to compile ONLY clang without LLVM?
Yes, debug mode binaries are typically much larger than release mode binaries.
Cmake normally uses CMAKE_BUILD_TYPE to determine he build type. It can be set from the command line with -DCMAKE_BUILD_TYPE="Release" o -DCMAKE_BUILD_TYPE="Debug" (sometimes there are other build types as well).
I have cloned the source for sgx-sdk from git repo. I want to build it with LLVM instead of gcc.
I have tried
make CC=clang-7 CXX=clang++-7 sdk
but it seems to be running into one problem after the other.
Eg.
There were bunch of CFLAGS options which were not compatible with clang. - I removed them.
dwarf/Gfind_unwind_table.c:59:8: error: implicit declaration of function
'_Uelf64_valid_object' is invalid in C99. ```
There were other issues before which I was able to solve by editing concerned files, but I am stuck at this point. GCC does not throw this error but clang does, and I am unable to understand why is this happening.
If my understanding is correct an implicit declaration error, if exists should be thrown by both GCC and clang.
My build machine is Ubuntu 18.04. I have clang-7 installed and have used it in past in building other applications like Nginx.
When trying to compile glibc on ubuntu 10.10, x86_64, i get the error:
../misc/syslog.c: In function ‘__vsyslog_chk’:
../misc/syslog.c:123: sorry, unimplemented: inlining failed in call to ‘syslog’: function body not available
../misc/syslog.c:155: sorry, unimplemented: called from here
make[2]: *** [/home/daniel/src/b.c/misc/syslog.o] Error 1
Try this wiki about glibc build issues.
I just ran into the same issue but with 32-bit. When running the configure script, adding CFLAGS='-U_FORTIFY_SOURCE -O2' to the command line seems to work. You may need to add -mtune=i686 and -march=i686 in there too. But maybe not for 64 bit. The i686 seems to be another bug.
Whenever you want to rebuild something on Ubuntu that Debian already, you are almost always best of by starting with the original source package on Debian.
In this particular case you can start with this version from the Debian experimental branch. By using the source package, you ensure you have required build-dependencies and should minimize surprises.
Also, building in a chroot environment is a good way to do this and made easy by packages such as pbuilder and sbuild.
Edit: There are build logs but they don't contain one for amd64, presumably because the maintainers built on that locally. But you can look at i386, say, and see that it passed the error you had.
Good day
Currently, I'm working on an embedded device based on arm-linux. I want to build GCC for my target architecture with Glibc. GCC builds successful, but I have trouble with Glibc build.
I use the latest version of Glibc (ftp.gnu.org/gnu/glibc/glibc-2.12.1.tar.gz) and port for them (ftp.gnu.org/gnu/glibc/glibc-ports-2.12.1.tar.gz)
my configuration line:
../../glibc-2.12.1/configure --host=arm-none-linux-gnueabi --prefix=/home/anatoly/Desktop/ARM/build/glibc-build --enable-add-ons --with-binutils=/home/anatoly/Desctop/ARM/toolchain/arm/bin/
configuration script work fine, but i get some compile error:
...
/home/anatoly/Desktop/ARM/src/glibc-2.12.1/malloc/libmemusage_pic.a(memusage.os): In function me':
/home/anatoly/Desktop/ARM/src/glibc-2.12.1/malloc/lmemusage.c:253: undefined reference to__eabi+read_tp'
...
I also tried using the old version (2.11, 2.10) but have the same error.
Does anybody know the solution for this problem?
Use a precompiled toolchain, like those provided by code sourcery.
If you want to make your own, optimised (premature optimization is the root of all evil), use crosstool-NG, which is a tool dedicated to cross-compilation toolchain building.
If you are not convinced, and want to do everything with your own hands, ask your question on the crosstool-NG mailing list.
Try substituting arm-linux-gnueabi for arm-none-linux-gnueabi. Check that a compiler, loader etc. with the prefix you used for "host" exist on your path.