Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!hpfcdc!stroyan
From: stroyan@hpfcdc.HP.COM (Mike Stroyan)
Newsgroups: comp.sys.hp
Subject: Re: S.O.S. LISP and Starbase problem.
Message-ID: <5570152@hpfcdc.HP.COM>
Date: 12 Apr 89 18:52:06 GMT
References: <204@goya.dit.upm.es>
Organization: HP Ft. Collins, Co.
Lines: 26

I am not familiar with HP-Common Lisp II, but am familiar with Starbase.
Apparently the load-foreign-libraries operation loads all .o files in an
archive without regard to referenced entry points.

The "asm_strlenfieldwidth" symbol is from /lib/libpc.a, and is part of
the Pascal language binding.  Linking with -lpc should take care of it,
as long as you have the Pascal compiler installed on your system.  Leaving
the symbol unresolved shouldn't be a problem.  It is only used when calling
Starbase from Pascal.

The gopen error message is also related to the .o files loaded.  There
are stub routines in -lsb2 for the window system open code loaded from
-lwindow.  The stub routines are being used instead of the window system
routines.  This makes gopen complain that /dev/screen/FOO is not a
graphics device file.  (It is in fact a pty.)  You should be able to make
the window library code be used instead of the stub by changing the
order of the libraries in the load-foreign-libraries call.

Change
  (load-foreign-libraries nil '("-lc" "-ldd300h" "-lsb1" "-lsb2" "-lwindow"))
to
  (load-foreign-libraries nil '("-ldd300h" "-lwindow" "-lsb1" "-lsb2" "-lc"))

Mike Stroyan, stroyan@hpfcla.hp.com

P.S.  Thank you for providing complete configuration information.  It helps.