ibm@bosco.dit.upm.es (Ignacio Bellido Montes) (04/11/89)
Hello, this is an S.O.S. call for all the people who knows something
about HP-Common Lisp II (from Lucid) and Starbase.
Whe are trying to call some code written in C (that uses Starbase and
Windows 9000) from LISP. The libraries used are charged on the Lisp
environment, that only tells a warning telling that a symbol
(asm_strlenfieldwidth) si not defined.
This is not a great problem (I hope) (where is this symbol defined?),
the real problem apears when trying to initialize Starbase, it returns an
error:
Starbase Error 8: Hardware especified is not installed on this system.
procedure name : gopen
file descriptor : 5
device file name : /dev/screen/FOO
library location : HP300 driver (4)
The function perror() prints out "Invalid argument".
This is not all, if we compile and run the program out of the LISP environment,
as an executable program...
IT WORKS !!! (funny, isn't it?)
The order of the libraries used when loading them on the LISP
environment must be the next one (using the LISP command):
(load-foreign-libraries nil '("-lc" "-ldd300h" "-lsb1" "-lsb2" "-lwindow"))
If some one of you knows the answer, please answer us by News or
e-mail.
For more help, we have an HP 9000-350 Workstation with HP-UX 6.21 and
an 98547A High Resolution Display Adaptor (6 planes).
============================================================================
Ignacio Bellido Fernandez-Montes,
Departamento de Ingenieria de Department of Telematic
Sistemas Telematicos (dit), Systems Engineering,
Laboratorio de Inteligencia Artificial. Artificial Intelligence Laboratory.
Universidad Politecnica de Madrid. Madrid University of Technology.
e-mail: ibellido@dit.upm.es or Phone: Work: 34 - 1 - 5495700 (62) ext 368
ibellido@goya.uucp Home: 34 - 1 - 2533365
TELEX: 47430 ETSIT E Fax: 34 - 1 - 2432077
============================================================================stroyan@hpfcdc.HP.COM (Mike Stroyan) (04/13/89)
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.cjames@hplchm.HP.COM (Craig James) (04/13/89)
> The order of the libraries used when loading them on the LISP > environment must be the next one (using the LISP command): > (load-foreign-libraries nil '("-lc" "-ldd300h" "-lsb1" "-lsb2" "-lwindow")) You say that when linked and run from C, the graphics program works; could you show us the "cc ..." or "ld ..." line used to actually link the program? (For example, run make(1) if you're using it, and copy the exact "cc..." line make(1) produces.) Another suggestion: (load-foreign-libraries nil '("-ldd300h" "-lsb1" "-lsb2" "-lwindow" "-lc")) The C library loaded by "-lc" is the most fundamental library, and I believe it should always be loaded last. Craig James, Hewlett-Packard Laboratories, Palo Alto, California
knish@hpcllld.HP.COM (Doreen Kawanishi) (04/19/89)
Greetings. Please refer to the notesgroup "comp.lang.lisp" on yet another possible solution. HP Lisp Support Staff