This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Merge cc1, cc1plus, etc?
- From: "Sam Lauber" <sam124 at operamail dot com>
- To: "Mike Stump" <mrs at apple dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 23 Dec 2004 00:44:16 +0100
- Subject: Re: Merge cc1, cc1plus, etc?
OK then. I'm experienced in getting my feet wet (literally) because I live in Hawaii. And as I type this, it is as wet
as wet can get outside. I can only test it on one architechure (my i686 GNU/Linux box), but I'm sure most of the
architechures are close to the x86. I think I'll just work on it locally, and gradually tweak and test it. As far as
I'm concerned, I think I have a good idea of how it goes through collect2. It goes through collect2 at the last stage
of the compilation. Running collect2 appears to just search for ld and execute it. That part shouldn't be that hard,
but agian, you never know.
Samuel Lauber
> One way to get this done, would be to start with a small subset and
> work on it, get it done and in, and then expand.
>
>> 6) Merge collect2 in to the gcc1 executable.
>
> I think this is desirable and doable and would provide a way to get
> your feet wet...
> I'd start with one target, examine all the ways in which it goes
> through collect2, and then fold _that_ functionality into the
> driver (gcc.c) for that target get that in, then do another target,
> and then at the end, you can do AIX. :-)
>
> I think this subpart is non-controversial and desirable, though, it
> would have to go into a post 4.0 tree.
>
> I don't see that a branch would be necessary for this sub-part.
--
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.
Powered by Outblaze