[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Proposal for new organization of gcc
From:       Richard Earnshaw <rearnsha () arm ! com>
Date:       1998-01-21 10:57:43
[Download RAW message or body]

>     This won't work.  gcc needs cc1 in order to build libgcc.a,
> 
> That's true.  In fact, I think this is a show-stopper: unless we make
> it possible to compile libgcc2.c with whatever C compiler you use to
> compile GCC (not easy since it uses GCC features), we can't possibly
> support building other languages without C.  We could perhaps make it
> work to compile libgcc2.c using C++, if you don't build the C
> compiler, but what if you choose to build only Fortran, Pascal or Ada?
> 

Currently currently libgcc.a contains a range of functions for different 
roles.  Some are to support the core compiler (back end), eg functions to 
support primitive operations such as division (eg divsi) and some are 
language specific, like __eprintf (mainly for C's assert) or __builtin_new 
(C++).

I don't think it is feasible to build the core compiler functions without 
a gcc (though a native CC is also needed on many platforms for libgcc1 
functions), but it shouldn't be necessary to build a completely new gcc to 
compile these if gcc is already installed on the machine.

Perhaps one solution for the multiple sub-libraries problem is for the 
build/install process to merge any existing libgcc.a with the new 
functions that are required, creating a single super-library that contains 
support routines for all the installed compilers.  This would certainly be 
possible with Unix archive libraries, and probably most other OS's.  It 
wouldn't work if libgcc were made into a shared library, but there are 
probably other issues there as well.

[prev in list] [next in list] [prev in thread] [next in thread]