[LLVMdev] Clang/Clang++ standard headers?

Mikael Lyngvig mikael at lyngvig.org
Mon May 28 11:01:48 PDT 2012


So, on Windows, Clang(++) will always depend on either Mingw (or Microsoft,
once the force_inline issue is resolved).  I'm only asking because the
Windows norm is that the compiler ships with everything needed - tools,
libraries, and headers.

Assuming LLVM optimizes better than GNU, wouldn't it to some extent make
sense to rebuild the GNU libraries using Clang(++) and then ship the
result?  Or, perhaps, even rebuild the GNU C and C++ libraries into bitcode
modules that are then link-time optimized once the user links?

Anybody know what the GNU license permits?  Would it be okay to take a
Mingw64 build, replace the tools, and then ship the result?

I must say that I feel that the whole procedure, from first stumbling
across LLVM to building your own C++ program succesfully, is rather long.

Now I'm battling some unresolved symbols such as __imp_htonl.  The
reference to htonl() is in my own code, but I am a "ld" newbie.  I seem to
recall from the ancient past that "ld" is extremely peculiar about how you
order your libraries.  Oh, well, I'll figure it out eventually.


Cheers,
Mikael
-- Love Thy Frog!

2012/5/28 Joerg Sonnenberger <joerg at britannica.bec.de>

> On Mon, May 28, 2012 at 07:42:12PM +0200, Mikael Lyngvig wrote:
> > Does Clang/Clang++ not have its own set of standard headers?  Isn't this
> a
> > serious issue if Clang/Clang++ is ever to outdo GCC/G++?  Is there any
> work
> > in progress on this?
>
> It provides the compiler-centric headers. It doesn't replace the rest of
> the C runtime library. That wouldn't make much sense.
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120528/263ac9fd/attachment.html>


More information about the llvm-dev mailing list