Is there a way to build glibc with clang/llvm? I’m working on enabling llvm-cov for my compiler which is a totally new arch with a libc.a built from newlib. I successfully built compiler-rt but when I typed the command ` clang++ --target=xxx -fprofile-instr-generate -fcoverage-mapping foo.cc -o foo`, the linker failed because of undefined reference to `mmap'/`ftruncate'/`mkdir'. I found these functions are supported by glibc but I cannot bulid glibc with clang/llvm(configure gave me an error “These critical programs are missing or too old: compiler”). So I want to know how can I compile glibc with clang/llvm or are there some WIP patches to help me with this requirement?
I've managed to do it before, with a lot of patches to Glibc, as well as ld.so and getting basic programs to start with
it. However, a lot of tests did not pass and in general I abandoned it due to the fact that Glibc source code is not
very easy to work with.
I can upload it somewhere, not sure if there is any general interest in this kind of thing. I think current GRTE may
also be build-able with Clang (my fork was based on older GRTE which had unfinished patches to support Clang), though I
haven't had the time to look at that recently.
I should add a huge disclaimer: this won't be easy and requires understanding the macro hell in glibc, GRTE relies on
some hacky uses of `_Pragma` to supplement for some macros otherwise not possible with Clang. Even if you do get it to
build I think it may be a waste of time to try and just implement the missing symbols in your case (or figure out why
they're not being exported).
Actually from reading the README, it seems to imply that it can be built
with Clang 6.0.0 and above now, though it does incorporate a lot of patches not
specific to Clang building so you will end up with them as well:
GNU likes to use non standard extensions for convenience while LLVM/Clang would like stick to the standards.
Unless GNU adopts a more standards compliant behavior OR LLVM decides to relax their adherence to the standards
the tools will always be somewhat incompatible w/o major work.
For example recent changes to the Linux Kernel adopted GNU goto asm; which means that Clang will not compile
the kernel;
I am not sure how far LLVM is willing to bend over to please the GNU nor am I certain GNU will become more
standards complaint anytime soon.
You might try the route of patching glibc but that might not be the best use of your time.
There are other c implementations out there.
Such is the case for most compilers, Clang supports extensions such as blocks for example, which IIRC date
back to before C++11 lambdas or around the same time. There's a lot of other implementation specific differences
for example in attributes.
Anyway, skipping that point, Glibc upstream isn't actively trying to work with Clang compliant unlike mainline Linux,
as you may guess from the name Glibc is a GNU libc, aimed to work and be built by the GNU Compiler Collection aka
GCC. If we look at a non-GNU libc such as, say, Bionic, currently it's built with a Clang based toolchain.
If you want a starting point for building Glibc forks with Clang, I mentioned one already, if the documentation
is correct, it has decent Clang support but YMMV.
Is your only problem that you don’t have definitions for mmap/ftruncate/mkdir?
If so, then you don’t need to compile glibc. You merely need to solve the problem you actually have: you need a C library for your system calls.
I have no idea what operating system you are running on your target, but the function names suggest it’s Unix-like. Unix-like operating systems typically implement system calls as a trap to the operating system using an instruction specially built for this purpose. To this end, the “mmap” function in glibc merely arranges to get the arguments in the correct registers (or possibly the stack), and then invokes the proper trap. Perhaps 10 lines of assembly in all.
If you can figure out the calling convention for your system calls, then you can easily write your own syscall library in assembler, for each call you require, which you can then link in, in addition to whatever else you are using.