<div dir="ltr">GNU likes to use non standard extensions for convenience while LLVM/Clang would like stick to the standards.<div><br></div><div>Unless GNU adopts a more standards compliant behavior OR LLVM decides to relax their adherence to the standards</div><div>the tools will always be somewhat incompatible w/o major work.</div><div><br></div><div>For example recent changes to the Linux Kernel adopted GNU goto asm; which means that Clang will not compile</div><div>the kernel; </div><div><br></div><div>I am not sure how far LLVM is willing to bend over to please the GNU nor am I certain GNU will become more</div><div>standards complaint anytime soon.</div><div><br></div><div>You might try the route of patching glibc but that might not be the best use of your time.</div><div>There are other c implementations out there.</div><div><br></div><div>Best</div><div><br></div><div><div class="gmail_quote"><div dir="ltr">On Mon, Dec 24, 2018 at 12:01 AM Alberto Barbaro via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hi,<div dir="auto">Could you keep us posted, or at least me? I'm interested to compile glibc as well and obtain the bitcode.</div><div dir="auto"><br></div><div dir="auto">Would you consider to use <a href="https://www.musl-libc.org" target="_blank">https://www.musl-libc.org</a> in the meantime?</div><div dir="auto"><br></div><div dir="auto">Thanks</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Dec 23, 2018, 12:00 Kristina Brooks via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi.<br>
<br>
Actually from reading the README, it seems to imply that it can be built<br>
with Clang 6.0.0 and above now, though it does incorporate a lot of patches not<br>
specific to Clang building so you will end up with them as well:<br>
<br>
----------------------------------------------------------------------------<br>
BUILDING GRTE WITH CLANG<br>
<br>
GRTE v5 and later can also be built with clang and (optionally) lld.<br>
LLVM support for GNU source code continues to evolve (as of June<br>
2018), so the process is less straightforward, and likely to change<br>
from what is documented here.  There are a number of glibc patches<br>
that make this work, including additional configure options mentioned<br>
below.<br>
<br>
The minimum version of clang is 6.0.0.  If lld is to be used for linking,<br>
it needs to be newer than 6.0.0.<br>
<br>
Configure:<br>
<br>
  CC=path-to-llvm/clang CXX=path-to-llvm/clang++ \<br>
    ../glibc/configure --disable-werror --with-clang --disable-float128 \<br>
      --with-lld --with-default-link --disable-multi-arch --prefix=/something<br>
------------------------------------------------------------------------------<br>
<br>
On 23/12/2018 02:51, Kristina Brooks wrote:<br>
> Hi.<br>
> <br>
> 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<br>
> 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<br>
> very easy to work with.<br>
> <br>
> I can upload it somewhere, not sure if there is any general interest in this kind of thing. I think current GRTE may<br>
> also be build-able with Clang (my fork was based on older GRTE which had unfinished patches to support Clang), though I<br>
> haven't had the time to look at that recently.<br>
> <br>
> I should add a huge disclaimer: this won't be easy and requires understanding the macro hell in glibc, GRTE relies on<br>
> some hacky uses of `_Pragma` to supplement for some macros otherwise not possible with Clang. Even if you do get it to<br>
> 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<br>
> they're not being exported).<br>
> <br>
> Thanks.<br>
> <br>
> On 22/12/2018 09:29, xuruobin via llvm-dev wrote:<br>
>> To whom it may concern,<br>
>><br>
>>      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?<br>
>><br>
>> Thanks,<br>
>> Ruobin.<br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><br>
> <br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div>