Subject: [clisp-list] FW: Still Problems compiling on HP

From: Nuzzo Art-CINT116 <[email-masked]>
Date: Tue Apr 2 06:15:27 2002

Note: I am resending this. It looks like my mail server must have
dropped the ball on this one since
	it never made it to the mailing list.  Please disregard it if it
shows up at some point. - Art

> I am getting closer but not there yet.
> 
> 
> >> gcc -g -O2 -x none minitests.o -o minitests  ./.libs/libavcall.a
> >> ./minitests > minitests.out
> >> uniq -u < minitests.out > minitests.output.hppa2.0-hp-hpux10.20
> >> test '!' -s minitests.output.hppa2.0-hp-hpux10.20
> >> make: *** [check] Error 1
> >
> >this should be fixed in the CVS.
> 
> Getting the CVS fixed this problem.
> 
> 
> 
> 
> >> > cc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type
> >> > -fomit-frame-pointer -Wno-sign-compare -O2 -fno-strength-reduce
> >> > -DUNICODE -c arihppa.s || /usr/ccs/bin/as arihppa.s -o arihppa.o ||
> >> > /bin/as arihppa.s -o arihppa.o
> >> > arihppa.s: Assembler messages:
> >> > arihppa.s:1: Error: Unknown pseudo-op:  `.shortdata'
> >> > arihppa.s:8: Error: The .ENTER pseudo-op is not supported
> >> > arihppa.s:30: Error: The .LEAVE pseudo-op is not supported
> >> > arihppa.s: Assembler messages:
> >> > arihppa.s:1: Error: Unknown pseudo-op:  `.shortdata'
> >> > arihppa.s:8: Internal error, aborting at targ-cpu.c line 4493
> >> > Please report this bug.
> >
> >
> >
> >GNU as and the binutils will not help you. You need the assembler that
> >is shipped with the system!
> 
> 
> Switching to the HP assembler fixed this problem.
> 
> It now continues until it reaches the point where it runs lisp.run and
> then
> core dumps.
> 
> 
> gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type
> -fomit-frame-pointer -Wno-sign-compare -O2 -fno-strength-reduce -DUNICODE
> -DDYNAMIC_FFI -x none spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o
> control.o encoding.o pathname.o stream.o socket.o io.o array.o hashtabl.o
> list.o package.o record.o sequence.o charstrg.o debug.o error.o misc.o
> time.o predtype.o symbol.o lisparit.o i18n.o foreign.o unixaux.o arihppa.o
> gmalloc.o modules.o libsigsegv.a libintl.a libiconv.a libreadline.a
> libavcall.a libcallback.a  -ltermcap   -o lisp.run
> sync
> ./lisp.run -B . -N locale -Efile UTF-8 -norc -m 750KW -x "(load
> \"init.lisp\") (sys::%saveinitmem) (exit)"
> /bin/sh: 14998 Memory fault(coredump)
> make: *** [interpreted.mem] Error 139
> 
> 
> 
> Any ideas what I am overlooking?
> 
> Thanks for help,
> 
> 
> 
> Art Nuzzo
> 
> 
> [email-masked]
> 
>

---

From: Nuzzo Art-CINT116 <[email-masked]>
Date: Tue Apr 2 13:41:10 2002

> Please set the environment variable CC to "cc -g" or "gcc -g"
> respectively.
> You might probably also want to set an option that causes the compiler
> to issue more warning-messages ( -Wall for gcc,  -W (???) for cc))
> 
> Delete the build-directory and configure again, e.g.:
> ./configure compile-with-g
> 
> Make sure that a core file can be reproduced (ulimit and friends
> according to shell)
> (core-file-size of 0 might be counter-productive :-)
> 
> then follow the instructions printed out at the end of configuration.
> 
> The dump should occur again, now use the debugger (dbx, gdb) 
> to extract
> the
> stack trace.
> 
> (I don't know the specific command for dbx,
> in gdb you just have to load the core file into the debugger and issue
> the
> command "where" if I recall correctly.)
> 
> We might then have a chance to find, where the problem is.
> 
> 

It's unfortunate but it looks like I don't have a debugger on this system.
So before
I take that step let me ask this question:

I used to be able to compile Clisp on HP. This was some time ago and
probably a million things have changed, including the hardware, but I seem
to to remember something about the LANG variable or NLS_LANG variable being
an issue and I had to either set it or unset it to get it to compile. 

Does this ring a bell with anyone?

(It's too bad I don't have a Linux system here at work. I can compile Clisp,
and just about about any other program, on Linux at home without problems.)

Thanks for any information,

Art Nuzzo

---

From: Stefan Kain <[email-masked]>
Date: Tue Apr 2 14:15:17 2002

Hi,

> > Switching to the HP assembler fixed this problem.

Great!

The dump should occur again, now use the debugger (dbx, gdb) to extract
the
stack trace.

Bye,
Stefan