Nagle@cup.portal.com (John - Nagle) (11/28/89)
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 Naglekc@rna.UUCP (Kaare Christian) (11/29/89)
In article <24525@cup.portal.com>, Nagle@cup.portal.com (John - Nagle) writes: > > 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. I don't have a solution for this particular problem, but I would like to throw in my two cents on the topic of using external libraries and device drivers with ztc 2.0. I had a working 1.07 ztc program that linked with an external library supplied by #9 computer (nnios). Their library is just glue that hooks up to their device driver, which then goes out to a special graphics board. Anyway, getting that previously working setup to work with ztc 2.0 required: 1. Fixing up the declarations and function prototypes. There was a half day's work here, because the old declarations were sloppy, and not all of the actual functions matched the prototypes exactly. 2. Fixing up the linkage. This took a while to find. The nnios library accesses their device driver via a far function pointer, which is made to point at the driver entry point. The device driver, originally written to work with C, does a far return and follows ordinary C stack cleanup conventions. Unfortunately the far pointer's declaration was embedded in code using C++ linkage, hence ztc was generating C++ style calls and cleanups. Anyway, switching the pointer declaration to C linkage made everything work. This was unpleasant to find because there aren't any error messages, and each trial lead to a system crash. Kaare Christian kc@rna.rockefeller.edu
bright@Data-IO.COM (Walter Bright) (11/30/89)
In article <24525@cup.portal.com> Nagle@cup.portal.com (John - Nagle) writes:
<the BLINK provided with 2.0 won't handle an object file with "threads"
<in it
I fixed the problem with threads. You can download it from my BBS
at (206) 822-6907. The problem was I had accidentally deleted a line of
code in the thread stuff... it was never noticed because my code generator
never generates threads.
< 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.
A B0 record is a COMDEF record. You'll find it documented in the
MSDOS Encyclopedia. It is necessary in order to specify common blocks
to the linker. Microsoft has made several extensions to the object file
format (some are undocumented). I'm surprised that plink86 won't handle
COMDEFs. Perhaps you have an old version of it?kipd@hpclad2.HP.COM (Kip Davidson) (12/01/89)
I don't have a work-around, however I do have some input about the 'B0' record. A 'B0' record is a Microsoft corruption of one of INTEL's records from their OMF spec. The 'B0' record is what Microsoft calls a "COMDEF" (communal var defination) record. If you want more details please let me know and I will e-mail it to you or post it. Kip Davidson Internet : kipd@hpda