Subject: Re: KLH10 Compile question and an answer!! Success!
To: Jason Thorpe <email@example.com>
From: bob smith <firstname.lastname@example.org>
Date: 05/10/2003 15:19:03
I had this itch to change the refs and make it something like you
describe but...I did not want to change the work that Ken did BUT I am
thrilled I have a clean compile, and am building the tops20 sys with TCP
as I type.
I have worked with FreeBSD - cause the Xwindows support seemed so easy,
might have been me. Debian - casue of the CCC capability, Redhat cause
it came with a couple of alphas I picked up and because of the SELinux
capabilities. but I seem to have this bent towards NetBSD. Just seems
natural to me. Considering that I jump from PC to Vax to Alpha as I
play with things, I like the transparance. Now, to have a version of
the 10 that runs cleanly on all three environments is great!!
I will tweak the sources with your suggestion and see what it does for me.
Jason Thorpe wrote:
> On Friday, May 9, 2003, at 03:04 PM, bob smith wrote:
>> # This auxiliary file is needed to get around a bug in the NetBSD
>> # /usr/include files. <stdio.h> includes <sys/types.h> which includes
>> # <machine/types.h> which incorrectly exposes a typedef of vaddr_t
>> # a kernel only type), thus conflicting with KLH10's vaddr_t.
>> # By including this file ahead of any other source files (see the
>> # in CENVFLAGS) we can nullify the typedef.
>> # And while we're at it, blast paddr_t for the same reason.
>> @echo '/* DO NOT EDIT - dynamically generated, see Makefile */' > $@
>> @echo "#define vaddr_t _kernel_vaddr_t" >> $@
>> @echo "#define paddr_t _kernel_paddr_t" >> $@
>> @echo "#include <sys/types.h>" >> $@
>> @echo "#undef paddr_t" >> $@
>> @echo "#undef vaddr_t" >> $@
> Nonsense. I seem to recall that identifiers that end in _t are reserved
> for the system in ISO C, and thus user applications that define them
> themselves are incorrect. I.e. it's KLH10 that is buggy for defining
> its own vaddr_t and paddr_t types. Instead, it should choose another
> name, like "klh10_vaddr" and "klh10_paddr".
> -- Jason R. Thorpe <email@example.com>