Re: 'make depend' or 'make' bug on recent --current
On 6/1/16 12:58 PM, Andrey Chernov wrote: > On 01.06.2016 22:36, Bryan Drewery wrote: The graph in the original commit for WITH_FAST_DEPEND disagrees. https://svnweb.freebsd.org/base?view=revision=290433 We run the preprocessor once now, not twice. >>> >>> It sounds good, just implemented bad. You measure some spherical chicken >>> in vacuum, not what really happens. In the old times I almost never have >>> clang libs rebuild (few files from there max when FreeBSD_version is >>> increased), but now I got them fully rebuilt with any header change. >>> That is the biggest slowdown and not what you try to measure. >>> Don't ever use 'make world'. Try to rebuild the system incrementally and >>> you'll see. >> >> I cannot argue with a lack of solid evidence. >> >> The old 'make depend' ran 'mkdep' which ran 'cc -E -M' which produces >> *the same output* as 'cc foo.c -o foo.o -MD -MF .depend.foo.o -MT >> foo.o'. There's nothing different in the actual .depend file >> implementation/content. Clang rebuilds often because it is changing >> often! Just look at recent commit logs and you'll see r300984 which >> will cause a rebuild of clang. Or r301011 which modified >> sys/sys/param.h which will rebuild just about everything. These are >> normal and how the old system worked as well. >> >> There certainly are some issues with the new system. >> 1. Processing the split files can be slow over NFS >> 2. make cleandepend - will cause the next build to make a lot of guesses >> and not be very efficient. >> 3. make cleandepend - There is no way to generate the .depend* files >> again without rebuilding. >> 4. It doesn't fix all of the missing dependencies that have been missing >> forever such as crt, csu, libgcc, etc for static builds. >> 5. the csu builds don't use it yet but have workarounds for it >> 6. removing the 'make depend' tree-walk can hurt downstream builds which >> relied on having a multi-phase build to generate a .mk file to include >> (odd case I hit at work). No such case exists in the upstream FreeBSD tree. >> > > There are two different things: pure recursive dependency (it is how > make depends works now) and just nested include graph with dependencies > marked directly by Makefile's rules (it is how old system works). Now it > is enough to touch some low level include to rebuild everything, before > only files which include it directly or have make rules for it are rebuilt. No. The build and how dependencies are generated and handled is still fundamentally the same. Open the .depend.* files and see. It is only simple dependencies for the target built. There's nothing new about its content. If foo.c includes stdlib.h then it includes sys/_types.h which includes sys/cdefs.h, etc. This graph is in the old (mkdep) and new .depend* content. This is easily provable by just comparing mkdep output to the new versions. Without specific evidence of a bug I cannot help. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: 'make depend' or 'make' bug on recent --current
On 01.06.2016 22:36, Bryan Drewery wrote: >>> The graph in the original commit for WITH_FAST_DEPEND disagrees. >>> https://svnweb.freebsd.org/base?view=revision=290433 >>> >>> We run the preprocessor once now, not twice. >> >> It sounds good, just implemented bad. You measure some spherical chicken >> in vacuum, not what really happens. In the old times I almost never have >> clang libs rebuild (few files from there max when FreeBSD_version is >> increased), but now I got them fully rebuilt with any header change. >> That is the biggest slowdown and not what you try to measure. >> Don't ever use 'make world'. Try to rebuild the system incrementally and >> you'll see. > > I cannot argue with a lack of solid evidence. > > The old 'make depend' ran 'mkdep' which ran 'cc -E -M' which produces > *the same output* as 'cc foo.c -o foo.o -MD -MF .depend.foo.o -MT > foo.o'. There's nothing different in the actual .depend file > implementation/content. Clang rebuilds often because it is changing > often! Just look at recent commit logs and you'll see r300984 which > will cause a rebuild of clang. Or r301011 which modified > sys/sys/param.h which will rebuild just about everything. These are > normal and how the old system worked as well. > > There certainly are some issues with the new system. > 1. Processing the split files can be slow over NFS > 2. make cleandepend - will cause the next build to make a lot of guesses > and not be very efficient. > 3. make cleandepend - There is no way to generate the .depend* files > again without rebuilding. > 4. It doesn't fix all of the missing dependencies that have been missing > forever such as crt, csu, libgcc, etc for static builds. > 5. the csu builds don't use it yet but have workarounds for it > 6. removing the 'make depend' tree-walk can hurt downstream builds which > relied on having a multi-phase build to generate a .mk file to include > (odd case I hit at work). No such case exists in the upstream FreeBSD tree. > There are two different things: pure recursive dependency (it is how make depends works now) and just nested include graph with dependencies marked directly by Makefile's rules (it is how old system works). Now it is enough to touch some low level include to rebuild everything, before only files which include it directly or have make rules for it are rebuilt. signature.asc Description: OpenPGP digital signature
Re: amd64 11.0 -r301139 installworld (WITH_META_MODE=yes) fails for "Unable to determine compiler type"
On 6/1/16 12:35 PM, Mark Millard wrote:
> Context: amd64 building for amd64 starting from:
>
>> # uname -apKU
>> FreeBSD FreeBSDx64 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #29 r300944M: Sun May 29
>> 14:39:47 PDT 2016
>> markmi@FreeBSDx64:/usr/obj/clang/amd64.amd64/usr/src/sys/GENERIC-NODEBUG
>> amd64 amd64 1100114 1100114
>
>
> After a successful WITH_META_MODE=yes buildworld buildkernel sequence and
> then installkernel sequence: installworld then failed with . . .
>
>> #
>> ~/sys_build_scripts.amd64-host/make_amd64_nodebug_clang_bootstrap-amd64-host.sh
>> installworld
>> Script started, output file is
>> /root/sys_typescripts/typescript_make_amd64_nodebug_clang_bootstrap-amd64-host-2016-06-01:12:13:05
>> mkdir -p /tmp/install.JwZJ3f9P
>> progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp date echo
>> egrep find grep id install ln make mkdir mtree mv pwd_mkdb rm sed
>> services_mkdb sh strip sysctl test true uname wc zic tzsetup makewhatis;
>> do if progpath=`which $prog`; then echo $progpath; else echo "Required
>> tool $prog not found in PATH." >&2; exit 1; fi; done); libs=$(ldd -f "%o
>> %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do set
>> -- $line; if [ "$2 $3" != "not found" ]; then echo $2; else echo
>> "Required library $1 not found." >&2; exit 1; fi; done); cp $libs $progs
>> /tmp/install.JwZJ3f9P
>> cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.JwZJ3f9P/locale
>> cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/clang/amd64.amd64 MACHINE_ARCH=amd64
>> MACHINE=amd64 CPUTYPE=
>> GROFF_BIN_PATH=/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/bin
>> GROFF_FONT_PATH=/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/share/groff_font
>>
>> GROFF_TMAC_PATH=/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/share/tmac
>> CC="cc -target x86_64-unknown-freebsd11.0
>> --sysroot=/usr/obj/clang/amd64.amd64/usr/src/tmp
>> -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" CXX="c++ -target
>> x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/clang/amd64.amd64/usr/src/tmp
>> -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" CPP="cpp -target
>> x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/clang/amd64.amd64/usr/src/tmp
>> -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld"
>> NM=nm OBJDUMP=objdump OBJCOPY="objcopy" RANLIB=ranlib STRINGS=
>> SIZE="size"
>> PATH=/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/sbin:/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/bin:/usr/obj/clang/a
md64.amd64/usr/src/tmp/legacy/bin:/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/sbin:/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin:/tmp/install.JwZJ3f9P
LD_LIBRARY_PATH=/tmp/install.JwZJ3f9P
PATH_LOCALE=/tmp/install.JwZJ3f9P/locale make -f Makefile.inc1
__MAKE_SHELL=/tmp/install.JwZJ3f9P/sh reinstall;
MAKEOBJDIRPREFIX=/usr/obj/clang/amd64.amd64 MACHINE_ARCH=amd64 MACHINE=amd64
CPUTYPE= GROFF_BIN_PATH=/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/share/tmac
CC="cc -target x86_64-unknown-freebsd11.0
--sysroot=/usr/obj/clang/amd64.amd64/usr/src/tmp
-B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" CXX="c++ -target
x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/clang/amd64.amd64/usr/src/tmp
-B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" CPP="cpp -target
x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/clang/amd64.amd64/usr
/src/tmp -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" AS="as" AR="ar"
LD="ld" NM=nm OBJDUMP=objdump OBJCOPY="objcopy" RANLIB=ranlib STRINGS=
SIZE="size"
PATH=/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/sbin:/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/bin:/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/bin:/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/sbin:/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin:/tmp/install.JwZJ3f9P
LD_LIBRARY_PATH=/tmp/install.JwZJ3f9P
PATH_LOCALE=/tmp/install.JwZJ3f9P/locale rm -rf /tmp/install.JwZJ3f9P
>> sh: cc: not found
>> make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 142: Unable to determine
>> compiler type for CC=cc -target x86_64-unknown-freebsd11.0
>> --sysroot=/usr/obj/clang/amd64.amd64/usr/src/tmp
>> -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin. Consider setting
>> COMPILER_TYPE.
>> *** Error code 1
>>
The error is not related to WITH_META_MODE.
>> Stop.
>> make[1]: stopped in /usr/src
>> *** Error code 1
>>
>> Stop.
>> make: stopped in /usr/src
>>
>> Script done, output file is
>> /root/sys_typescripts/typescript_make_amd64_nodebug_clang_bootstrap-amd64-host-2016-06-01:12:13:05
>
> (I do not know if WITH_META_MODE=yes matters here or not. WITH_META_MODE=yes
> was supplied the the script that I used.)
>
> make.conf was:
>
> CFLAGS.gcc+= -v
>
> (so effectively empty for clang use).
>
> src.conf was:
>
> TO_TYPE=amd64
> #
>
Re: 'make depend' or 'make' bug on recent --current
On 6/1/16 11:49 AM, Andrey Chernov wrote: > On 01.06.2016 21:18, Bryan Drewery wrote: >> On 6/1/2016 6:11 AM, Andrey Chernov wrote: >>> Steps to reproduce: >>> >>> cd /usr/src/lib/libc/stdlib >>> touch *div*.c >>> cd .. >>> make depend >>> make >>> >>> And see how imaxdiv.o only is recompiled. >>> No div.o ldiv.o lldiv.o are recompiled. Because they never were compiled! lib/libc/stdlib/Makefile.inc MISRCS has div.c ldiv.c lldiv.c However, for at least amd64 it also includes: lib/libc/amd64/stdlib/Makefile.inc which has MDSRCS= div.S ldiv.S lldiv.S Note the .depend.lldiv.o file: > ~/git/freebsd/lib/libc/stdlib # cat > /usr/obj/root/git/freebsd/lib/libc/.depend.lldiv.o > lldiv.o: /root/git/freebsd/lib/libc/amd64/stdlib/lldiv.S \ > /usr/obj/root/git/freebsd/tmp/usr/include/machine/asm.h \ > /usr/obj/root/git/freebsd/tmp/usr/include/sys/cdefs.h It's built from lldiv.S, not lldiv.c. No bug here. proof: > cc -O2 -pipe -I/root/git/freebsd/lib/libc/include > -I/root/git/freebsd/lib/libc/../../include -I/root/git/freebsd/lib/libc/amd64 > -DNLS -D__DBINTERFACE_PRIVATE -I/root/git/freebsd/lib/libc/../../contrib/ > gdtoa -I/root/git/freebsd/lib/libc/../../contrib/libc-vis -DINET6 > -I/usr/obj/root/git/freebsd/lib/libc -I/root/git/freebsd/lib/libc/resolv > -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/root/git/freebsd/lib/libc/../li > bmd -I/root/git/freebsd/lib/libc/../../contrib/jemalloc/include > -DMALLOC_PRODUCTION -I/root/git/freebsd/lib/libc/../../contrib/tzcode/stdtime > -I/root/git/freebsd/lib/libc/stdtime -I/root/git/freebsd/lib/l > ibc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN > -I/root/git/freebsd/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -MD > -MF.depend.lldiv.o -MTlldiv.o -std=gnu99 -fstack-protector-strong > -Wsystem-heade > rs -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality > -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef > -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -fcolor-diagnostics > -Qunused-arguments -I/root/git/freebsd/lib/libutil -I/roo > t/git/freebsd/lib/msun/amd64 -I/root/git/freebsd/lib/msun/x86 > -I/root/git/freebsd/lib/msun/src -c > /root/git/freebsd/lib/libc/amd64/stdlib/lldiv.S -o lldiv.o > cc -fpic -DPIC -O2 -pipe -I/root/git/freebsd/lib/libc/include > -I/root/git/freebsd/lib/libc/../../include -I/root/git/freebsd/lib/libc/amd64 > -DNLS -D__DBINTERFACE_PRIVATE -I/root/git/freebsd/lib/libc/.. > /../contrib/gdtoa -I/root/git/freebsd/lib/libc/../../contrib/libc-vis -DINET6 > -I/usr/obj/root/git/freebsd/lib/libc -I/root/git/freebsd/lib/libc/resolv > -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/root/git/freebsd/li > b/libc/../libmd -I/root/git/freebsd/lib/libc/../../contrib/jemalloc/include > -DMALLOC_PRODUCTION -I/root/git/freebsd/lib/libc/../../contrib/tzcode/stdtime > -I/root/git/freebsd/lib/libc/stdtime -I/root/git/f > reebsd/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN > -I/root/git/freebsd/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -MD > -MF.depend.lldiv.So -MTlldiv.So -std=gnu99 -fstack-protector-strong > -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized > -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value > -Wno-parenth > eses-equality -Wno-unused-function -Wno-enum-conversion > -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum > -Wno-knr-promoted-parameter -fcolor-diagnostics -Qunused-arguments > -I/root/git/freebsd/lib/ > libutil -I/root/git/freebsd/lib/msun/amd64 -I/root/git/freebsd/lib/msun/x86 > -I/root/git/freebsd/lib/msun/src-c > /root/git/freebsd/lib/libc/amd64/stdlib/lldiv.S -o lldiv.So note lldiv.S in both. >> >> My dev system is busy at the moment. I'll test it and get back to you. > > I need to add that I do 'make cleandepend/cleandir/cleanobj' + 'make > obj' again and full rebuild with no old files, but the bug repeated again. > >>> P.S. new make depend is simple disgusting. It tends to recompile >>> everything in the system if some minor header file is touched, but >> >> If the header is used by all source files then that is expected. >> >> However if you do not have a .depend.obj.o file then it is quite >> aggressive with building. If you touch any header it will rebuild >> everything. But you shouldn't get into that situation unless you rm -f >> .depend* first. >> >>> completely forget to recompile source code changes. I suggest to back >>> out all AI in that area. >>> 'make depend' is not time-consuming task and good old way never made >>> mistakes. >> >> The graph in the original commit for WITH_FAST_DEPEND disagrees. >> https://svnweb.freebsd.org/base?view=revision=290433 >> >> We run the preprocessor once now, not twice. > > It sounds good, just implemented bad. You measure some spherical chicken > in
amd64 11.0 -r301139 installworld (WITH_META_MODE=yes) fails for "Unable to determine compiler type"
Context: amd64 building for amd64 starting from:
> # uname -apKU
> FreeBSD FreeBSDx64 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #29 r300944M: Sun May 29
> 14:39:47 PDT 2016
> markmi@FreeBSDx64:/usr/obj/clang/amd64.amd64/usr/src/sys/GENERIC-NODEBUG
> amd64 amd64 1100114 1100114
After a successful WITH_META_MODE=yes buildworld buildkernel sequence and then
installkernel sequence: installworld then failed with . . .
> #
> ~/sys_build_scripts.amd64-host/make_amd64_nodebug_clang_bootstrap-amd64-host.sh
> installworld
> Script started, output file is
> /root/sys_typescripts/typescript_make_amd64_nodebug_clang_bootstrap-amd64-host-2016-06-01:12:13:05
> mkdir -p /tmp/install.JwZJ3f9P
> progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp date echo
> egrep find grep id install ln make mkdir mtree mv pwd_mkdb rm sed
> services_mkdb sh strip sysctl test true uname wc zic tzsetup makewhatis; do
> if progpath=`which $prog`; then echo $progpath; else echo "Required tool
> $prog not found in PATH." >&2; exit 1; fi; done); libs=$(ldd -f "%o %p\n"
> -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do set --
> $line; if [ "$2 $3" != "not found" ]; then echo $2; else echo "Required
> library $1 not found." >&2; exit 1; fi; done); cp $libs $progs
> /tmp/install.JwZJ3f9P
> cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.JwZJ3f9P/locale
> cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/clang/amd64.amd64 MACHINE_ARCH=amd64
> MACHINE=amd64 CPUTYPE=
> GROFF_BIN_PATH=/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/bin
> GROFF_FONT_PATH=/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/share/groff_font
>
> GROFF_TMAC_PATH=/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/share/tmac
> CC="cc -target x86_64-unknown-freebsd11.0
> --sysroot=/usr/obj/clang/amd64.amd64/usr/src/tmp
> -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" CXX="c++ -target
> x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/clang/amd64.amd64/usr/src/tmp
> -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" CPP="cpp -target
> x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/clang/amd64.amd64/usr/src/tmp
> -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld"
> NM=nm OBJDUMP=objdump OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size"
> PATH=/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/sbin:/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/bin:/usr/obj/clang/am
d64.amd64/usr/src/tmp/legacy/bin:/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/sbin:/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin:/tmp/install.JwZJ3f9P
LD_LIBRARY_PATH=/tmp/install.JwZJ3f9P
PATH_LOCALE=/tmp/install.JwZJ3f9P/locale make -f Makefile.inc1
__MAKE_SHELL=/tmp/install.JwZJ3f9P/sh reinstall;
MAKEOBJDIRPREFIX=/usr/obj/clang/amd64.amd64 MACHINE_ARCH=amd64 MACHINE=amd64
CPUTYPE= GROFF_BIN_PATH=/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/share/tmac
CC="cc -target x86_64-unknown-freebsd11.0
--sysroot=/usr/obj/clang/amd64.amd64/usr/src/tmp
-B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" CXX="c++ -target
x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/clang/amd64.amd64/usr/src/tmp
-B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" CPP="cpp -target
x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/clang/amd64.amd64/usr/
src/tmp -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin" AS="as" AR="ar"
LD="ld" NM=nm OBJDUMP=objdump OBJCOPY="objcopy" RANLIB=ranlib STRINGS=
SIZE="size"
PATH=/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/sbin:/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/usr/bin:/usr/obj/clang/amd64.amd64/usr/src/tmp/legacy/bin:/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/sbin:/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin:/tmp/install.JwZJ3f9P
LD_LIBRARY_PATH=/tmp/install.JwZJ3f9P
PATH_LOCALE=/tmp/install.JwZJ3f9P/locale rm -rf /tmp/install.JwZJ3f9P
> sh: cc: not found
> make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 142: Unable to determine
> compiler type for CC=cc -target x86_64-unknown-freebsd11.0
> --sysroot=/usr/obj/clang/amd64.amd64/usr/src/tmp
> -B/usr/obj/clang/amd64.amd64/usr/src/tmp/usr/bin. Consider setting
> COMPILER_TYPE.
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make: stopped in /usr/src
>
> Script done, output file is
> /root/sys_typescripts/typescript_make_amd64_nodebug_clang_bootstrap-amd64-host-2016-06-01:12:13:05
(I do not know if WITH_META_MODE=yes matters here or not. WITH_META_MODE=yes
was supplied the the script that I used.)
make.conf was:
CFLAGS.gcc+= -v
(so effectively empty for clang use).
src.conf was:
TO_TYPE=amd64
#
KERNCONF=GENERIC-NODEBUG
TARGET=${TO_TYPE}
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITHOUT_CROSS_COMPILER=
WITH_SYSTEM_COMPILER=
#
WITH_LIBCPLUSPLUS=
Re: 'make depend' or 'make' bug on recent --current
On 01.06.2016 21:18, Bryan Drewery wrote: > On 6/1/2016 6:11 AM, Andrey Chernov wrote: >> Steps to reproduce: >> >> cd /usr/src/lib/libc/stdlib >> touch *div*.c >> cd .. >> make depend >> make >> >> And see how imaxdiv.o only is recompiled. >> No div.o ldiv.o lldiv.o are recompiled. > > My dev system is busy at the moment. I'll test it and get back to you. I need to add that I do 'make cleandepend/cleandir/cleanobj' + 'make obj' again and full rebuild with no old files, but the bug repeated again. >> P.S. new make depend is simple disgusting. It tends to recompile >> everything in the system if some minor header file is touched, but > > If the header is used by all source files then that is expected. > > However if you do not have a .depend.obj.o file then it is quite > aggressive with building. If you touch any header it will rebuild > everything. But you shouldn't get into that situation unless you rm -f > .depend* first. > >> completely forget to recompile source code changes. I suggest to back >> out all AI in that area. >> 'make depend' is not time-consuming task and good old way never made >> mistakes. > > The graph in the original commit for WITH_FAST_DEPEND disagrees. > https://svnweb.freebsd.org/base?view=revision=290433 > > We run the preprocessor once now, not twice. It sounds good, just implemented bad. You measure some spherical chicken in vacuum, not what really happens. In the old times I almost never have clang libs rebuild (few files from there max when FreeBSD_version is increased), but now I got them fully rebuilt with any header change. That is the biggest slowdown and not what you try to measure. Don't ever use 'make world'. Try to rebuild the system incrementally and you'll see. signature.asc Description: OpenPGP digital signature
Re: [PATCH] microoptimize locking primitives by avoiding unnecessary atomic ops
On Fri, May 27, 2016 at 04:21:11PM -0700, John Baldwin wrote: > On Friday, May 27, 2016 09:17:01 PM Mateusz Guzik wrote: > > Hello there, > > > > quite some time ago I posted a trivial patch to locking primitives. What > > they do is the inline part tries an atomic op and if that fails the > > actual function is called, which immediately tries the same op. > > > > The obvious optimisation checks for the availability of the lock first. > > > > There concerns about the way it was done previously by relying on > > volatile behaving in a specific way. > > > > Later a simplified version was posted which should not have the concern, > > but the thread died. > > > > I refer you to > > https://lists.freebsd.org/pipermail/freebsd-current/2015-November/058100.html > > for simple benchmark results. > > > > I would like to get the patch in before 11 freeze. > > I think this looks fine. Thanks for expanding the previous patch to cover > more primitives. > Thanks, committed in https://svnweb.freebsd.org/changeset/base/301157 -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 'make depend' or 'make' bug on recent --current
On 6/1/2016 6:11 AM, Andrey Chernov wrote: > Steps to reproduce: > > cd /usr/src/lib/libc/stdlib > touch *div*.c > cd .. > make depend > make > > And see how imaxdiv.o only is recompiled. > No div.o ldiv.o lldiv.o are recompiled. My dev system is busy at the moment. I'll test it and get back to you. > > P.S. new make depend is simple disgusting. It tends to recompile > everything in the system if some minor header file is touched, but If the header is used by all source files then that is expected. However if you do not have a .depend.obj.o file then it is quite aggressive with building. If you touch any header it will rebuild everything. But you shouldn't get into that situation unless you rm -f .depend* first. > completely forget to recompile source code changes. I suggest to back > out all AI in that area. > 'make depend' is not time-consuming task and good old way never made > mistakes. The graph in the original commit for WITH_FAST_DEPEND disagrees. https://svnweb.freebsd.org/base?view=revision=290433 We run the preprocessor once now, not twice. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: [CFT] WITH_META_MODE: Working incremental build
On 5/31/2016 5:17 PM, Simon J. Gerraty wrote:
>> Another reported issue just now is that right after an installworld,
>> everything rebuilds due to changed /bin/sh (-dM flag to make tells you
>> why things rebuild). I'll look into some mitigations for this.
>
> It is probably sufficient to just add
>
> .MAKE.META.IGNORE_PATHS += ${__MAKE_SHELL}
>
Yes but I need to test it fully to see if things like rtld and
libmap.conf, etc, get caught up in the problem too.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
head r30140 - Panic String: _mtx_lock_sleep: recursed on non-recursive mutex vm page @ /usr/src/sys/vm/vm_page.c:774
Since upgrading to head r301040 I have started to get the above panic while running poudriere while building packages for 10.3-STABLE r301107. Unfortuately I can't tell you the previous version of head but it was from some months ago. https://charon.gopai.com/core.txt.7 https://charon.gopai.com/info.7 I also have the full core file if needed. Let me know what else I can provide. Thank you. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Unable to load freshly-built nvidia.ko @r300994.
On Monday, May 30, 2016 11:52:27 AM David Wolfskill wrote:
> On Mon, May 30, 2016 at 07:03:42PM +0300, Konstantin Belousov wrote:
> > ...
> > > May 30 11:29:31 g1-252 root: /etc/rc: WARNING: Unable to load kernel
> > > module linux64
> > > May 30 11:29:31 g1-252 kernel: KLD linux64.ko: depends on kernel - not
> > > available or version mismatch
> > > May 30 11:29:31 g1-252 kernel: linker_load_file: Unsupported file type
> >
> > Your kernel was built from older sources than you used to build the nvidia
> > module. I mean, the kernel headers used for the module build where
> > updated comparing with binaries that are installed into /boot/kernel.
>
> Hmmm... I'm ... unlcear ... on how that could have happened.
>
> I've copied the typescript (from the build) to
> http://www.catwhisker.org/~david/FreeBSD/head/typescript_r300994; the
> "_bw" alias (ultimately) expands to:
>
> setenv TMPDIR /tmp && \
> id && \
> mount && \
> cd /usr/src && \
> uname -a && \
> date && \
> make -j16 buildworld && \
> date && \
> make -j16 buildkernel && \
> date && \
> rm -fr /boot/modules.old && \
> cp -pr /boot/modules{,.old} && \
> make installkernel && \
> date && \
> pushd /usr/ports && \
> pushd x11/nvidia-driver && \
> make clean ; popd ; popd && \
> date && \
> mergemaster -U -u 0022 -p && \
> date && \
> rm -fr /usr/include.old && \
> date && \
> mv /usr/include{,.old} && \
> date && \
> rm -fr /usr/share/man && \
> date && \
> make installworld && \
> date && \
> mergemaster -F -U -u 0022 -i && \
> date && \
> make delete-old && \
> date && \
> df -k
Just as a followup, this sequeunce will result in the nvidia-drier always
being stale. You have to build the nvidia-driver after installworld for
it to use up-to-date kernel headers (installkernel only installs the kernel
and modules, it does not update the headers in /usr/include).
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
kernel panic
Hi. I compile FreeBSD-CURRENT at 30 may and my server is not loading http://s33.postimg.org/5e1rk1lbz/20160531_123419.jpg Today, I fetch fresh sources and compile kernel again Server has loaded, but after some time I get kernel panic http://postimg.org/image/r78vxopkb/ http://postimg.org/image/7rtza7nu3/ http://postimg.org/image/adtblz97v/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] WITH_META_MODE: Working incremental build [only on i386 and amd64]
On 5/29/2016 3:53 PM, Mark Millard wrote:
> Quoting the original note about WITH_META_MODE (
> https://lists.freebsd.org/pipermail/freebsd-current/2016-May/061481.html ):
>
>> You will also need to load the filemon(4) module with 'kldload filemon'.
>
> But head's sys/modules/Makefile says:
>
>> .if defined(MODULES_OVERRIDE) && !defined(ALL_MODULES)
>> SUBDIR=${MODULES_OVERRIDE}
>> .else
>> SUBDIR= \
>
> . . .
>>${_filemon} \
>
> . . .
>> .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
> . . .
>> _filemon= filemon
> . . .
>
> as the only contexts that provide a filemon.ko to use with kldload.
>
> Thus, for example, arm variants (32 bit and 64 bit) and powerpc variants
> (32bit and 64 bit) do not have WITH_META_MODE as an option as things are set
> up.
>
> I had been hoping to cut down on the time for clang-related rebuilds during
> native buildworld runs on my slower buildworld contexts (armv7a/cortex-a7,
> powerpc, powerpc64). But it was not to be.
>
> It appears that, once some arm variants are officially tier 1, WITH_META_MODE
> will not span all tier 1 platforms.
>
> [Since I tend to use non-tier-1 platforms I tend to notice some of the
> statements about FreeBSD that are true of only tier 1 without being explicit
> about it. But initially it takes some research to discover that status for
> each such point. WITH_META_MODE is an example.]
>
I've just enabled the filemon(4) build on all architectures in r301130.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
'make depend' or 'make' bug on recent --current
Steps to reproduce: cd /usr/src/lib/libc/stdlib touch *div*.c cd .. make depend make And see how imaxdiv.o only is recompiled. No div.o ldiv.o lldiv.o are recompiled. P.S. new make depend is simple disgusting. It tends to recompile everything in the system if some minor header file is touched, but completely forget to recompile source code changes. I suggest to back out all AI in that area. 'make depend' is not time-consuming task and good old way never made mistakes. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 11.0 -r300944 build*KERNEL* via amd64-gcc fails for: .../dev/cxgb/ulp/tom/cxgb_listen.c:926:13: error: redundant redeclaration of 'tcp_dooptions'; cxgbe has an issue too
On 2016-Jun-1, at 12:36 AM, Navdeep Parhar wrote: > On Tue, May 31, 2016 at 10:49:29PM -0700, Mark Millard wrote: >> On 2016-May-31, at 10:31 PM, Mark Millard wrote: >> > >> >> If the offending declaration in cxgb_listen.c is commented out (or removed) >> there is a "next problem" but for cxgbe: >> >>> --- all_subdir_cxgbe/tom --- >>> /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c: In >>> function 'do_pass_accept_req': >>> /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:640:1: >>> warning: inlining failed in call to 'release_synqe': call is unlikely and >>> code size would grow [-Winline] > > Can you try removing the "inline" at line 639 in t4_listen.c and see if that > makes a difference? > > Regards, > Navdeep I tried commenting out the inline. Looks like cxgbe code has the same sort of redundant declaration problem as cxgb code: > --- t4_listen.o --- > /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:669:13: > error: redundant redeclaration of 'tcp_dooptions' [-Werror=redundant-decls] > extern void tcp_dooptions(struct tcpopt *, u_char *, int, int); > ^ > In file included from > /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:61:0: > /usr/src/sys/netinet/tcp_var.h:769:7: note: previous declaration of > 'tcp_dooptions' was here > void tcp_dooptions(struct tcpopt *, u_char *, int, int); >^ . . . > --- t4_listen.o --- > cc1: all warnings being treated as errors > *** [t4_listen.o] Error code 1 Commenting that out as well lead to a failure in a very different area of code: > --- all_subdir_drm2/i915kms --- > In file included from > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_drv.h:31:0, > from > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/dvo.h:35, > from > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/dvo_ch7xxx.c:32: > /usr/src/sys/dev/drm2/i915/i915_drv.h:1621:6: error: redundant redeclaration > of 'i915_gem_dump_object' [-Werror=redundant-decls] > void i915_gem_dump_object(struct drm_i915_gem_object *obj, int len, > ^ > /usr/src/sys/dev/drm2/i915/i915_drv.h:1612:6: note: previous declaration of > 'i915_gem_dump_object' was here > void i915_gem_dump_object(struct drm_i915_gem_object *obj, int len, > ^ > In file included from > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/dvo.h:35:0, > from > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/dvo_ch7xxx.c:32: > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_drv.h:671:13: > error: redundant redeclaration of 'intel_fbc_enabled' > [-Werror=redundant-decls] > extern bool intel_fbc_enabled(struct drm_device *dev); > ^ > In file included from > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_drv.h:31:0, > from > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/dvo.h:35, > from > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/dvo_ch7xxx.c:32: > /usr/src/sys/dev/drm2/i915/i915_drv.h:1676:13: note: previous declaration of > 'intel_fbc_enabled' was here > extern bool intel_fbc_enabled(struct drm_device *dev); > ^ . . . > --- all_subdir_drm2 --- > cc1: all warnings being treated as errors > *** [dvo_ch7xxx.o] Error code 1 === Mark Millard markmi at dsl-only.net ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 11.0 -r300944 build*KERNEL* via amd64-gcc fails for: .../dev/cxgb/ulp/tom/cxgb_listen.c:926:13: error: redundant redeclaration of 'tcp_dooptions'; cxgbe has an issue too
On Tue, May 31, 2016 at 10:49:29PM -0700, Mark Millard wrote: > On 2016-May-31, at 10:31 PM, Mark Millard wrote: > > > If the offending declaration in cxgb_listen.c is commented out (or removed) > there is a "next problem" but for cxgbe: > > > --- all_subdir_cxgbe/tom --- > > /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c: In > > function 'do_pass_accept_req': > > /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:640:1: > > warning: inlining failed in call to 'release_synqe': call is unlikely and > > code size would grow [-Winline] Can you try removing the "inline" at line 639 in t4_listen.c and see if that makes a difference? Regards, Navdeep ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 11.0 -r300944 build*KERNEL* via amd64-gcc fails for: .../dev/cxgb/ulp/tom/cxgb_listen.c:926:13: error: redundant redeclaration of 'tcp_dooptions'
[I'm too used to typing "buildworld": The subject line should have referenced
buildkernel and this resend does.]
On 2016-May-31, at 10:21 PM, Mark Millard wrote:
>
>> --- all_subdir_cxgb ---
>> /usr/src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_listen.c:926:13:
>> error: redundant redeclaration of 'tcp_dooptions' [-Werror=redundant-decls]
>> extern void tcp_dooptions(struct tcpopt *, u_char *, int, int);
>> ^
>> In file included from
>> /usr/src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_listen.c:49:0:
>> /usr/src/sys/netinet/tcp_var.h:769:7: note: previous declaration of
>> 'tcp_dooptions' was here
>> void tcp_dooptions(struct tcpopt *, u_char *, int, int);
>> ^
> . . .
> --- all_subdir_cxgb ---
>> cc1: all warnings being treated as errors
>> *** [cxgb_listen.o] Error code 1
>
>
> I got this while experimenting with WITH_META_MODE=yes for an external
> toolchain.
>
>
> src.conf details:
> (Yes it has some redundancies.)
>
> TO_TYPE=amd64
> TOOLS_TO_TYPE=x86_64
> VERSION_CONTEXT=11.0
> #
> KERNCONF=GENERIC-NODEBUG
> TARGET=${TO_TYPE}
> .if ${.MAKE.LEVEL} == 0
> TARGET_ARCH=${TO_TYPE}
> .export TARGET_ARCH
> .endif
> #
> WITHOUT_CROSS_COMPILER=
> WITHOUT_SYSTEM_COMPILER=
> #
> WITH_LIBCPLUSPLUS=
> WITHOUT_BINUTILS_BOOTSTRAP=
> WITHOUT_CLANG_BOOTSTRAP=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_CLANG_EXTRAS=
> WITH_LLDB=
> #PORTS_MODULES=emulators/virtualbox-ose-additions
> #
> #WITH_BOOT= for amd64-xtoolschain-gcc/amd64-gcc gets...
> # --- all_subdir_sys ---
> # -994 bytes available
> # *** [boot2] Error code 1
> WITHOUT_BOOT=
> WITH_LIB32=
> #
> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
> WITHOUT_GCC_BOOTSTRAP=
> WITHOUT_GCC=
> WITHOUT_GCC_IS_CC=
> WITHOUT_GNUCXX=
> #
> NO_WERROR=
> #WERROR=
> MALLOC_PRODUCTION=
> #
> WITH_DEBUG_FILES=
> #
> #
> # For TO (so-called "cross") stages . . .
> # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . .
> # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . .
> #
> CROSS_TOOLCHAIN=${TO_TYPE}-gcc
> X_COMPILER_TYPE=gcc
> CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
> .if ${.MAKE.LEVEL} == 0
> XCC=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gcc
> XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g++
> XCPP=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-cpp
> .export XCC
> .export XCXX
> .export XCPP
> XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
> XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
> XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
> XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
> XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
> XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
> XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
> XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
> #NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
> XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
> .export XAS
> .export XAR
> .export XLD
> .export XNM
> .export XOBJCOPY
> .export XOBJDUMP
> .export XRANLIB
> .export XSIZE
> .export XSTRINGS
> .endif
> #
> #
> # From based on clang (via system). . .
> #
> .if ${.MAKE.LEVEL} == 0
> CC=/usr/bin/clang
> CXX=/usr/bin/clang++
> CPP=/usr/bin/clang-cpp
> .export CC
> .export CXX
> .export CPP
> .endif
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 11.0 -r300944 build*KERNEL* via amd64-gcc fails for: .../dev/cxgb/ulp/tom/cxgb_listen.c:926:13: error: redundant redeclaration of 'tcp_dooptions'; cxgbe has an issue too
On 2016-May-31, at 10:31 PM, Mark Millard wrote:
> [I'm too used to typing "buildworld": The subject line should have referenced
> buildkernel and this resend does.]
>
> On 2016-May-31, at 10:21 PM, Mark Millard wrote:
>>
>>> --- all_subdir_cxgb ---
>>> /usr/src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_listen.c:926:13:
>>> error: redundant redeclaration of 'tcp_dooptions' [-Werror=redundant-decls]
>>> extern void tcp_dooptions(struct tcpopt *, u_char *, int, int);
>>>^
>>> In file included from
>>> /usr/src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_listen.c:49:0:
>>> /usr/src/sys/netinet/tcp_var.h:769:7: note: previous declaration of
>>> 'tcp_dooptions' was here
>>> void tcp_dooptions(struct tcpopt *, u_char *, int, int);
>>> ^
>> . . .
>> --- all_subdir_cxgb ---
>>> cc1: all warnings being treated as errors
>>> *** [cxgb_listen.o] Error code 1
>>
>>
>> I got this while experimenting with WITH_META_MODE=yes for an external
>> toolchain.
>>
>>
>> src.conf details:
>> (Yes it has some redundancies.)
>>
>> TO_TYPE=amd64
>> TOOLS_TO_TYPE=x86_64
>> VERSION_CONTEXT=11.0
>> #
>> KERNCONF=GENERIC-NODEBUG
>> TARGET=${TO_TYPE}
>> .if ${.MAKE.LEVEL} == 0
>> TARGET_ARCH=${TO_TYPE}
>> .export TARGET_ARCH
>> .endif
>> #
>> WITHOUT_CROSS_COMPILER=
>> WITHOUT_SYSTEM_COMPILER=
>> #
>> WITH_LIBCPLUSPLUS=
>> WITHOUT_BINUTILS_BOOTSTRAP=
>> WITHOUT_CLANG_BOOTSTRAP=
>> WITH_CLANG=
>> WITH_CLANG_IS_CC=
>> WITH_CLANG_FULL=
>> WITH_CLANG_EXTRAS=
>> WITH_LLDB=
>> #PORTS_MODULES=emulators/virtualbox-ose-additions
>> #
>> #WITH_BOOT= for amd64-xtoolschain-gcc/amd64-gcc gets...
>> # --- all_subdir_sys ---
>> # -994 bytes available
>> # *** [boot2] Error code 1
>> WITHOUT_BOOT=
>> WITH_LIB32=
>> #
>> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
>> WITHOUT_GCC_BOOTSTRAP=
>> WITHOUT_GCC=
>> WITHOUT_GCC_IS_CC=
>> WITHOUT_GNUCXX=
>> #
>> NO_WERROR=
>> #WERROR=
>> MALLOC_PRODUCTION=
>> #
>> WITH_DEBUG_FILES=
>> #
>> #
>> # For TO (so-called "cross") stages . . .
>> # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . .
>> # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . .
>> #
>> CROSS_TOOLCHAIN=${TO_TYPE}-gcc
>> X_COMPILER_TYPE=gcc
>> CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
>> .if ${.MAKE.LEVEL} == 0
>> XCC=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gcc
>> XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g++
>> XCPP=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-cpp
>> .export XCC
>> .export XCXX
>> .export XCPP
>> XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
>> XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
>> XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
>> XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
>> XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
>> XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
>> XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
>> XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
>> #NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
>> XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
>> .export XAS
>> .export XAR
>> .export XLD
>> .export XNM
>> .export XOBJCOPY
>> .export XOBJDUMP
>> .export XRANLIB
>> .export XSIZE
>> .export XSTRINGS
>> .endif
>> #
>> #
>> # From based on clang (via system). . .
>> #
>> .if ${.MAKE.LEVEL} == 0
>> CC=/usr/bin/clang
>> CXX=/usr/bin/clang++
>> CPP=/usr/bin/clang-cpp
>> .export CC
>> .export CXX
>> .export CPP
>> .endif
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
If the offending declaration in cxgb_listen.c is commented out (or removed)
there is a "next problem" but for cxgbe:
> --- all_subdir_cxgbe/tom ---
> /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c: In
> function 'do_pass_accept_req':
> /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:640:1:
> warning: inlining failed in call to 'release_synqe': call is unlikely and
> code size would grow [-Winline]
> release_synqe(struct synq_entry *synqe)
> ^
> /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:1406:3:
> warning: called from here [-Winline]
> release_synqe(synqe); /* extra hold */
> ^
> /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:640:1:
> warning: inlining failed in call to 'release_synqe': call is unlikely and
> code size would grow [-Winline]
> release_synqe(struct synq_entry *synqe)
> ^
> /usr/src/sys/modules/cxgbe/tom/../../../dev/cxgbe/tom/t4_listen.c:1411:2:
> warning: called from here [-Winline]
> release_synqe(synqe); /* extra hold */
> ^
. . .
> --- all_subdir_cxgbe/tom ---
> cc1: all warnings being treated as errors
> *** [t4_listen.o] Error code 1
It looks like this code area has not been tried under devel/amd64-gcc compiles.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209920 has the material for
these.
===
Mark Millard
markmi at dsl-only.net
11.0 -r300944 buildworld via amd64-gcc fails for: .../dev/cxgb/ulp/tom/cxgb_listen.c:926:13: error: redundant redeclaration of 'tcp_dooptions'
> --- all_subdir_cxgb ---
> /usr/src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_listen.c:926:13:
> error: redundant redeclaration of 'tcp_dooptions' [-Werror=redundant-decls]
> extern void tcp_dooptions(struct tcpopt *, u_char *, int, int);
> ^
> In file included from
> /usr/src/sys/modules/cxgb/tom/../../../dev/cxgb/ulp/tom/cxgb_listen.c:49:0:
> /usr/src/sys/netinet/tcp_var.h:769:7: note: previous declaration of
> 'tcp_dooptions' was here
> void tcp_dooptions(struct tcpopt *, u_char *, int, int);
>^
. . .
--- all_subdir_cxgb ---
> cc1: all warnings being treated as errors
> *** [cxgb_listen.o] Error code 1
I got this while experimenting with WITH_META_MODE=yes for an external
toolchain.
src.conf details:
(Yes it has some redundancies.)
TO_TYPE=amd64
TOOLS_TO_TYPE=x86_64
VERSION_CONTEXT=11.0
#
KERNCONF=GENERIC-NODEBUG
TARGET=${TO_TYPE}
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITHOUT_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
WITH_LIBCPLUSPLUS=
WITHOUT_BINUTILS_BOOTSTRAP=
WITHOUT_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLDB=
#PORTS_MODULES=emulators/virtualbox-ose-additions
#
#WITH_BOOT= for amd64-xtoolschain-gcc/amd64-gcc gets...
# --- all_subdir_sys ---
# -994 bytes available
# *** [boot2] Error code 1
WITHOUT_BOOT=
WITH_LIB32=
#
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_DEBUG_FILES=
#
#
# For TO (so-called "cross") stages . . .
# So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . .
# TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . .
#
CROSS_TOOLCHAIN=${TO_TYPE}-gcc
X_COMPILER_TYPE=gcc
CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
.if ${.MAKE.LEVEL} == 0
XCC=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gcc
XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g++
XCPP=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-cpp
.export XCC
.export XCXX
.export XCPP
XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
#NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
.export XAS
.export XAR
.export XLD
.export XNM
.export XOBJCOPY
.export XOBJDUMP
.export XRANLIB
.export XSIZE
.export XSTRINGS
.endif
#
#
# From based on clang (via system). . .
#
.if ${.MAKE.LEVEL} == 0
CC=/usr/bin/clang
CXX=/usr/bin/clang++
CPP=/usr/bin/clang-cpp
.export CC
.export CXX
.export CPP
.endif
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
