Kernel Compile issue

Paige Thompson erratic at devel.ws
Mon Mar 2 02:45:53 PST 2009


On Mon, Mar 2, 2009 at 2:44 AM, Paige Thompson <erratic at devel.ws> wrote:
> PS: it seems just straight up mget * works x.x
> k! satisfactory enough...
>
>
> 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, ...
>>>
>>
>


More information about the freebsd-questions mailing list