[comp.unix.xenix] Xenix 2.3 development upgrade problem

jbayer@ispi.UUCP (Jonathan Bayer) (04/28/89)

Greetings, netlanders.

     I recently upgraded my SCO Xenix development system from the 2.2 to
the 2.3 system.  Now a program that used to link with no problems now
has unresolved external references.  The references to wstandend() and
wstandout() are due to a redefinition of those functions in the
libraries.  However, it appears that the other functions either are
missing or are located in a place where the loader can't find.  The
unexplained errors are all coming from the standard libraries.  Any
ideas?  I have looked for these routines in all the libraries, but can't
find them.  The errors also occur with a smaller program in this system.
A final note:  all of the source code is Microsoft Pascal except for one
module which is used to interface between the pascal program and the O/S.


This is the link line:

cl  -Ml2 -o ../bin/matcher -F 7000  \
        /usr/interface/p.o newunits/xnx.o newunits/xa.o newunits/xv.o \
        newunits/xw.o newunits/db.o \
        newunits/print.o newunits/fileio.o newunits/fkam.o \
 alloc.mod.o     initsel.mod.o   misc5.mod.o     reporter.mod.o  sch14.mod.o   \
 create.mod.o    main.mod.o      pass.mod.o      reports.mod.o   search.mod.o  \
 create15.mod.o  maint.mod.o     quest.mod.o     rglobal.mod.o   search2.mod.o \
 create2.mod.o   matcher.o       quest25.mod.o   rptdelet.mod.o  search3.mod.o \
 create3.mod.o   misc.mod.o      quest26.mod.o   rptedit.mod.o   search4.mod.o \
 create4.mod.o   misc2.mod.o     quest3.mod.o    rptprint.mod.o  sort.mod.o    \
 global.mod.o    misc3.mod.o     quest35.mod.o   rptsort.mod.o   temp.mod.o    \
 global2.mod.o   misc4.mod.o     rep3.mod.o      sch12.mod.o     menu.mod.o    \
 xenix.mod.o     temp1.mod.o     vread.mod.o     ez.mod.o        ezmisc.mod.o  \
 gchange.mod.o	\
 -lcurses -ltermcap -link -S 180




and these are the errors:


/bin/ld : error: Unresolved externals:



__aFlmul in file(s):
 /lib/Llibc.a(ctime.c) /lib/Llibc.a(calloc.c)
__aFNalmul in file(s):
 /lib/Llibcfp.a(atof.c)
__aFNaldiv in file(s):
 /lib/Llibcfp.a(fdoprnt.c)
_wstandend in file(s):
 newunits/xa.o(SUPERASM)
__aFldiv in file(s):
 /lib/Llibc.a(ctime.c) /lib/Llibcfp.a(fdoprnt.c)
__aFlrem in file(s):
 /lib/Llibc.a(ctime.c) /lib/Llibcfp.a(fdoprnt.c)
_wstandout in file(s):
 newunits/xa.o(SUPERASM)

-- 
Jonathan Bayer			      Beware: The light at the end of the
Intelligent Software Products, Inc.	      tunnel may be an oncoming dragon
19 Virginia Ave.				...uunet!ispi!jbayer
Rockville Centre, NY 11570  (516) 766-2867    jbayer@ispi.UUCP

daveh@marob.MASA.COM (Dave Hammond) (05/02/89)

In article <599@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes:
>     I recently upgraded my SCO Xenix development system from the 2.2 to
>the 2.3 system.  Now a program that used to link with no problems now
>has unresolved external references.  The references to wstandend() and
>wstandout() are due to a redefinition of those functions in the
>libraries. [...]

