Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!uwm.edu!genbank!apple!fox!portal!cup.portal.com!Nagle
From: Nagle@cup.portal.com (John - Nagle)
Newsgroups: comp.lang.c++
Subject: Zortech C++ vs Metagraphics Metawindow vs various linkers
Message-ID: <24525@cup.portal.com>
Date: 28 Nov 89 03:33:18 GMT
References: <870@sys.uea.ac.uk>
Organization: The Portal System (TM)
Lines: 47


      I've recently upgraded to Zortech 2.0, and am trying to recompile a
previously-working program that uses Metagraphics Metawindow.  The result
is a finger-pointing exercise involving Zortech, Metagraphics, and Polytran.
Here's the situation:

      Zortech provides a linker of their own, called "BLINK".  With 2.0,
it's not mandatory that you use BLINK to link Zortech programs, but it
does supposedly provide some extra diagnostics if you do.  Unfortunately,
the BLINK provided with 2.0 won't handle an object file with "threads"
in it; "FIXUP" error messages are produced.  The file "FINDMETA.OBJ" in
the Metawindow library has "thread" type relocation, which bombs BLINK.
The old BLINK, shipped with C++ 1.09, handled this correctly, but the new
one doesn't.

      The Zortech manual claims that C++ will work with Metawindow, but
they use Metawindow Plus, the expensive version.  (Regular Metawindow
has a TSR that does the work and a library that is really just interfacep
routines.  Metawindow Plus is a true linkable library.  The licencing
is more compicated for Metawindow Plus, and it costs more.)

      Zortech technical support suggested that I talk to Metagraphics
about the problem, and also suggested using a different linker, until
they could find out what's wrong with BLINK and fix it.  They acknowledge
that there is a problem.

      Instead of BLINK, I tried Plink86 Plus, the big linker from 
Polytron.  It complained about a "B0" type record in the file "fclose.c"
in the "ZLL" library from Zortech.  Examination of ZLL.LIB indicated that
there were about a half dozen files named "fclose.c".  This isn't the only
duplicated file name in the library, either.  There is one "B0" record in
one of the "fclose.c" files, and it mentions the symbol "__atexitp". 
The library is difficult to manipulate because of the duplicated files;
you're not supposed to build libraries like that, and I'm unable to
extract the defective file with PLIB86, Polytran's library utility,
because it isn't the first one with that name.

      I called Polytron to ask about this error.  They don't know what
a "B0" record is; their Intel linker format manual doesn't mention it.
It won't link with a rather ancient version of the IBM linker, either,
by the way, so it doesn't appear to be Polytron's fault.  

      Tomorrow I call Zortech again.  

      Does anyone have a workaround for this?

						John Nagle