[haiku-development] Re: [haiku-commits] haiku: hrev43838 - build/jam -- clang / llvm

  • From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 12 Mar 2012 00:51:07 +0100

Paul Davey wrote:
> > The compiler does have to provide the C and C++ runtime environments. In 
> > case
> > of gcc 4 those live in libgcc and libsupc++ (with gcc 2 things are a bit
> > messier). IIRC the early clang ports used the gcc runtime. I don't know, if
> > that is still the case. Ideally clang would be fully self-contained and 
> > provide
> > its own runtimes.
> >
> > Unfortunately on BeOS and Haiku libgcc is linked into libroot, which is a
> > questionable strategy as it might make switching the compiler problematic.
> 
> libgcc is a set of low level routines to work around the lack of
> floating point arithmetic on some platforms as well as other related
> routines.
> glibc is the C runtime environment, combined with the crt*.o files
> somewhere in gcc.
> Similarly libsupc++ is a set of support stuff for new and exception
> handling, not the whole C++ standard library which lives in libstdc++.

I haven't checked whether the nomenclature is defined somewhere. I was 
intuitively using runtime for the stuff that is required to make the basic 
language features work (libgcc, libsupc++, plus the glue code) as opposed to 
the standard libraries ([g]libc, libstdc++) which implement, well, standard 
functions, classes, etc.

> Clang uses whatever gcc4 uses on haiku, it uses gcc4 to call the
> linker since it has not been given a toolchain description for Haiku,
> when we do this we could replace some parts of gcc and I would like to
> port and use a freeBSD libc for the C standard library, libc++ can be
> ported for the C++ standard library at some point.

Replacing the standard libraries doesn't really replace parts of the compiler. 
I don't know how closely the gcc project and the GNU standard C++ library 
project are related, but -- and that's why I was pointing out the 
runtime/standard library separation -- as long as both adhere to the same ABI 
either part (compiler and standard library) can be replaced with a different 
implementation. At least with gcc 4; gcc 2 is a mess.

> My point is that using clang to build executables does not produce any
> dependencies on llvm or clang libraries, only on the libs already
> included in haiku.

That's what my previous mail was aiming at: A compiler which requires part of 
another equivalent compiler (its runtime) is just incomplete. While that may be 
great for using clang compiled libraries and programs, it prevents us from 
switching over to clang.

CU, Ingo

Other related posts: