Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Jul 1995 23:20:20 -0700 (PDT)
From:      "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
To:        bde@zeta.org.au (Bruce Evans)
Cc:        freebsd-hackers@freebsd.org, root@debian.cps.cmich.edu, current@freebsd.org
Subject:   Re: Help me please.. :)
Message-ID:  <199507120620.XAA17246@gndrsh.aac.dev.com>
In-Reply-To: <199507120428.OAA09376@godzilla.zeta.org.au> from "Bruce Evans" at Jul 12, 95 02:28:46 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> >debian# make
> >cc -O2 -I/usr/src/sys/libkern -I/usr/src/sys/libkern/.. -DKERNEL -c 
> >adddi3.c -o adddi3.o
> >In file included from quad.h:57,
> >                 from adddi3.c:40:
> >/usr/src/sys/libkern/../sys/types.h:72: parse error before `off_t'
> >/usr/src/sys/libkern/../sys/types.h:72: warning: data definition has no 
> >type or storage class
> >/usr/src/sys/libkern/../sys/types.h:73: parse error before `pid_t'
> >/usr/src/sys/libkern/../sys/types.h:73: warning: data definition has no 
> >type or storage class
> >*** Error code 1
> 
> Your <machine/ansi.h> is out of date.
> 
> There are two bugs here:

There is one bug here.

> 
> 1) The include path is incorrect for compiling libkern.  <machine/ansi.h>
>     is /usr/include/machine/ansi.h for compiling libkern but it is usually
>     /usr/src/sys/i386/include/ansi.h for compiling the main part of the
>     kernel.

That is a bug.

> 
> 2) FreeBSD releases have /usr/include/machine populated with files.  It
>    should be a symlink to /sys/i386/include to avoid update problems.

This is not a bug, realize that without the src release installed if we
did this you could not use the system for compiling.  Bill did that
with 386BSD 0.1 and folks screamed about having to get part of the
src tree to be able to compile.  It was _fixed_ in FreeBSD 1.0 and
all later releases.

We need to ``enhance'' the installation of the src tree, that is where
the bug lies.  When a src tree is installed then and only then should
this symlink be made.  Infact right after a src install a
``cd /usr/src; make SHARED=symlinks includes'' would be the proper
thing to do.

I have in all of my /etc/make.conf files done just the opposite for
my own reasons (SHARED=copies) as I don't like my mucking around
in the /usr/src area to be any way visible to the running system,
if I want a change visible I run a make install.

The other real fix to this is to get on with the -no-std-includes that
has fallen into the deep deep cracks of time.

Your proposed symlink is just not really the right _fix_ for this bug :-(.

-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                 Reliable computers for FreeBSD



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507120620.XAA17246>