c libraries implementation

Hello all,

Does the libc++ also implements the c standard library or only are included from

another library?

Thanks,

Constantinos

Hi Constantinos,

Does the libc++ also implements the c standard library or only are included
from another library?

You need a separate libc implementation.

Cheers.

Tim.

Hi Constantinos,

> Does the libc++ also implements the c standard library or only are
included
> from another library?

You need a separate libc implementation.

   Thanks, are any plans for a libc implementation as a llvm sub project?
if any i will be glad to help on my free time.

There are existing open source, permissively licensed, libc implementations. Derivatives of FreeBSD libc are used on Darwin (iOS / OS X), some OpenSolaris derviatives and Android. NetBSD and OpenBSD also have their own libc implementations that occasionally share code.

We welcome contributors to FreeBSD libc, if you want to work on a C standard library implementation...

David

FreeBSD has lots of good code.
MUSL http://www.musl-libc.org/ is another library with BSD/MIT license.
MingW has Windows specific code usually in the public domain.

Out of curiosity, how does clang determine what standard C libraries and headers to use during a build? Is that documented anywhere? I did a quick google search to see I saw that mechanism discussed, I don’t see a good document coming up on the topic.

-James

Do you mean when clang is being built or when clang compiles something?
The first is in the build environment.
The second depends upon the target, there are functions in InitHeaderSearch.cpp that try to locate the include dirs. The libraries come with the linker and linker switches since clang doesn’t link by itself.

thanks for the info. I was referring to the case where clang is the compiler.

So if one wanted to use an alternative set of compatible libc headers, he would merely have to provide his own header search paths rather than allow it to use the default ones?

-James

libc usually is toughly coupled to the underlying kernel.
There are FreeBSD libc, Solaris libc, Glibc on Linux or Hurd.

Using foreign libc is almost impossible, and porting it is rocket science :slight_smile:

[snip]
I'm using musl in my ELLCC project (http://ellcc.org). I'm using it as the Linux C library for arm, armeb, i386, microblaze, mips, mipsel, ppc, and x86_64. I highly recommend musl: Very nice clean code.
Other libraries my tools use are libcxx, libcxxabi, compiler-rt, and I'm currently porting libunwind to complete full C and C++ support.

-Rich

Just in case you missed it, libcxxabi now included unwind support (introduced by a very recent commit).

-- Jean-Daniel

Wow. Very cool. I will look at it. Thanks!

-Rich

Could you elaborate on the practical significance of this change? Stack unwinding is a fundamental part of C++. It doesn’t make sense that it be just added to the system. Therefore, I must not understand what you are talking about.

This looks very nice, but is there a reason that it's in libcxxabi and not compiler-rt? The equivalent code is provided by libgcc_s currently, and putting the language-agnostic part of the unwinder (used by C, C++, Objective-C, and many other languages) into the C++ ABI library doesn't seem to make sense.

David

While using zero-cost exception model, unwinding is done at runtime by parsing and interpreting external exception tables.
The code to perform such task is not part of the language nor it is generated by the compiler. You have to use some external library (like libunwind or now libcxxabi) to perform such task.

So the “zero-cost exception model” is the new feature?

Another interesting option for C library for clang toolchain on Windows is mingw-w64-crt

https://github.com/kinke/mingw-w64-crt

Tailored light-weight MinGW-w64 C Runtime (on top of Microsoft’s Visual C Runtime) to be built by Clang on Win64 and linked by Microsoft’s linker.

It covers most of the C99 functionality missing in Microsoft’s runtime (otherwise implemented in virtually all other C runtimes) and therefore simplifies code portability while allowing you to use common Windows compilers (MS, Intel etc.) and linkers instead of having to rely on the MinGW-w64 GCC eco-system.

Clang handles GCC-style C code very well and at the same time is able to output Windows COFF objects which may then be fed to the MS linker. So we use Clang to build a trimmed-down version of the MinGW-w64 runtime library and are then free to use it with all other MS-compatible compilers (e.g., the D compilers LDC and DMD on Win64). For example, we get back x87 floating-point (80 bits) support.