Re: arla-devel port for FreeBSD (was: Patches to get Arla running on FreeBSD 8-CURRENT)

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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-afs
To unsubscribe, send any mail to "[email protected]"