Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hpfcdc!cunniff
From: cunniff@hpfcdc.HP.COM (Ross Cunniff)
Newsgroups: comp.sys.hp
Subject: Re: HPUX 6.5 problems (long)
Message-ID: <5570159@hpfcdc.HP.COM>
Date: 21 Apr 89 16:06:17 GMT
References: <1725@Portia.Stanford.EDU>
Organization: HP Ft. Collins, Co.
Lines: 35

>   As far as the missing symbols are concerned, we get them when
>   compiling gnuemacs18.51 for X10.  The symbols "flag_68010" and
>   "flag_fpa" (and 2 or 3 others I can't remember) are not found.  The
>   only references to these symbols are in libc.a (not our applications)
>   so it must be a bug.  How could a system with undefined symbols get
>   released?  Doesn't HP do any integrity checking?

Don't blame HP.  Blame GNU, who supplies (for some unknown reason)
their own version of crt0.o, the C startup routine.  This is EXTREMELY
system-dependant stuff, and I think it's very inappropriate of them,
and I can't imagine any functionality they could put in crt0.o that
they couldn't put in main() itself (it's their own code, after all).

The symbols flag_68010, flag_68881, flag_fpa, float_loc, float_soft,
and fpa_loc are defined in /lib/crt0.o.  It is likely that this set
will change in future releases.  Link with it, you'll be happy.

>   Actually, flag_68010 was missing in 6.2 also, but we hacked in a 
>   dummy assembler file defining it to be the word 0xFFFFFFFF and 
>   got things to work.   Now that 4 symbols are missing in 6.5, I don't
>   think this sort of fix is appropriate.

No.  Use /lib/crt0.o.

> Erik Ruf
> Center for Integrated Systems
> Stanford University
> ruf@dolores.stanford.edu
> ...{decwrl,ucbvax}!dolores.stanford.edu!ruf
   

				Ross Cunniff
				Hewlett-Packard Colorado Languages Lab
				...{ucbvax,hplabs}!hpfcla!cunniff
				cunniff%hpfcrt@hplabs.HP.COM