Quick test building a module cross all targets and architectures
Ian Lepore
ian at freebsd.org
Tue Nov 3 15:30:06 UTC 2015
On Tue, 2015-11-03 at 13:24 +0100, Hans Petter Selasky wrote:
> On 10/27/15 17:16, Hans Petter Selasky wrote:
> > On 10/27/15 16:49, John Baldwin wrote:
> > > With MAKE_JUST_WORLDS you would only build
> > > a "generic" module once per architecture. That savings is likely
> > > far
> > > more
> > > than the cost of the additional tools.
> >
> > I will try it out. Thanks for your hints and tips.
> >
>
> Hi,
>
> Running:
>
> make buildworld TARGET=arm TARGET_ARCH=armv6 MAKE_JUST_WORLDS=yes
> SUBDIR_OVERRIDE=sys/modules MODULES_OVERRIDE=linuxkpi -DNO_CLEAN
>
> I get:
>
> > --------------------------------------------------------------
> > > > > stage 4.4: building everything
> > --------------------------------------------------------------
> > cd /usr/img/freebsd; MAKEOBJDIRPREFIX=/usr/obj/arm.armv6
> > MACHINE_ARCH=armv6 MACHINE=arm CPUTYPE=
> > GROFF_BIN_PATH=/usr/obj/arm.armv6/usr/img/freebsd/tmp/legacy/usr/bi
> > n
> > GROFF_FONT_PATH=/usr/obj/arm.armv6/usr/img/freebsd/tmp/legacy/usr/
> > share/groff_font
> > GROFF_TMAC_PATH=/usr/obj/arm.armv6/usr/img/freebsd/tmp/legacy/usr/
> > share/tmac _LDSCRIPTROOT= INSTALL="sh
> > /usr/img/freebsd/tools/install.sh"
> > PATH=/usr/obj/arm.armv6/usr/img/freebsd/tmp/legacy/usr/sbin:/usr/o
> > bj/arm.armv6/usr/img/freebsd/tmp/legacy/usr/bin:/usr/obj/arm.armv6/
> > usr/img/freebsd/tmp/legacy/bin:/usr/obj/arm.armv6/usr/img/freebsd/t
> > mp/usr/sbin:/usr/obj/arm.armv6/usr/img/freebsd/tmp/usr/bin:/sbin:/b
> > in:/usr/sbin:/usr/bin CC="cc " CXX="c++ " DEPFLAGS="" CPP="cpp "
> > AS="as" AR="ar" LD="ld" NM=nm OBJDUMP=objdump OBJCOPY="objcopy"
> > RANLIB=ranlib STRINGS= SIZE="size" make -f Makefile.inc1
> > DESTDIR=/usr/obj/arm.armv6/usr/img/freebsd/tmp par-all
> > ===> sys/modules (all)
> > ===> sys/modules/linuxkpi (all)
> > cc -O -pipe -mfloat-abi=softfp -Werror -D_KERNEL -DKLD_MODULE
> > -nostdinc
> > -I/usr/img/freebsd/sys/modules/linuxkpi/../../compat/linuxkpi/commo
> > n/include -I. -I/usr/img/freebsd/sys/modules/linuxkpi/../.. -fno
> > -common -funwind-tables -ffreestanding -fwrapv -Wall -Wredundant
> > -decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
> > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
> > -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs
> > -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error
> > -tautological-compare -Wno-error-empty-body -Wno-error-parentheses
> > -equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno
> > -error-shift-negative-value -mllvm -arm-use-movt=0 -mfpu=none
> > -std=iso9899:1999 -c
> > /usr/img/freebsd/sys/modules/linuxkpi/../../compat/linuxkpi/common/
> > src/linux_compat.c -o linux_compat.o
> > In file included from
> > /usr/img/freebsd/sys/modules/linuxkpi/../../compat/linuxkpi/common/
> > src/linux_compat.c:38:
> > In file included from
> > /usr/img/freebsd/sys/modules/linuxkpi/../../sys/proc.h:66:
> > In file included from
> > /usr/img/freebsd/sys/modules/linuxkpi/../../sys/_vm_domain.h:34:
> > In file included from
> > /usr/img/freebsd/sys/modules/linuxkpi/../../sys/seq.h:70:
> > ./machine/cpu.h:22:9: error: implicit declaration of function
> > 'cp15_pmccntr_get' is invalid in C99
> > [-Werror,-Wimplicit-function-declaration]
> > return cp15_pmccntr_get();
> > ^
> > 1 error generated.
> > *** Error code 1
>
> And when running:
>
> make -DNO_CLEAN -j6 universe MAKE_JUST_KERNELS=yes
> MODULES_OVERRIDE=linuxkpi
>
> With my "sys/conf/kern.post.mk" patch, it passes all the variants.
>
>
> Is this the expected behaviour or a bug somewhere?
>
>
> --HPS
The only way that error can happen is if _KERNEL is defined and
__ARM_ARCH is not >= 6 at that point in the compile. The __ARM_ARCH
symbol is set by the compiler and/or acle-compat.h (acle-compat
translates old gcc-style arm arch symbols to new-style).
Hmm, and looking at that output some more, we have CC="cc " CXX="c++ "
etc, so it's not using the cross-compiler and __ARM_ARCH will be zero.
Why it's using the wrong compiler is a question I'll leave for Warner
or someone else who understands module building better.
-- Ian
More information about the freebsd-current
mailing list