Kernel Compile issue

[Paige Thompson]

On Mon, Mar 2, 2009 at 2:43 AM, Paige Thompson <erratic at devel.ws> wrote:
> You're right, my source tree is incomplete:
>
> # pwd
> /usr/src/sys
> # cd sys
> sys: No such file or directory.
> #
>
> Thank you that helps a lot actually, it probably has something to do
> with the source archives that I downloaded not being extracted
> properly. I'm not a big fan of sysinstall, I prefer to work without
> it. You know the whole thing seems like its setup to try and force me
> to use sysinstall. Even the ftp client gives me a lot of flack about
> how I use mget (IE: mget ssys.* not being a valid way to just fetch
> all of the files) so of course i'm left to go through and fetch each
> of them individually :((
>
> and for whatever reason, Im not having any luck with ncftp which I'm
> sure I could figure it out but I really don't think that I should have
> to install an additional FTP client just so I can fetch the kernel
> source ._. it kind of negates the whole minimalist aspect of having
> multiple archive files in the first place.
>
> Am I right?
>
>
>
>
> On Mon, Mar 2, 2009 at 2:24 AM, Polytropon <freebsd at edvax.de> wrote:
>> On Mon, 2 Mar 2009 01:59:43 -0800, Paige Thompson <erratic at devel.ws> wrote:
>>> I have followed the manual, line for line or I wouldn't have gotten
>>> this far. I'm sorry but
>>>
>>> # cat /cdrom/src/ssys.[a-d]* | tar -xzvf -
>>> # cat /cdrom/src/sbase.[a-d]* | tar -xzvf -
>>>
>>> isn't typical archiving practice by today's standards (geez was it
>>> ever?)
>>
>> I'd thought that you've simply used sysinstall to install the
>> distribution "src-all", would be much easier. :-)
>>
>> Maybe you can try this again, but prior to this try, be sure to
>> eliminate everything that might be interfering:
>>
>>        # rm -r /usr/src
>>        # rm -r /usr/obj
>>
>>
>>
>>> As per your suggestion to check in the Makefile, I have found nothing
>>> that really eludes me as to why file cdefs.h actually does
>>> exist in /usr/include/sys yet the compiler does not see it probably
>>> because the compiler is not being given the correct include path or an
>>> include path at all for that matter.
>>
>> As I mentioned, I think the compile process first generates a
>> subtree in /usr/obk according to /usr/src and uses this for the
>> compile process. I'm not sure if the system files will then be
>> looked at...
>>
>>
>>> Reiteration:
>>>
>>> make buildkernel KERNCONF=GENERIC fails due to the following:
>>>
>>> # head error.log
>>> /usr/src/sys/i386/i386/genassym.c:35:23: error: sys/cdefs.h: No such
>>> file or directory
>>>
>>> when viewing the code /usr/src/sys/i386/i386/genassym.c on line 35 I find:
>>>
>>> #include <sys/cdefs.h>
>>>
>>> (please note the following carefully)
>>> Note that sys/cdefs.h is enclosed in <> as opposed to "" quotations.
>>> In C this indicates that the header should be included from an include
>>> path that's passed as an argument to the compiler-- *how ever and
>>> where ever that is done is what I would like to know.*
>>
>> Exactly. While "..." refers to $CWD, <...> refers to the -I parameter
>> of cc. This parameter is set by Makefile.
>>
>> Be sure that your sources are complete.
>>
>>
>>
>>> Now furthermore, /usr/local/include has *nothing* and I'm almost
>>> willing to bet you anything that if I copied * from /usr/include to
>>> /usr/local/include that would fix the issue except I don't think
>>> that's how this was intended to work.
>>
>> No. /usr/local does ONLY contain things that do not belong to the
>> operating system, such as things installed by ports or packages.
>>
>> We're talking about the operating system (and its kernel) itself,
>> so we're completely outside of /usr/local.
>>
>> In such a situation, cdefs.h can be found in different places:
>>
>>        % locate cdefs.h
>>        /usr/include/sys/cdefs.h
>>        /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h
>>        /usr/src/sys/sys/cdefs.h
>>        /usr/src/usr.sbin/lpr/common_source/lp.cdefs.h
>>
>> The first one is the system one's. The second one belongs to the
>> compiling process, generated by the sources. The third and forth
>> one ARE the sources for this.
>>
>>
>>
>>> Based on what I have read here:
>>>
>>> http://www.nabble.com/What-is-CPP%27s-real-default-include-path--td17057087.html
>>> (and from that please note:)
>>>
>>> >   GCC looks in several different places for headers.  On a normal Unix
>>> >   system, if you do not instruct it otherwise, it will look for headers
>>> >   requested with `#include <FILE>' in:
>>> >
>>> >      /usr/local/include
>>>
>>> I came across this thread by googling: "FreeBSD Include Path"
>>
>> As I said, that is a "Linux-ism". :-)
>>
>> For inclusion, first come the system's directories /usr/include, then
>> the local additions /usr/local/include. The last ones are not of
>> any value regarding the kernel and system compilation process.
>>
>>
>>
>> To be sure, ABSOLUTELY sure, use sysinstall to get the sources from
>> the CD, deleting any previous existence of them. Then,
>>
>>        # cd /usr/src
>>        # make buildkernel KERNCONF=GENERIC
>>
>> By the way, omitting KERNCONF loads GENERIC automatically.
>>
>> I think - and that's a quite wild guess - your problem is caused by
>> incomplete sources.
>>
>> A final question: Are you using the sources from the CD "as is"
>> (which release?) or do you update them (how?) before starting the
>> compilation process?
>>
>>
>>
>>
>> --
>> Polytropon
>> From Magdeburg, Germany
>> Happy FreeBSD user since 4.0
>> Andra moi ennepe, Mousa, ...
>>
>