Date: Mon, 2 Mar 2009 02:45:28 -0800 From: Paige Thompson <erratic@devel.ws> To: freebsd-questions@freebsd.org Subject: Re: Kernel Compile issue Message-ID: <5061b39c0903020245u1fbd668bgb0022e3ec37cdfb6@mail.gmail.com> In-Reply-To: <5061b39c0903020243j64dd9739ua26277d639834d27@mail.gmail.com> References: <5061b39c0903020021t311f69c8va16b425e13f80eeb@mail.gmail.com> <5061b39c0903020026u7ad4d422w8f572f35bb27f9d1@mail.gmail.com> <gog805$qrh$1@ger.gmane.org> <5061b39c0903020128i63f81812ne7699dedb4e4b8a5@mail.gmail.com> <20090302104337.d06b2b63.freebsd@edvax.de> <5061b39c0903020159m44d36a19m60a5079f43564193@mail.gmail.com> <20090302112443.5a08f565.freebsd@edvax.de> <5061b39c0903020243j64dd9739ua26277d639834d27@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 2, 2009 at 2:43 AM, Paige Thompson <erratic@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@edvax.de> wrote: >> On Mon, 2 Mar 2009 01:59:43 -0800, Paige Thompson <erratic@devel.ws> wro= te: >>> 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: >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0# rm -r /usr/src >> =C2=A0 =C2=A0 =C2=A0 =C2=A0# 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=3DGENERIC 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 fi= nd: >>> >>> #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: >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0% locate cdefs.h >> =C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/include/sys/cdefs.h >> =C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/obj/usr/src/tmp/usr/include/sys/cdefs.h >> =C2=A0 =C2=A0 =C2=A0 =C2=A0/usr/src/sys/sys/cdefs.h >> =C2=A0 =C2=A0 =C2=A0 =C2=A0/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--td1705= 7087.html >>> (and from that please note:) >>> >>> > =C2=A0 GCC looks in several different places for headers. =C2=A0On a = normal Unix >>> > =C2=A0 system, if you do not instruct it otherwise, it will look for = headers >>> > =C2=A0 requested with `#include <FILE>' in: >>> > >>> > =C2=A0 =C2=A0 =C2=A0/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, >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0# cd /usr/src >> =C2=A0 =C2=A0 =C2=A0 =C2=A0# make buildkernel KERNCONF=3DGENERIC >> >> 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, ... >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5061b39c0903020245u1fbd668bgb0022e3ec37cdfb6>