C11.2.2) Other undefined entries (compiler import error)
Description
This article is from the FAQ, by with numerous contributions by others.
C11.2.2) Other undefined entries (compiler import error)
Question:
I experience errors from the linker concerning undefined entries, and I am
sure that all of my slots are bound. What is wrong?
Answer:
You may have encountered a situation where the internal import tables of the
compiler gets confused because two of your slots have identical names.
Consider:
main.bet:
ORIGIN '~beta/basiclib/v1.6/betaenv';
INCLUDE 'foo';
--PROGRAM: descriptor--
(#
do foo
#)
foo.bet:
ORIGIN '~beta/basiclib/v1.6/betaenv';
BODY 'foobody';
-- LIB: attributes --
foo:
(# size: (# s: @integer <<SLOT size:dopart>> exit s #);
do size -> putint; newline;
#)
foobody.bet:
ORIGIN 'foo';
INCLUDE 'bar';
-- size: dopart --
do (&bar[]).size -> s
bar.bet:
ORIGIN '~beta/basiclib/v1.6/betaenv';
BODY 'barbody';
--LIB: attributes--
bar:
(# size: (# s: @integer <<SLOT size:dopart>> exit s #)#);
barbody.bet:
ORIGIN 'bar'
-- size: dopart --
do 1 -> s
Although somewhat stupid, you would expect this program to print "1" onto
the screen. And it does so on most platforms. But on the platforms hpux9pa
(HPPA 9000/700 running HP-UX 9) and nti (Windows 95 / Windows NT), when
assembling the code produced for foobody, you get an error like
undefined label - M2BAR
The reason for this, is that the compiler gets confused by the two dopart
slots both tagged with "size".
The solution is to use two distinct names, e.g. foosize and barsize. Such a
naming scheme is advisable to use in general - notice that if the two SLOTs
had been of kind Descriptor, then on all platforms, you would get
multiply defined: M1SIZE
Continue to:
My Books
