jms@spatial.COM (Jim M. Sharpe) (02/13/91)
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. Does anyone know about any tools to resolve the differences between versions at link time? Thanx in advance. -- Jim Sharpe / jms@spatial.com
benson@odi.com (Benson I. Margulies) (02/14/91)
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