Date: Sun, 2 Mar 2008 16:22:30 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Alec Kloss <alec-keyword-freebsd.org.a6e2e4@SetFilePointer.com> Cc: Rasmus Kaj <kaj@kth.se>, Garance A Drosehn <gad@FreeBSD.org>, "Marc G. Fournier" <scrappy@hub.org>, afs@FreeBSD.org, Tomas Olsson <tol@stacken.kth.se>, arla-drinkers@stacken.kth.se Subject: Re: arla-devel port for FreeBSD (was: Patches to get Arla running on FreeBSD 8-CURRENT) Message-ID: <20080302161258.L21146@fledge.watson.org> In-Reply-To: <20080301210055.GA8919@hamlet.SetFilePointer.com> References: <1203286882.16414.3.camel@heterodyne.kaj> <20080218012608.V96329@fledge.watson.org> <20080222125207.GD38141@hamlet.setfilepointer.com> <20080223092516.O23969@fledge.watson.org> <20080223102922.GF38141@hamlet.setfilepointer.com> <20080223110549.GG38141@hamlet.setfilepointer.com> <20080223161249.GH38141@hamlet.setfilepointer.com> <90334B40754BEDC2991E0147@ganymede.hub.org> <p0624081bc3e936674ece@[128.113.24.47]> <20080226061140.GI28956@hamlet.SetFilePointer.com> <20080301210055.GA8919@hamlet.SetFilePointer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 1 Mar 2008, Alec Kloss wrote: > I've made a new arla-devel port snapped from Arla's CVS today. The only > patch is a relatively minor one applied to cf/bsd-header-vnode-if.h.m4 (and > therefore one for configure too). > > I've done rudamentary validation against 6.3, 7.0-PRERELEASE, and a -CURRENT > from last week. The port, arla-devel.tgz, and packages for 6.3, 7.x, and > 8.x are available here: > > http://setfilepointer.com/pub/afs/FreeBSD/ > > Testers, comments, criticisms welcome. Tomas, I'm happy to submit the devel > port based on a snapshot of arla to the FreeBSD project, but if you know > something about a "official" build of arla coming soon, I'd like to know > about it. Regardless, I'd like to submit something to the FreeBSD ports > tree by the middle of next week so we can have arla on FreeBSD more widely > distributed soon. > > Tomas, Robert, thanks so much for your help. I'm still having a few problems with the machine/ include issue. Your patch seems generally to help with the build portion of the show, but I noticed that the configure parts to detect uma.h now fail, due to uma.h depending in machine/ includes itself: checking for vm/vnode_pager.h... yes checking for vm/uma.h... no checking whether byte order is known at compile time... yes This would seem to occur because the machine symlink isn't set up in time for configure to use it: | #include <vm/vm_zone.h> configure:10682: result: no configure:10642: checking for vm/vnode_pager.h configure:10660: gcc -E -I. -D_KERNEL -DKLD_MODULE -fno-strict-aliasing -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 - mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fformat-extensions -I/usr/src/sys -nostdinc -I@ -I@/contrib/altq conftest.c configure:10666: $? = 0 configure:10682: result: yes configure:10642: checking for vm/uma.h configure:10660: gcc -E -I. -D_KERNEL -DKLD_MODULE -fno-strict-aliasing -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 - mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fformat-extensions -I/usr/src/sys -nostdinc -I@ -I@/contrib/altq conftest.c In file included from /usr/src/sys/sys/param.h:63, from /usr/src/sys/vm/uma.h:39, from conftest.c:103: /usr/src/sys/sys/types.h:44:28: error: machine/endian.h: No such file or directory In file included from /usr/src/sys/sys/types.h:45, from /usr/src/sys/sys/param.h:63, from /usr/src/sys/vm/uma.h:39, from conftest.c:103: /usr/src/sys/sys/_types.h:33:28: error: machine/_types.h: No such file or directory In file included from /usr/src/sys/vm/uma.h:39, from conftest.c:103: /usr/src/sys/sys/param.h:105:27: error: machine/param.h: No such file or directory configure:10666: $? = 1 configure: failed program was: | /* confdefs.h. */ That leads to config.h no longer knowing about uma.h: @@ -1395,7 +1395,7 @@ #define HAVE_VIS_H 1 /* Define to 1 if you have the <vm/uma.h> header file. */ -#define HAVE_VM_UMA_H 1 +/* #undef HAVE_VM_UMA_H */ /* Define to 1 if you have the <vm/vm_extern.h> header file. */ #define HAVE_VM_VM_EXTERN_H 1 In practice, things build anyway as some or another include must do a nested include of uma.h, but it still suggests the approach isn't quite right yet. How should we be setting up configure's kernel build environment? Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080302161258.L21146>