Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!odi!benson
From: benson@odi.com (Benson I. Margulies)
Newsgroups: comp.lang.c++
Subject: Re: munch going away?
Message-ID: <1991Feb14.132408.15862@odi.com>
Date: 14 Feb 91 13:24:08 GMT
References: <1991Feb12.144307@spatial.COM>
Reply-To: benson@odi.com (Benson I. Margulies)
Organization: Object Design Inc., Burlington, MA
Lines: 31

In article <1991Feb12.144307@spatial.COM> gad@spatial.COM writes:
>I've just come across a totally unsubstantiated rumour that all post 2.1 releases
>of the ATT C++ compiler will be patch only versions.  Is this actually true?
>If so, what ramifications does it have on ease of porting?   What are the issues 
>regarding people with libraries built with a "munch compiler" who wish to link 
>them to an application compiled with a "patch compiler" and the reverse.
>

We're a C++ licencee and beta test site. Pay no attention to this
stupid rumor.

In any case, munch mode of the compiler is a subset of patch mode.

In patch mode, the translator generates additional static structures
that patch can use to link together the constructors/destructors.  In
munch mode, it omits them. So you can always "munch" a patch-compiled
.o. 

Munch itself is a trivial program, anyone can write it in about 10
minutes.

libC.a is the only thing that is really different -- for patch, it
expects to find the "head" symbol, while for munch it expects to find
the _ctor and _dtor arrays. So your libC.a has to match your desired
patch/munch technology.

Now, if you want C++ on the RS/6000, neither munch nor patch works due
to the wonders of the AIX binder garbage collector. THAT was a project
to get by.
-- 
Benson I. Margulies