Date: Mon, 26 Jun 2000 11:07:46 -0400
Message-Id: <200006261507.LAA12752@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
In-reply-to: <Pine.SUN.3.91.1000626154721.7682I-100000@is> (message from Eli
	Zaretskii on Mon, 26 Jun 2000 15:54:49 +0300 (IDT))
Subject: Re: GCC and the rest of us, again
References:  <Pine DOT SUN DOT 3 DOT 91 DOT 1000626154721 DOT 7682I-100000 AT is>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> For the recent round of GCC-maintainers-vs-the-rest-of-the-world series, 
> read the thread "Re: gcc compiles assert() to code that requires linking 
> with gcc" on bug-gcc AT gnu DOT org.

In that case, though, gcc is doing the best it can - there are some
thing that gcc-compiled code *needs* from libgcc.a, because they are
too complex to be handled by the compiler.  For example, it used to be
that you couldn't multiply two longs together on an i386 without
linking libgcc.a, because gcc didn't know how to do such multiplies
inline.

The fact that assert() is a borderline case doesn't change the design
decision that gcc-compiled objects may depend on libgcc.a to link.