From owner-freebsd-chat  Thu Feb  6 08:22:40 1997
Return-Path: <owner-chat>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id IAA11476
          for chat-outgoing; Thu, 6 Feb 1997 08:22:40 -0800 (PST)
Received: from chai.plexuscom.com (chai.plexuscom.com [207.87.46.100])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA11452
          for <chat@FreeBSD.org>; Thu, 6 Feb 1997 08:22:35 -0800 (PST)
Received: from chai.plexuscom.com (localhost [127.0.0.1]) by chai.plexuscom.com (8.8.4/8.6.12) with ESMTP id LAA16070; Thu, 6 Feb 1997 11:21:07 -0500 (EST)
Message-Id: <199702061621.LAA16070@chai.plexuscom.com>
To: Terry Lambert <terry@lambert.org>
Cc: chat@FreeBSD.org
Subject: Re: g++, STL and -frepo on FreeBSD-2.2-Beta 
In-reply-to: Your message of "Wed, 05 Feb 1997 15:29:25 MST."
             <199702052229.PAA15792@phaeton.artisoft.com> 
Date: Thu, 06 Feb 1997 11:21:07 -0500
From: Bakul Shah <bakul@torrentnet.com>
Sender: owner-chat@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> I guess this is where the confusion is.  Is g++ without frepo statically
> typed, but with frepo, not statically typed?

There are no semantic differences at the language level. AFAIK, the
-frepo patches simply affect the *size* of the generated binary.

> You seem to be saying that the frepo patches don't work, or because
> they are known to work with ELF, that the frepo patches don't work
> with the a.out code back end and/or linker.

What does not work is stock FSF g++ plus -frepo patches under
FreeBSD.  by `not work' I mean the compile phase succeeds but the
link phase fails.  I do not know _where_ the actual error is and I
stopped worrying about it once I found out the stock FreeBSD g++
works just fine (if you avoid flags like -fexternal-templates).  The
only change is that the generated binary is bigger.

> Hmmm... have you tried running the make under gnumake?  It may be that
> there is a step not being invoked...

The makefiles are gnumakefiles so I had no other alternative.

> Thanks for the correction, too; it's always better to know what is
> going on than to think you know what is going on.  ;-).

I see an infinite recursion here :-)

-- bakul