Results of `cd /usr/include; grep wstand *.h':

tcap.h:# define	wstandout(win)	CURVOID(wattron(win,A_STANDOUT))
tcap.h:# define	wstandend(win)	CURVOID(wattroff(win,A_STANDOUT))
tinfo.h:		scrollok(), wstandend(), wstandout(); 
tinfo.h:#define	standend()	wstandend(stdscr)
tinfo.h:#define	standout()	wstandout(stdscr)
tinfo.h:#define wstandend(win)		wattrset((win),A_NORMAL)
tinfo.h:#define wstandout(win)		wattron((win),A_STANDOUT)

The new curses simply defines wstand* as wattron/wattroff macros.

[ Jonathan, I expected less obvious problems from _you_ :-) :-) ]

--
Dave Hammond
daveh@marob.masa.com

jbayer@ispi.UUCP (Jonathan Bayer) (05/09/89)

}Greetings, netlanders.
}
}     I recently upgraded my SCO Xenix development system from the 2.2 to
}the 2.3 system.  Now a program that used to link with no problems now
}has unresolved external references.  The references to wstandend() and
}wstandout() are due to a redefinition of those functions in the
	[ deleted ]
}
}This is the link line:
}
}cl  -Ml2 -o ../bin/matcher -F 7000  \
}        /usr/interface/p.o newunits/xnx.o newunits/xa.o newunits/xv.o \
}        newunits/xw.o newunits/db.o \
}        newunits/print.o newunits/fileio.o newunits/fkam.o \
} alloc.mod.o     initsel.mod.o   misc5.mod.o     reporter.mod.o  sch14.mod.o   \
} create.mod.o    main.mod.o      pass.mod.o      reports.mod.o   search.mod.o  \
} create15.mod.o  maint.mod.o     quest.mod.o     rglobal.mod.o   search2.mod.o \
} create2.mod.o   matcher.o       quest25.mod.o   rptdelet.mod.o  search3.mod.o \
} create3.mod.o   misc.mod.o      quest26.mod.o   rptedit.mod.o   search4.mod.o \
} create4.mod.o   misc2.mod.o     quest3.mod.o    rptprint.mod.o  sort.mod.o    \
} global.mod.o    misc3.mod.o     quest35.mod.o   rptsort.mod.o   temp.mod.o    \
} global2.mod.o   misc4.mod.o     rep3.mod.o      sch12.mod.o     menu.mod.o    \
} xenix.mod.o     temp1.mod.o     vread.mod.o     ez.mod.o        ezmisc.mod.o  \
} gchange.mod.o \
} -lcurses -ltermcap -link -S 180
}
}and these are the errors:
}
}/bin/ld : error: Unresolved externals:
}
}__aFlmul in file(s):
} /lib/Llibc.a(ctime.c) /lib/Llibc.a(calloc.c)
}__aFNalmul in file(s):
} /lib/Llibcfp.a(atof.c)
}__aFNaldiv in file(s):
} /lib/Llibcfp.a(fdoprnt.c)
}_wstandend in file(s):
} newunits/xa.o(SUPERASM)
}__aFldiv in file(s):
} /lib/Llibc.a(ctime.c) /lib/Llibcfp.a(fdoprnt.c)
}__aFlrem in file(s):
} /lib/Llibc.a(ctime.c) /lib/Llibcfp.a(fdoprnt.c)
}_wstandout in file(s):
} newunits/xa.o(SUPERASM)


The following is an answer I received from someone at SCO. 
Unfortunately all I have is his account, "sco!jeffj".  I received a
number of replies from other readers, but this was the only correct
answer.  It turns out that this was the tip of a worm, and SCO is
currently re-evaluating a number of products which might have this
problem.  Thank you "jeffj", whoever you are.


>The wstandend and wstandout are now macros, and you
>can fix that problem by simply recompiling the modules
>that refer to them.  You seem to have already solved that
>one.  The other routines are all defined in the library
>/lib/libh.a, a set of helper routines for the compiler.


JB
-- 
Jonathan Bayer			      Beware: The light at the end of the
Intelligent Software Products, Inc.	      tunnel may be an oncoming dragon
500 Oakwood Ave.				...uunet!ispi!root
Roselle Park, NJ   07204    (201) 245-5922    jbayer@ispi.UUCP