Subject: Re: Can we trim the fat from gcc3, please?
To: Todd Vierling <>
From: Frederick Bruckman <>
List: tech-pkg
Date: 06/15/2003 12:07:15
On Sun, 15 Jun 2003, Todd Vierling wrote:

> On Sun, 15 Jun 2003, Frederick Bruckman wrote:
> : 2) It makes it hard to test and troubleshoot the "gcc3" package
> : itself.
> Huh?

The whole thing takes almost three hours to build on a dual PIII/500.
Just c and c++ takes about 30 minutes (as I recall).

> : I posted a patch in PR pkg/21848. If folks are already relying on gcc3's
> : "gcj", I suppose I could make another package for them, although I'd
> : really rather someone else did that. It actually looks to be fairly
> : trivial to clone the package with a different "--with-lang".
> You haven't even tried using "--with-languages" yet, have you?

My patch actually uses "--enable-languages=c,c++", not "--with-lang".

> : The only hard part will be making sure certain files (such as
> : "libiberty.a") don't conflict, and of course, finding a host that can
> : actually build it, and a day or two to do so.
> Building the Java bits requires building the C and C++ bits in full, so a
> "full gcc3" package *will* conflict with a "non-java gcc3" package.

That's too bad. Is it possible to build the java bits with an
installed compiler? Maybe something short of a full bootstrap?
That way, the java package could just depend on the C/C++/F77.
The would be the ideal solution.

> Again, how about a "pkgtools/gcc3"  for the stripped down version and leave
> the full version to work as gcc3 "normally" builds?

I'm not happy with that idea. It would make more work for maintainers.

> As an alternative:  Make a Makefile variable such as GCC3_EXTRA_LANGUAGES
> that defaults to empty and can be changed in mk.conf to modify what
> languages are built for the pkg.  This would be added to the list "c c++
> f77" that is put into LANGUAGES when building gcc3.  And since gcc3 already
> uses dynamic PLIST generation, you have no problem in creating a proper
> PLIST for the requested languages.

Yes, that would be easy, but then no gcc3-java binary package.

By the way, any idea why we're keeping gcc-2 and pgcc around? Doesn't
gcc-3 do it all, and do it better?