[ports-sparc64@bento.FreeBSD.org: libticables-3.7.7_2 failed on sparc64 5]

[Thomas Moestl]

On Tue, 2004/05/11 at 21:37:57 +0200, Tijl Coosemans wrote:
> On Mon, 10 May 2004 18:08:23 -0700, Kris Kennaway wrote:
> 
> > ----- Forwarded message from User Ports-sparc64
> > <ports-sparc64 at bento.FreeBSD.org> -----
> 
> Full build log at
> http://bento.freebsd.org/errorlogs/sparc64-5-latest/libticables-3.7.7_2.log
> 
> > In file included from ioports.c:45:
> > /usr/include/machine/sysarch.h:53: error: syntax error before
> > "utrap_entry_t"
> > /usr/include/machine/sysarch.h:64: error: syntax error before "type"
> > gmake[2]: *** [ioports.lo] Error 1
> > gmake[2]: Leaving directory
> > `/tmp/a/ports/comms/libticables/work/libticables-3.7.7/src'
> > gmake[1]: *** [all-recursive] Error 1
> > gmake[1]: Leaving directory
> > `/tmp/a/ports/comms/libticables/work/libticables-3.7.7'
> > gmake: *** [all] Error 2
> > *** Error code 2
> 
> Apparently src/sys/sparc64/include/sysarch.h uses
> utrap_entry_t and utrap_handler_t without defining them. They are
> however defined in src/sys/sparc64/utrap.h.
> 
> So I'm wondering, should I file a PR for my port to include
> machine/utrap.h(?) before machine/sysarch.h in case
> of a sparc64 build (or get rid of it since it is only used on i386),
> or is this a bug and should src/sys/sparc64/include/sysarch.h include
> machine/utrap.h (probably wrapped inside an #ifndef _KERNEL)?

Since machine/sysarch.h is by definition architecture dependent, it
would probably be best to include it only when it is needed (i.e. in
the i386 case).
Adding an ucontext.h include might be worth considering, but then
there seem to already be slightly different prerequisites on other
platforms.

	- Thomas

-- 
Thomas Moestl	<t.moestl at tu-bs.de>	http://www.tu-bs.de/~y0015675/
		<tmm at FreeBSD.org>	http://people.FreeBSD.org/~tmm/
"I realized that the purpose of writing is to inflate weak ideas,
 obscure poor reasoning, and inhibit clarity."	-- Calvin and Hobbes