|
Icetips Article
Back to article list
Search Articles
Add Comment
Printer friendly
Direct link
ABC: Some discussion on include file problems (C5)
1999-03-04 -- Fobert J. Lerner
Newsgroups: topspeed.products.c5ee
Alexey was kind enough to allow me to excerpt his problem-resolution
email to me which contains linker information which some might find of
interest. I'm providing it as kind of a diary so that the reader can
get a sense of Alexey's thought process. Thoughts like "boy is this
guy dumb" have been omitted to conserve space.
The Problem
---------------------
I've got a 16-bit C5 app called CF which has a dictionary-defined TPS
file called CUS_ORGS. I have a source module with my own defined procs
called RLCLIENT. When I compile I get a warning (which appears in my
CF.MAP file) of:
CUS_ORGS$ORGS:RECORD : type inconsistency, files involved are
e:\clarion5\obj\release\cf.obj and
e:\clarion5\obj\release\rlclient.obj
The only reference I to make in RLCLIENT to CUS_ORGS was in
assigning the file to a file reference variable in one of the procs.
However, even after removing that completely, and erasing the two OBJ
files, I still get the warning.
Alexey NG Response
----------------------------------
Declarations of CUS_ORGS.Record in CF.CLW and RLCLIENT.CLW are
not the same.
My (Insightful) NG Response
----------------------------------------------
But CUS_ORGS is not mentioned at all in RLCLIENT.CLW?
Alexey NG Response
----------------------------------
The message means exactly the thing I've written. Why it could be?
I think, RLCLIENT is a MEMBER of CF. So, it include implicitly all
global declarations but some of them can be in other context, say,
some EQUATE has another value or so. If you'll send me CF.OBJ and
RLCLIENT.OBJ, I can look exactly.
Alexey's Email Response (After Getting Files)
---------------------------------------------------------------------
I think, the problem is in CF module. I suspect, it uses some old
INCLUDE files for its compilation. I not see any references to
ORGS_CUS.Record in the RLCLIENT.OBJ but on attempt to link these OBJ
files I've found that CF.OBJ contains incorrect type record for INI
Manager class VMT (this is a table for INIClass virtual methods).
Perhaps, _ABCDllMode_ symbol is redefined in PRUNEQU.CLW or
PRUNAPI.CLW (what are they?). Can you send me entire APP+DCT and other
files required for compilation?
My Email Response
--------------------------------
The two PRU... files come from the PowerRUN templates (giving better
Run(wait) support). But these were just added within the last few
days, long after I started getting the error message.
The project is being done under a subcontract deal with a large
accounting/consulting firm who in turn is doing it for one of their
large clients. We all had to sign all sorts of legal stuff about not
releasing this or that. So I'll check with them and get back to you if
I get approval. Thanks very, very much for the offer.
Once last question: if the CUS_ORGS file is part of a relation with
another file named in RLCLIENT, would that possibly have something to
do with it?
Alexey's Response
-----------------------------
Ok. Can you send me CF.CLW and CF.MAP files? I still suspect that you
have some data objects dependent from flags like _ABCDllMode_ but
these flags have different values for different source modules.
In answer to your question re. can a relation having some bearing:
No. In two words, how the linker works. There are 3 kind of names in
source modules:
1) Declared somewhere in the module and local there. The compiler
generates no records for such names in the module's OBJ file;
2) Declared somewhere in the module and visible outside it. The
compiler generates an PUBDEF record for such names in the module's OBJ
file;
3) Declared somewhere out of the module and visible within it. The
compiler generates an EXTDEF record for such names in the module's OBJ
file.
In the OBJ file all references to particular name are represented as a
reference to correspondent PUBDEF or EXTDEF record. As easy to
understand, in all program's OBJ (and LIB - library is just a set of
OBJ files) files should contain one and the only PUBDEF record for
every not local object(variable or function) and 1 EXTDEF record per
every other OBJ file where it is referenced.
When the linker is need to resolve some EXTDEF record it looks in
other OBJ and LIB files for PUBDEF with the same external name. If it
can't find such PUBDEF record, it reports the following link time
error:
.... is unresolved in file
Besides the external name the compiler includes in PUBDEF and EXTDEF
records an extra byte with encoded information about type of this
name. The linker checks that this type byte has the same value in the
EXTDEF record and its correspondent PUBDEF record. If this condition
is violated, the linker reports a _warning_
.... : type inconsistency, files involved are
and
In many cases such warning could be ignored, e.g. many C/C++ functions
can't be prototyped exactly in CW programs and, say, C/C++ addresses
can be replaced with CW LONGs. The linker detects inconsistency but it
is not sufficient. Your case is other: the linker reports about
inconsistency in data structures. This means, that some module treats
the data object in other way as it has been declared.
So, if some variable, FILE, function, etc. is not _directly_
referenced in the source module, the OBJ file not contains PUBDEF or
EXTDEF for it. RI is not an exception.
Alexex's Response After Getting Files
----------------------------------------------------------
Thanks, I've found that have wanted to get. I'm practically sure now
that your APP references ABC library files from C4. Do you have C4
installed as well as C5, so? I wrote you about warning concerning
INIClass I'd got.
Your MAP file shows:
...
0001:04AE VMT$INICLASS
0001:04B4 TYPE$CONSTDESCRIPTORLIST
...
I.e., INIClass VMT takes 6 bytes only. This means, that INIClass your
APP uses has no VIRTUAL methods. This is true for C4 but not for C5.
You _should_ use C5 version of ABC library in C5 made programs.
Check out your APP related files (INCs, RED, etc.) for references to
C4.
My Response
---------------------
I've been doing file searches for references to Clarion4. So far, the
only thing I've been able to come up with are:
1. A bunch of references to icons and bitmaps existing in the old
Clarion 4 directory; and
2. The following Path reference in my autoexec.bat file
E:\CLARION5\Bin;D:\CLARION4\Bin;C:\PROGRA~1\MICROS~5\OFFICE;%PATH%;D:\CLARION4
\BIN;D:\CLARION4\3RDPAR~1\GAP\CLACOMW;D:\CLARION4\3RDPAR~1\CLACOMW;E:\CLACOMW\GETHOS~1;E:
\CLACOMW\CLIENT~1
Could the path statement have anything to do with it? And yes, I still
have Clarion 4 installed.
Alexey's Response
-----------------------------
Sorry, I was incorrect - sometimes it's need to sleep . I've used
latest pre-C5A ABC library and, of course, it has been inconsistent
with your OBJ files. But with ABC library from SR-1 I was able to
emulate your program linkage without any warnings, including ones
about types inconsistency in CF.OBJ and RLCLIENT.OBJ . I've noticed
that the MAP file you've sent me there is no warnings' texts.
Let begin from the start again. Do you still have this problem? Can
you compile the program with line numbers (see Debug Tab of the
Project Editor dialog) and send me OBJs and the MAP with a warning
again? When line numbers option is turned on OBJ and MAP files contain
much more data for tracing.
My Response
----------------------
You're sorry? You're sorry! You don't know from 'sorry'. the
walking, living, breathing definition of 'sorry'. 'Why?' you ask:
Because the problem has disappeared from my end. But I didn't notice
it and ended up wasting your time! I am sorry. Something I did
between when I generated the MAP with the error message (the one I
sent you), and when I sent you the latest files, made the problem
disappear. Alexey, I have no idea what it was, except that perhaps the
evil Bug Spirits learned were on the case, got scared, and ran
way with their tale between their legs.
Alexey's (Gracious) Response
----------------------------------------------
I have 4 version of C5 installed on my computer and sometimes
forgetting to change path to made particular one as "main" and getting
strange things. I think, in your case was something similar: your
program used files (INC or OBJ) made with other version.
Today is April 19, 2024, 3:23 am
This article has been viewed 35490 times.
Google search
has resulted in 93 hits on this article since January 25, 2004.
Back to article list
Search Articles
Add Comment
Printer friendly
|
|
|
