Re: buildworld error
Am Sat, 24 Aug 2024 15:21:16 -0600 Warner Losh schrieb: > On Sat, Aug 24, 2024 at 1:39 PM Gordon Bergling wrote: > > > Hi Warner, > > > > On Sat, Aug 24, 2024 at 01:29:55PM -0600, Warner Losh wrote: > > > On Sat, Aug 24, 2024, 1:14 PM Gordon Bergling wrote: > > > > I got the following buildworld error a recent -CURRENT > > > > > > > > ===> stand/i386/pxeldr (all) > > > > `kldstat.o' is up to date. > > > > -14152 bytes available > > > > > > > > The same happens on stable/14: > > > > > > > > ===> stand/i386/pxeldr (all) > > > > -22344 bytes available > > > > ===> share/misc (all) > > > > --- loader --- > > > > *** [loader] Error code 1 > > > > > > > > make[5]: stopped in /storage/freebsd/src/stable/14/stand/i386/pxeldr > > > > 1 error > > > > > > > > src.conf looks like the following: > > > > WITH_BEARSSL=1 > > > > WITH_RETPOLINE=1 > > > > WITHOUT_CLEAN=1 > > > > > > > > I remove the whole obj directories and tried several full builds, but > > the > > > > error persists for a while. > > > > > > > > Has any one a clue how to solve this? > > > > > > Either disable pxe, raise the pxe limit (though it may not work), or > > select > > > the 4th loader for pxeboot. > > > > > > The loader is too big on BIOS to enable all the options. > > > > I looked at src.conf(5), but didn't found a switch to disable pxe. What I > > am > > wondering about is that no one is facing the problem, since this it is a > > pretty clean build without and special modifications, despite the ones > > mention > > above in the src.conf. > > > > Did you have a hint on how to disable pxe? > > > > I was sure that I'd documented everything, but it seems not: > > WITHOUT_LOADER_PXEBOOT=t > PXEBOOT_DEFAULT_INTERP=4th > PXEBOOTSIZE?=525000 > > I'll look to make sure I don't have a commit stuck in a branch somewhere > > Warner Just a note: src.conf(5) does not have (yet?) "PXEBOOTSIZE", instead, "LOADERSIZE" is mentioned, nor do I see PXEBOOT_DEFAULT_INTERP in the manpage. I think that would be worth being mentioned. Regards, Oliver -- O. Hartmann
Re: buildworld error
Am Sat, 24 Aug 2024 15:21:16 -0600 Warner Losh schrieb: > On Sat, Aug 24, 2024 at 1:39 PM Gordon Bergling wrote: > > > Hi Warner, > > > > On Sat, Aug 24, 2024 at 01:29:55PM -0600, Warner Losh wrote: > > > On Sat, Aug 24, 2024, 1:14 PM Gordon Bergling wrote: > > > > I got the following buildworld error a recent -CURRENT > > > > > > > > ===> stand/i386/pxeldr (all) > > > > `kldstat.o' is up to date. > > > > -14152 bytes available > > > > > > > > The same happens on stable/14: > > > > > > > > ===> stand/i386/pxeldr (all) > > > > -22344 bytes available > > > > ===> share/misc (all) > > > > --- loader --- > > > > *** [loader] Error code 1 > > > > > > > > make[5]: stopped in /storage/freebsd/src/stable/14/stand/i386/pxeldr > > > > 1 error > > > > > > > > src.conf looks like the following: > > > > WITH_BEARSSL=1 > > > > WITH_RETPOLINE=1 > > > > WITHOUT_CLEAN=1 > > > > > > > > I remove the whole obj directories and tried several full builds, but > > the > > > > error persists for a while. > > > > > > > > Has any one a clue how to solve this? > > > > > > Either disable pxe, raise the pxe limit (though it may not work), or > > select > > > the 4th loader for pxeboot. > > > > > > The loader is too big on BIOS to enable all the options. > > > > I looked at src.conf(5), but didn't found a switch to disable pxe. What I > > am > > wondering about is that no one is facing the problem, since this it is a > > pretty clean build without and special modifications, despite the ones > > mention > > above in the src.conf. > > > > Did you have a hint on how to disable pxe? > > > > I was sure that I'd documented everything, but it seems not: > > =t > PXEBOOT_DEFAULT_INTERP=4th > PXEBOOTSIZE?=525000 > > I'll look to make sure I don't have a commit stuck in a branch somewhere > > Warner After the introduction of WITHOUT_LOADER_PXEBOOT and setting this knob to true in /etc/src.conf has mitigated for me the problem reported above (it appears reproduceable when setting WITH_BEARSSL for me). But the problem mentione reappeared recently (a week or two on CURRENT, building on testboxes almost daily ...) again. Just for the record Kind regards, oh -- O. Hartmann
Re: buildworld error
Gordon Bergling writes: > But I wonder why I am the only person, who hits that problem since it > is a very plain -CURRENT build on a Hyper-V instance. You enabled BearSSL (and consequently Veriexec), that's pretty far from a plain build. The fact that you don't realize this leads me to suspect that you don't actually need them and would be better off disabling them than fiddling with PXE and Forth. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: buildworld error
On Sun, Aug 25, 2024 at 4:23 AM Gordon Bergling wrote: > Hi Warner, > > On Sat, Aug 24, 2024 at 03:21:16PM -0600, Warner Losh wrote: > > On Sat, Aug 24, 2024 at 1:39 PM Gordon Bergling wrote: > > > On Sat, Aug 24, 2024 at 01:29:55PM -0600, Warner Losh wrote: > > > > On Sat, Aug 24, 2024, 1:14 PM Gordon Bergling > wrote: > > > > > I got the following buildworld error a recent -CURRENT > > > > > > > > > > ===> stand/i386/pxeldr (all) > > > > > `kldstat.o' is up to date. > > > > > -14152 bytes available > > > > > > > > > > The same happens on stable/14: > > > > > > > > > > ===> stand/i386/pxeldr (all) > > > > > -22344 bytes available > > > > > ===> share/misc (all) > > > > > --- loader --- > > > > > *** [loader] Error code 1 > > > > > > > > > > make[5]: stopped in > /storage/freebsd/src/stable/14/stand/i386/pxeldr > > > > > 1 error > > > > > > > > > > src.conf looks like the following: > > > > > WITH_BEARSSL=1 > > > > > WITH_RETPOLINE=1 > > > > > WITHOUT_CLEAN=1 > > > > > > > > > > I remove the whole obj directories and tried several full builds, > but > > > the > > > > > error persists for a while. > > > > > > > > > > Has any one a clue how to solve this? > > > > > > > > Either disable pxe, raise the pxe limit (though it may not work), or > > > select > > > > the 4th loader for pxeboot. > > > > > > > > The loader is too big on BIOS to enable all the options. > > > > > > I looked at src.conf(5), but didn't found a switch to disable pxe. > What I > > > am > > > wondering about is that no one is facing the problem, since this it is > a > > > pretty clean build without and special modifications, despite the ones > > > mention > > > above in the src.conf. > > > > > > Did you have a hint on how to disable pxe? > > > > > > > I was sure that I'd documented everything, but it seems not: > > > > WITHOUT_LOADER_PXEBOOT=t > > PXEBOOT_DEFAULT_INTERP=4th > > PXEBOOTSIZE?=525000 > > > > I'll look to make sure I don't have a commit stuck in a branch > somewhere > > with this values in the src.conf(5) the build finally finished. But I > wonder > why I am the only person, who hits that problem since it is a very plain > -CURRENT build on a Hyper-V instance. > > Should these values be default values? > You've enabled some big ticket items. It's not at all clear what the default should be when people grow the loader too big. These options exist because PXEBOOT larger than about 500k is know to be flakey, though there's no universally known good upper limit since it depends a lot on the BIOS, what it does, etc. So upping that limit is off the table (though one can if one tests it and finds that works). Some other people don't use PXE at all, so for them, disabling it makes the most sense. Still others can't up the PXE limit high enough, and for them, using the 4th loader is a good path forward. The other option is for someone to go through /boot/loader and shaving some additional space. I've found all the easy, low-hanging fruit, plus turning off all the esoteric filesystems got us down to almost fitting. Warner
Re: buildworld error
Hi Warner, On Sat, Aug 24, 2024 at 03:21:16PM -0600, Warner Losh wrote: > On Sat, Aug 24, 2024 at 1:39 PM Gordon Bergling wrote: > > On Sat, Aug 24, 2024 at 01:29:55PM -0600, Warner Losh wrote: > > > On Sat, Aug 24, 2024, 1:14 PM Gordon Bergling wrote: > > > > I got the following buildworld error a recent -CURRENT > > > > > > > > ===> stand/i386/pxeldr (all) > > > > `kldstat.o' is up to date. > > > > -14152 bytes available > > > > > > > > The same happens on stable/14: > > > > > > > > ===> stand/i386/pxeldr (all) > > > > -22344 bytes available > > > > ===> share/misc (all) > > > > --- loader --- > > > > *** [loader] Error code 1 > > > > > > > > make[5]: stopped in /storage/freebsd/src/stable/14/stand/i386/pxeldr > > > > 1 error > > > > > > > > src.conf looks like the following: > > > > WITH_BEARSSL=1 > > > > WITH_RETPOLINE=1 > > > > WITHOUT_CLEAN=1 > > > > > > > > I remove the whole obj directories and tried several full builds, but > > the > > > > error persists for a while. > > > > > > > > Has any one a clue how to solve this? > > > > > > Either disable pxe, raise the pxe limit (though it may not work), or > > select > > > the 4th loader for pxeboot. > > > > > > The loader is too big on BIOS to enable all the options. > > > > I looked at src.conf(5), but didn't found a switch to disable pxe. What I > > am > > wondering about is that no one is facing the problem, since this it is a > > pretty clean build without and special modifications, despite the ones > > mention > > above in the src.conf. > > > > Did you have a hint on how to disable pxe? > > > > I was sure that I'd documented everything, but it seems not: > > WITHOUT_LOADER_PXEBOOT=t > PXEBOOT_DEFAULT_INTERP=4th > PXEBOOTSIZE?=525000 > > I'll look to make sure I don't have a commit stuck in a branch somewhere with this values in the src.conf(5) the build finally finished. But I wonder why I am the only person, who hits that problem since it is a very plain -CURRENT build on a Hyper-V instance. Should these values be default values? --Gordon signature.asc Description: PGP signature
Re: buildworld error
On Sat, Aug 24, 2024 at 1:39 PM Gordon Bergling wrote: > Hi Warner, > > On Sat, Aug 24, 2024 at 01:29:55PM -0600, Warner Losh wrote: > > On Sat, Aug 24, 2024, 1:14 PM Gordon Bergling wrote: > > > I got the following buildworld error a recent -CURRENT > > > > > > ===> stand/i386/pxeldr (all) > > > `kldstat.o' is up to date. > > > -14152 bytes available > > > > > > The same happens on stable/14: > > > > > > ===> stand/i386/pxeldr (all) > > > -22344 bytes available > > > ===> share/misc (all) > > > --- loader --- > > > *** [loader] Error code 1 > > > > > > make[5]: stopped in /storage/freebsd/src/stable/14/stand/i386/pxeldr > > > 1 error > > > > > > src.conf looks like the following: > > > WITH_BEARSSL=1 > > > WITH_RETPOLINE=1 > > > WITHOUT_CLEAN=1 > > > > > > I remove the whole obj directories and tried several full builds, but > the > > > error persists for a while. > > > > > > Has any one a clue how to solve this? > > > > Either disable pxe, raise the pxe limit (though it may not work), or > select > > the 4th loader for pxeboot. > > > > The loader is too big on BIOS to enable all the options. > > I looked at src.conf(5), but didn't found a switch to disable pxe. What I > am > wondering about is that no one is facing the problem, since this it is a > pretty clean build without and special modifications, despite the ones > mention > above in the src.conf. > > Did you have a hint on how to disable pxe? > I was sure that I'd documented everything, but it seems not: WITHOUT_LOADER_PXEBOOT=t PXEBOOT_DEFAULT_INTERP=4th PXEBOOTSIZE?=525000 I'll look to make sure I don't have a commit stuck in a branch somewhere Warner
Re: buildworld error
Hi Warner, On Sat, Aug 24, 2024 at 01:29:55PM -0600, Warner Losh wrote: > On Sat, Aug 24, 2024, 1:14 PM Gordon Bergling wrote: > > I got the following buildworld error a recent -CURRENT > > > > ===> stand/i386/pxeldr (all) > > `kldstat.o' is up to date. > > -14152 bytes available > > > > The same happens on stable/14: > > > > ===> stand/i386/pxeldr (all) > > -22344 bytes available > > ===> share/misc (all) > > --- loader --- > > *** [loader] Error code 1 > > > > make[5]: stopped in /storage/freebsd/src/stable/14/stand/i386/pxeldr > > 1 error > > > > src.conf looks like the following: > > WITH_BEARSSL=1 > > WITH_RETPOLINE=1 > > WITHOUT_CLEAN=1 > > > > I remove the whole obj directories and tried several full builds, but the > > error persists for a while. > > > > Has any one a clue how to solve this? > > Either disable pxe, raise the pxe limit (though it may not work), or select > the 4th loader for pxeboot. > > The loader is too big on BIOS to enable all the options. I looked at src.conf(5), but didn't found a switch to disable pxe. What I am wondering about is that no one is facing the problem, since this it is a pretty clean build without and special modifications, despite the ones mention above in the src.conf. Did you have a hint on how to disable pxe? --Gordon
Re: buildworld error
On Sat, Aug 24, 2024, 1:14 PM Gordon Bergling wrote: > Hi folks, > > I got the following buildworld error a recent -CURRENT > > ===> stand/i386/pxeldr (all) > `kldstat.o' is up to date. > -14152 bytes available > > The same happens on stable/14: > > ===> stand/i386/pxeldr (all) > -22344 bytes available > ===> share/misc (all) > --- loader --- > *** [loader] Error code 1 > > make[5]: stopped in /storage/freebsd/src/stable/14/stand/i386/pxeldr > 1 error > > src.conf looks like the following: > WITH_BEARSSL=1 > WITH_RETPOLINE=1 > WITHOUT_CLEAN=1 > > I remove the whole obj directories and tried several full builds, but the > error persists for a while. > > Has any one a clue how to solve this? Either disable pxe, raise the pxe limit (though it may not work), or select the 4th loader for pxeboot. The loader is too big on BIOS to enable all the options. Warner --Gordon >
Re: Buildworld stops for d3befb534b9 in tests
On Mon, Mar 04, 2024 at 09:54:14AM -0800, Mark Millard wrote: > bob prohaska wrote on > Date: Mon, 04 Mar 2024 16:35:52 UTC : > > > An armv7 (Pi2 v1.1) -current system stopped buildworld with > > > > c++: error: linker command failed with exit code 1 (use -v to see > > invocation) > > *** [capsicum-test.full] Error code 1 > > There might have been more error messages at some earlier point prior to > the above. Such likely would have more detail about what the issue was. > You're right, I missed the start. Here it is: Building /usr/obj/usr/src/arm.armv7/tests/sys/capsicum/capsicum-test.full cc -target armv7-gnueabihf-freebsd15.0 --sysroot=/usr/obj/usr/src/arm.armv7/tmp -B/usr/obj/usr/src/arm.armv7/tmp/usr/bin -O2 -pipe -fno-common -I/usr/src/lib/libarchive/tests -I/usr/src/lib/libarchive -I/usr/obj/usr/src/arm.armv7/lib/libarchive/tests -I/usr/src/contrib/libarchive/libarchive -I/usr/src/contrib/libarchive/libarchive/test -I/usr/src/contrib/libarchive/test_utils -DHAVE_BZLIB_H=1 -DHAVE_LIBLZMA=1 -DHAVE_LZMA_H=1 -DHAVE_ZSTD_H=1 -DHAVE_LIBZSTD=1 -DHAVE_LIBZSTD_COMPRESSOR=1 -DPLATFORM_CONFIG_H=\"/usr/src/lib/libarchive/tests/config_freebsd.h\" -DWITH_OPENSSL -DOPENSSL_API_COMPAT=0x1010L -g -gz=zlib -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Qunused-arguments -c /usr/src/contrib/libarchive/libarchive/test/test_archive_pathmatch.c -o test_archive_pathmatch.o ld: error: undefined symbol: testing::internal::CmpHelperGE(char const*, char const*, long long, long long) >>> referenced by procdesc.cc:199 >>> (/usr/src/contrib/capsicum-test/procdesc.cc:199) >>> procdesc.o:(Pdfork_TimeCheck_Test::TestBody()) ld: error: undefined symbol: testing::internal::CmpHelperEQ(char const*, char const*, long long, long long) >>> referenced by gtest.h:1502 >>> (/usr/obj/usr/src/arm.armv7/tmp/usr/include/private/gtest/gtest.h:1502) >>> procdesc.o:(Pdfork_TimeCheck_Test::TestBody()) >>> referenced by gtest.h:1502 >>> (/usr/obj/usr/src/arm.armv7/tmp/usr/include/private/gtest/gtest.h:1502) >>> procdesc.o:(Pdfork_TimeCheck_Test::TestBody()) >>> referenced by gtest.h:1502 >>> (/usr/obj/usr/src/arm.armv7/tmp/usr/include/private/gtest/gtest.h:1502) >>> procdesc.o:(Pdfork_TimeCheck_Test::TestBody()) __cxa_thread_call_dtors: dtr 0x6ce470 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0x6309c4 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0x6ce470 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0x64b138 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0x6309c4 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0x6309c4 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0x6ce470 from unloaded dso, skipping __cxa_thread_call_dtors: dtr 0x64b138 from unloaded dso, skipping Building /usr/obj/usr/src/arm.armv7/usr.bin/mandoc/mdoc_markdown.o Thanks for reading, and apologies for the omission! bob prohaska
Re: Buildworld stops for d3befb534b9 in tests
bob prohaska wrote on Date: Mon, 04 Mar 2024 16:35:52 UTC : > An armv7 (Pi2 v1.1) -current system stopped buildworld with > > c++: error: linker command failed with exit code 1 (use -v to see invocation) > *** [capsicum-test.full] Error code 1 There might have been more error messages at some earlier point prior to the above. Such likely would have more detail about what the issue was. > make[6]: stopped in /usr/src/tests/sys/capsicum > .ERROR_TARGET='capsicum-test.full' > ERROR_META_FILE='/usr/obj/usr/src/arm.armv7/tests/sys/capsicum/capsicum-test.full.meta' > .MAKE.LEVEL='6' > MAKEFILE='' > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' > _ERROR_CMD='c++ -target armv7-gnueabihf-freebsd15.0 > --sysroot=/usr/obj/usr/src/arm.armv7/tmp > -B/usr/obj/usr/src/arm.armv7/tmp/usr/bin -O2 -pipe -fno-common > -I/usr/src/tests -g -gz=zlib -Wno-format-zero-length -fstack-protector-strong > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wpointer-arith -Wno-uninitialized -Wdate-time -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable > -Wno-error=unused-but-set-parameter -Wno-tautological-compare > -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function > -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member > -Qunused-arguments -I/usr/obj/usr/src/arm.armv7/tmp/usr/include/private > -DGTEST_HAS_POSIX_RE=1 -DGTEST_HAS_PTHREAD=1 -DGTEST_HAS_STREAM_REDIRECTION=1 > -frtti -std=c++14 -Wno-c++11-extensions -Wl,-zrelro -o capsicum-test.full > capsicum-test-main.o capsicum-test.o capability-fd.o copy_file_range.o > fexecve.o procdesc.o capmode.o fcntl.o ioctl.o openat.o sysctl.o select.o > mqueue.o socket.o sctp.o capability-fd-pair.o overhead.o rename.o > -lprivategtest -lprocstat -lpthread;' > .CURDIR='/usr/src/tests/sys/capsicum' > .MAKE='make' > .OBJDIR='/usr/obj/usr/src/arm.armv7/tests/sys/capsicum' > .TARGETS=' all' > CPUTYPE='' > DESTDIR='/usr/obj/usr/src/arm.armv7/tmp' > LD_LIBRARY_PATH='' > MACHINE='arm' > MACHINE_ARCH='armv7' > MACHINE_CPUARCH='arm' > MAKEOBJDIRPREFIX='' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20220726' > PATH='/usr/obj/usr/src/arm.armv7/tmp/bin:/usr/obj/usr/src/arm.armv7/tmp/usr/sbin:/usr/obj/usr/src/arm.armv7/tmp/usr/bin:/usr/obj/usr/src/arm.armv7/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm.armv7/tmp/legacy/usr/bin:/usr/obj/usr/src/arm.armv7/tmp/legacy/bin:/usr/obj/usr/src/arm.armv7/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP='/usr/src' > OBJTOP='/usr/obj/usr/src/arm.armv7' > .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk > /usr/src/share/mk/src.sys.env.mk /usr/src/share/mk/bsd.mkopt.mk > /usr/src/share/mk/src.sys.obj.mk /usr/src/share/mk/local.sys.machine.mk > /usr/src/share/mk/meta.sys.mk /usr/src/share/mk/local.meta.sys.env.mk > /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk > /etc/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk > /etc/src.conf /usr/src/tests/sys/capsicum/Makefile > /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk > /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk > /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.endian.mk > /usr/src/share/mk/bsd.linker.mk /usr/src/share/mk/bsd.test.mk > /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk > /usr/src/share/mk/src.init.mk /usr/src/tests/sys/capsicum/../Makefile.inc > /usr/src/tests/Makefile.inc0 /usr/src/share/mk/googletest.test.mk > /usr/src/share/mk/googletest.test.inc.mk /usr/src/share/mk/plain.test.mk > /usr/src/share/mk/tap.test.mk > make[2]: stopped in /usr/src === Mark Millard marklmi at yahoo.com
Re: buildworld broken due to INET6 not being set
On Tue, 4 Jul 2023 16:48:10 + Gary Jennejohn wrote: > buildworld breaks because I do not have INET6 defined: > > /usr/src/sbin/ping/main.c:76:7: error: variable 'ipv4' set but not used > [-Werror,-Wunused-but-set-variable] > bool ipv4 = false; > ^ > 1 error generated. > I bit the bullet and enabled INET6, so there won't be any more reports like this from me in the future. -- Gary Jennejohn
Re: Buildworld failure at main-n261978-44312c28fe2d in /usr/src/usr.sbin/bhyve
Resolved by 76fa62b5232e67ef10476cf1329aaceb9cbc2ff5; ref. https://cgit.freebsd.org/src/commit/?id=76fa62b5232e67ef10476cf1329aaceb9cbc2ff5 Peace, david -- David H. Wolfskill da...@catwhisker.org Putin claimed he wanted to avoid expansion of NATO. See how well THAT worked. See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: buildworld failure
On Sat, 18 Feb 2023 13:28:58 -0800 (PST), "Jeffrey Bouquet" wrote: > > > On Sat, 18 Feb 2023 00:33:11 -0800 (PST), "Jeffrey Bouquet" > wrote: > > > Building > > /usr/obj/usr/src/amd64.amd64/tools/build/test-includes/sys_bitcount.c > > Building > > /usr/obj/usr/src/amd64.amd64/tools/build/test-includes/sys_bitcount.o > > sys_bitcount.c:1:10: fatal error: 'sys/bitcount.h' file not found > > #include > > ^~~~ > > 1 error generated. > > *** Error code 1 > > > > Stop. > > make[3]: stopped in /usr/src/tools/build/test-includes > > .ERROR_TARGET='sys_bitcount.o' > > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/tools/build/test-includes/sys_bitcount.o.meta' > > .MAKE.LEVEL='3' > > MAKEFILE='' > > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' > > _ERROR_CMD='/usr/local/bin/clang14 -O2 -pipe -fno-common -g -gz=zlib > > -std=gnu99 -Wno-format-zero-length -nobuiltininc -idirafter > > /usr/local/llvm14/lib/clang/14.0.6/include -fstack-protector-strong > > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > > -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition > > -Wno-pointer-sign -Wdate-time -Wmissing-variable-declarations > > -Wthread-safety -Wno-empty-body -Wno-string-plus-int > > -Wno-unused-const-variable -Wno-error=unused-but-set-variable > > -Qunused-arguments-c sys_bitcount.c -o sys_bitcount.o; ;' > > .CURDIR='/usr/src/tools/build/test-includes' > > .MAKE='make' > > .OBJDIR='/usr/obj/usr/src/amd64.amd64/tools/build/test-includes' > > .TARGETS='test-includes' > > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > > LD_LIBRARY_PATH='' > > MACHINE='amd64' > > MACHINE_ARCH='amd64' > > MAKEOBJDIRPREFIX='' > > MAKESYSPATH='/usr/src/share/mk' > > MAKE_VERSION='20220208' > > PATH='/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin' > > SRCTOP='/usr/src' > > OBJTOP='/usr/obj/usr/src/amd64.amd64 > > . > > > > Anyone see/know anything causing this error? > > Also, the buildworld command most likely to build the most amd64 components > > from scratch? > > > seems "make hier" fixed it partially > then WITHOUT_OFED=yes in src.conf. maybe fixed, maybe not. Not fixed. question 1. While building, it fails in some subtree. I change to that location and "make" which succeeds back in buildworld, stage 4.4, it then fails at the same place despite the "make" success. also, it re attempts to build in places I've WITHOUT_ in src.conf BOTH situations appear concurrently during the build, which halts, confusing me as to which condition causes the failure. Any workaround or fix? Seems the system is a hybrid of CURRENT and of 13-stable now, running without issues otherwise. leading to question 2. Ideally, I could overcome the buildworld failure by sequentially installing all parts of the buildworld which have SO FAR not failed? and where would I find the sequence of locations from which to do a "make" "make install" mimicing an installworld DURING buildworld, as if each part of buildworld after success coud be installed, leading to a greater probability that the entire buildworld could finish without error and to the likelihood also that an installworld would not fail due to most of its parts already having been completed. ... might as well put this question in also. ... 3... there is pending a UFS2 packagebase somewhere still in code review or beta? How might I use that to overcome this issue and install CURRENT if packagesets were available? thanks in advance. Jeff
Re: buildworld failure
On Sat, 18 Feb 2023 00:33:11 -0800 (PST), "Jeffrey Bouquet" wrote: > Building /usr/obj/usr/src/amd64.amd64/tools/build/test-includes/sys_bitcount.c > Building /usr/obj/usr/src/amd64.amd64/tools/build/test-includes/sys_bitcount.o > sys_bitcount.c:1:10: fatal error: 'sys/bitcount.h' file not found > #include > ^~~~ > 1 error generated. > *** Error code 1 > > Stop. > make[3]: stopped in /usr/src/tools/build/test-includes > .ERROR_TARGET='sys_bitcount.o' > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/tools/build/test-includes/sys_bitcount.o.meta' > .MAKE.LEVEL='3' > MAKEFILE='' > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' > _ERROR_CMD='/usr/local/bin/clang14 -O2 -pipe -fno-common -g -gz=zlib > -std=gnu99 -Wno-format-zero-length -nobuiltininc -idirafter > /usr/local/llvm14/lib/clang/14.0.6/include -fstack-protector-strong > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign > -Wdate-time -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable > -Wno-error=unused-but-set-variable -Qunused-arguments-c sys_bitcount.c > -o sys_bitcount.o; ;' > .CURDIR='/usr/src/tools/build/test-includes' > .MAKE='make' > .OBJDIR='/usr/obj/usr/src/amd64.amd64/tools/build/test-includes' > .TARGETS='test-includes' > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > LD_LIBRARY_PATH='' > MACHINE='amd64' > MACHINE_ARCH='amd64' > MAKEOBJDIRPREFIX='' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20220208' > PATH='/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP='/usr/src' > OBJTOP='/usr/obj/usr/src/amd64.amd64 > . > > Anyone see/know anything causing this error? > Also, the buildworld command most likely to build the most amd64 components > from scratch? seems "make hier" fixed it partially then WITHOUT_OFED=yes in src.conf. maybe fixed, maybe not.
Re: buildworld failure
On Sat, Feb 18, 2023 at 12:33:11AM -0800, Jeffrey Bouquet wrote: > Building /usr/obj/usr/src/amd64.amd64/tools/build/test-includes/sys_bitcount.c > Building /usr/obj/usr/src/amd64.amd64/tools/build/test-includes/sys_bitcount.o > sys_bitcount.c:1:10: fatal error: 'sys/bitcount.h' file not found > #include > ^~~~ > 1 error generated. > *** Error code 1 > > Stop. > make[3]: stopped in /usr/src/tools/build/test-includes > .ERROR_TARGET='sys_bitcount.o' > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/tools/build/test-includes/sys_bitcount.o.meta' > .MAKE.LEVEL='3' > MAKEFILE='' > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' > _ERROR_CMD='/usr/local/bin/clang14 -O2 -pipe -fno-common -g -gz=zlib > -std=gnu99 -Wno-format-zero-length -nobuiltininc -idirafter > /usr/local/llvm14/lib/clang/14.0.6/include -fstack-protector-strong > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign > -Wdate-time -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable > -Wno-error=unused-but-set-variable -Qunused-arguments-c sys_bitcount.c > -o sys_bitcount.o; ;' > .CURDIR='/usr/src/tools/build/test-includes' > .MAKE='make' > .OBJDIR='/usr/obj/usr/src/amd64.amd64/tools/build/test-includes' > .TARGETS='test-includes' > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > LD_LIBRARY_PATH='' > MACHINE='amd64' > MACHINE_ARCH='amd64' > MAKEOBJDIRPREFIX='' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20220208' > PATH='/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP='/usr/src' > OBJTOP='/usr/obj/usr/src/amd64.amd64 > . > > Anyone see/know anything causing this error? > Also, the buildworld command most likely to build the most amd64 components > from scratch? I'm seeing a different buildworld problem. ===> usr.bin/nm (obj,all,install) cc -O2 -pipe -fno-common -I/usr/src/contrib/elftoolchain/libelftc -I/usr/src/contrib/elftoolchain/common -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wdate-time -Wmissing-variable-declarations -Wthrea d-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -Wl,-zrelro -static -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib -o nm nm.o -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf -ldwarf -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf -L/usr /obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz -lz -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc -lelftc_pie -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf -legacy PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace. Stack dump: 0. Program arguments: /usr/bin/ld --eh-frame-hdr -Bstatic -o nm /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbeginT.o -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -L/usr/lib -zrelro nm.o -ldwarf -lelf -lz -lelftc_pie -lelf -legacy -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/crtend.o /usr/lib/crtn.o #0 0x0164f1c1 (/usr/bin/ld+0x164f1c1) #1 0x0164d4a5 (/usr/bin/ld+0x164d4a5) #2 0x0164f8e0 (/usr/bin/ld+0x164f8e0) #3 0x000827446a60 (/lib/libthr.so.3+0x19a60) #4 0x00082744601f (/lib/libthr.so.3+0x1901f) #5 0x00082362e8a3 ([vdso]+0x2d3)
Re: buildworld failed after deleting /usr/obj
- Original Message ---
On Sunday, January 29th, 2023 at 3:06 PM, qroxana
wrote:
> It appears buildworld doesn't create the obj directory for
> usr.bin/clang/llvm-objcopy in stage 2.2 after this commit.
>
> commit adc3c128c6603054586a993d117e5dd808deac17
> Author: John Baldwin j...@freebsd.org
>
> AuthorDate: Fri Nov 18 20:12:28 2022 -0800
> Commit: John Baldwin j...@freebsd.org
>
> CommitDate: Fri Nov 18 20:12:28 2022 -0800
>
> src.opts.mk: Require C++20 for C++ support.
>
> libc++ requires C++20, so mark C++ (MK_CXX) as broken if the compiler
> does not support C++20.
>
> Reviewed by: emaste
> Differential Revision: https://reviews.freebsd.org/D36893
>
> diff --git a/share/mk/src.opts.mk b/share/mk/src.opts.mk
> index f69208f21556..5089a034350d 100644
> --- a/share/mk/src.opts.mk
> +++ b/share/mk/src.opts.mk
> @@ -348,6 +348,11 @@ __DEFAULT_YES_OPTIONS+=OPENMP
> __DEFAULT_NO_OPTIONS+=OPENMP
> .endif
>
> +# libc++ requires C++20
> +.if !${COMPILER_FEATURES:Mc++20}
> +BROKEN_OPTIONS+=CXX
> +.endif
> +
> .include
>
>
> #
Sorry for the noise, this has been fixed by this commit.
commit ac4c695ad61e81d00cff2a03202a4afe94a92513
Author: Ed Maste
AuthorDate: Wed Nov 16 09:20:39 2022 -0500
Commit: Ed Maste
CommitDate: Thu Jan 26 21:13:16 2023 -0500
Retire WITHOUT_CXX option
Several important base system components are written in C++, and the
WITHOUT_CXX option produced a system that was not fully functional.
Just accept this, and remove the option to build without C++ support.
This reverts commit adc3c128c6603054586a993d117e5dd808deac17.
Reviewed by:brooks, kevans, jhb (earlier)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33108
Re: buildworld failed after deleting /usr/obj
--- Original Message ---
On Monday, January 23rd, 2023 at 1:44 PM, qroxana
wrote:
> --- Original Message ---
> On Monday, January 23rd, 2023 at 10:02 AM, Dimitry Andric d...@freebsd.org
> wrote:
>
>
>
> > On 23 Jan 2023, at 04:05, qroxana qrox...@protonmail.com wrote:
> >
> > > It seems ${MAKEOBJDIR} was not created for usr.bin/clang/llvm-objcopy.
> > >
> > > --- all_subdir_usr.bin ---
> > > --- objwarn ---
> > > Warning: Object directory not changed from original
> > > /usr/src/usr.bin/clang/llvm-objcopy
> >
> > This is usually an indication that your source directory contains object
> > files, e.g. is "dirty". Run "make clean" from the top level, or clean up
> > your source checkout with something like "git clean".
> >
> > -Dimitry
>
>
> I had tried it with a clean source directory and empty /usr/obj
>
> # find /usr/src/usr.bin/clang/llvm-objcopy
> /usr/src/usr.bin/clang/llvm-objcopy
> /usr/src/usr.bin/clang/llvm-objcopy/llvm-objcopy.1
> /usr/src/usr.bin/clang/llvm-objcopy/Makefile
>
> and "make buildworld" still ended with the same error.
>
> In /usr/src/Makefile.inc1, the _NO_INCLUDE_COMPILERMK=t option prevents
> creating
> the obj directories for the stuff in usr.bin/clang/.
>
> 1098 _obj:
> 1099 @echo
> 1100 @echo "--"
> 1101 @echo ">>> stage 2.2: rebuilding the object tree"
>
> 1102 @echo "--"
> 1103 ${+}cd ${.CURDIR}; ${WMAKE} _NO_INCLUDE_COMPILERMK=t obj
>
> > --- all_subdir_usr.bin ---
> > --- objwarn ---
> > Warning: Object directory not changed from original
> > /usr/src/usr.bin/clang/llvm-objcopy
>
>
> This happens in stage 4.4, and there's no ${MAKEOBJDIR} directory created
> for usr.bin/clang/llvm-objcopy
>
It appears buildworld doesn't create the obj directory for
usr.bin/clang/llvm-objcopy in stage 2.2 after this commit.
commit adc3c128c6603054586a993d117e5dd808deac17
Author: John Baldwin
AuthorDate: Fri Nov 18 20:12:28 2022 -0800
Commit: John Baldwin
CommitDate: Fri Nov 18 20:12:28 2022 -0800
src.opts.mk: Require C++20 for C++ support.
libc++ requires C++20, so mark C++ (MK_CXX) as broken if the compiler
does not support C++20.
Reviewed by:emaste
Differential Revision: https://reviews.freebsd.org/D36893
diff --git a/share/mk/src.opts.mk b/share/mk/src.opts.mk
index f69208f21556..5089a034350d 100644
--- a/share/mk/src.opts.mk
+++ b/share/mk/src.opts.mk
@@ -348,6 +348,11 @@ __DEFAULT_YES_OPTIONS+=OPENMP
__DEFAULT_NO_OPTIONS+=OPENMP
.endif
+# libc++ requires C++20
+.if !${COMPILER_FEATURES:Mc++20}
+BROKEN_OPTIONS+=CXX
+.endif
+
.include
#
Re: buildworld failed after deleting /usr/obj
--- Original Message ---
On Monday, January 23rd, 2023 at 10:02 AM, Dimitry Andric
wrote:
> On 23 Jan 2023, at 04:05, qroxana qrox...@protonmail.com wrote:
>
> > It seems ${MAKEOBJDIR} was not created for usr.bin/clang/llvm-objcopy.
> >
> > --- all_subdir_usr.bin ---
> > --- objwarn ---
> > Warning: Object directory not changed from original
> > /usr/src/usr.bin/clang/llvm-objcopy
>
>
> This is usually an indication that your source directory contains object
> files, e.g. is "dirty". Run "make clean" from the top level, or clean up
> your source checkout with something like "git clean".
>
> -Dimitry
I had tried it with a clean source directory and empty /usr/obj
# find /usr/src/usr.bin/clang/llvm-objcopy
/usr/src/usr.bin/clang/llvm-objcopy
/usr/src/usr.bin/clang/llvm-objcopy/llvm-objcopy.1
/usr/src/usr.bin/clang/llvm-objcopy/Makefile
and "make buildworld" still ended with the same error.
In /usr/src/Makefile.inc1, the _NO_INCLUDE_COMPILERMK=t option prevents creating
the obj directories for the stuff in usr.bin/clang/.
1098 _obj:
1099 @echo
1100 @echo
"--"
1101 @echo ">>> stage 2.2: rebuilding the object tree"
1102 @echo
"--"
1103 ${_+_}cd ${.CURDIR}; ${WMAKE} _NO_INCLUDE_COMPILERMK=t obj
> --- all_subdir_usr.bin ---
> --- objwarn ---
> Warning: Object directory not changed from original
> /usr/src/usr.bin/clang/llvm-objcopy
This happens in stage 4.4, and there's no ${MAKEOBJDIR} directory created
for usr.bin/clang/llvm-objcopy
Re: buildworld failed after deleting /usr/obj
On 23 Jan 2023, at 04:05, qroxana wrote:
>
> It seems ${MAKEOBJDIR} was not created for usr.bin/clang/llvm-objcopy.
>
> --- all_subdir_usr.bin ---
> --- objwarn ---
> Warning: Object directory not changed from original
> /usr/src/usr.bin/clang/llvm-objcopy
This is usually an indication that your source directory contains object
files, e.g. is "dirty". Run "make clean" from the top level, or clean up
your source checkout with something like "git clean".
-Dimitry
signature.asc
Description: Message signed with OpenPGP
Re: buildworld fail: ld: error: undefined symbol: test_no_kevents
> Am 06.06.2022 um 13:42 schrieb Ronald Klop : > > > ….. Will take 10+ hours to compile clang for the millionth time. > I also often prefer compiling on target hardware… but to be honest: cross compiling on -j(fullspeed)-machines to PXE-boot one slow boards is the only „painless" workflow. On the other hand e.g. / NO_OBJWALK / perhaps should work as expected w/o ld-error and w/o using WITHOUT_TESTS(in this case), so up to you filing a bug report if you think it’s worth..
Re: buildworld fail: ld: error: undefined symbol: test_no_kevents
Hi, Mmm, took another look. I doubt my clean build was clean as "wipe out workspace" did not work because the Jenkins agent was offline. The problem might be PEBCAK[1]. :-) Doing another build with a fresh Jenkins workspace now. Will take 10+ hours to compile clang for the millionth time. Ronald. [1] https://en.wiktionary.org/wiki/PEBCAK Van: Dimitry Andric Datum: maandag, 6 juni 2022 12:16 Aan: Ronald Klop CC: freebsd-current , Mark Johnston Onderwerp: Re: buildworld fail: ld: error: undefined symbol: test_no_kevents Looks like it might be using an old version of tests/sys/kqueue/libkqueue/common.h, after https://cgit.freebsd.org/src/commit/?id=c728c56c870abe230e45cee5c477f0d890ebacef ? Without seeing how the .o files have been compiled, specifically with which -I flags, it is impossible to see what is going wrong, though. -Dimitry On 6 Jun 2022, at 11:59, Ronald Klop wrote: Hi, Building on aarch64/14-CURRENT fails with this error on my rpi4. It failed on incremental build and tried a clean build today. First failure was on "World build started on Sun May 29 00:25:17 UTC 2022". This weekend it still fails (I'm building weekly in Jenkins). 10:04:44 ===> tests/sys/kqueue/libkqueue (all) 10:04:44 --- kqueue_test --- 10:04:44 (cd /usr/src/tests/sys/kqueue/libkqueue && DEPENDFILE=.depend.kqueue_test NO_SUBDIR=1 /usr/bin/make -f /usr/src/tests/sys/kqueue/libkqueue/Makefile _RECURSING_PROGS=t PROG=kqueue_test ) 10:04:44 --- kqueue_test.full --- 10:04:44 cc -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common -fPIE -g -gz=zlib -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments -pie -o kqueue_test.full main.o read.o timer.o vnode.o proc.o signal.o user.o 10:04:44 ld: error: undefined symbol: test_no_kevents 10:04:45 >>> referenced by read.c:169 (/usr/src/tests/sys/kqueue/libkqueue/read.c:169) 10:04:45 >>> read.o:(test_evfilt_read) 10:04:45 >>> referenced by read.c:75 (/usr/src/tests/sys/kqueue/libkqueue/read.c:75) 10:04:45 >>> read.o:(test_evfilt_read) 10:04:45 >>> referenced by read.c:137 (/usr/src/tests/sys/kqueue/libkqueue/read.c:137) 10:04:45 >>> read.o:(test_evfilt_read) 10:04:45 >>> referenced 31 more times 10:04:45 >>> did you mean: _test_no_kevents 10:04:45 >>> defined in: main.o 10:04:45 10:04:45 ld: error: undefined symbol: kevent_cmp 10:04:45 >>> referenced by read.c:72 (/usr/src/tests/sys/kqueue/libkqueue/read.c:72) 10:04:45 >>> read.o:(test_evfilt_read) 10:04:45 >>> referenced by read.c:145 (/usr/src/tests/sys/kqueue/libkqueue/read.c:145) 10:04:45 >>> read.o:(test_evfilt_read) 10:04:45 >>> referenced by read.c:193 (/usr/src/tests/sys/kqueue/libkqueue/read.c:193) 10:04:45 >>> read.o:(test_evfilt_read) 10:04:45 >>> referenced 14 more times 10:04:45 >>> did you mean: _kevent_cmp 10:04:45 >>> defined in: main.o 10:04:45 cc: error: linker command failed with exit code 1 (use -v to see invocation) 10:04:45 668.58 real 125.97 user62.12 sys 10:04:45 10:04:45 make[1]: stopped in /usr/src 10:04:45 10:04:45 make: stopped in /usr/src 10:04:45 Build step 'Execute shell' marked build as failure 10:04:46 Skipped archiving because build is not successful 10:04:46 Sending e-mails to: x...@.zzz 10:04:47 Finished: FAILURE Any thoughts? Similar experience? Regards, Ronald.
Re: buildworld fail: ld: error: undefined symbol: test_no_kevents
> Am 06.06.2022 um 11:59 schrieb Ronald Klop : > > on my rpi4….. > 10:04:45 > 10:04:45 > ld: error: undefined symbol: kevent_cmp > > Any thoughts? Similar experience? > > Yes, similar experience(~1 week ago) , specially when using NO_CLEAN flag , as far as I remember.. `got around this issue by using the WITHOUT_TESTS flag .
Re: buildworld fail: ld: error: undefined symbol: test_no_kevents
Looks like it might be using an old version of tests/sys/kqueue/libkqueue/common.h, after https://cgit.freebsd.org/src/commit/?id=c728c56c870abe230e45cee5c477f0d890ebacef ? Without seeing how the .o files have been compiled, specifically with which -I flags, it is impossible to see what is going wrong, though. -Dimitry > On 6 Jun 2022, at 11:59, Ronald Klop wrote: > > Hi, > > Building on aarch64/14-CURRENT fails with this error on my rpi4. > It failed on incremental build and tried a clean build today. > > First failure was on "World build started on Sun May 29 00:25:17 UTC 2022". > > This weekend it still fails (I'm building weekly in Jenkins). > 10:04:44 ===> tests/sys/kqueue/libkqueue (all) > 10:04:44 --- kqueue_test --- > 10:04:44 (cd /usr/src/tests/sys/kqueue/libkqueue && > DEPENDFILE=.depend.kqueue_test NO_SUBDIR=1 /usr/bin/make -f > /usr/src/tests/sys/kqueue/libkqueue/Makefile _RECURSING_PROGS=t > PROG=kqueue_test ) > 10:04:44 --- kqueue_test.full --- > 10:04:44 cc -target aarch64-unknown-freebsd14.0 > --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common -fPIE -g > -gz=zlib -std=gnu99 -Wno-format-zero-length -fstack-protector-strong > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Wnested-externs -Wold-style-definition -Wno-pointer-sign > -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body > -Wno-string-plus-int -Wno-unused-const-variable > -Wno-error=unused-but-set-variable -Qunused-arguments -pie -o > kqueue_test.full main.o read.o timer.o vnode.o proc.o signal.o user.o > 10:04:44 ld: error: undefined symbol: test_no_kevents > 10:04:45 >>> referenced by read.c:169 > (/usr/src/tests/sys/kqueue/libkqueue/read.c:169) > 10:04:45 >>> read.o:(test_evfilt_read) > 10:04:45 >>> referenced by read.c:75 > (/usr/src/tests/sys/kqueue/libkqueue/read.c:75) > 10:04:45 >>> read.o:(test_evfilt_read) > 10:04:45 >>> referenced by read.c:137 > (/usr/src/tests/sys/kqueue/libkqueue/read.c:137) > 10:04:45 >>> read.o:(test_evfilt_read) > 10:04:45 >>> referenced 31 more times > 10:04:45 >>> did you mean: _test_no_kevents > 10:04:45 >>> defined in: main.o > 10:04:45 > 10:04:45 ld: error: undefined symbol: kevent_cmp > 10:04:45 >>> referenced by read.c:72 > (/usr/src/tests/sys/kqueue/libkqueue/read.c:72) > 10:04:45 >>> read.o:(test_evfilt_read) > 10:04:45 >>> referenced by read.c:145 > (/usr/src/tests/sys/kqueue/libkqueue/read.c:145) > 10:04:45 >>> read.o:(test_evfilt_read) > 10:04:45 >>> referenced by read.c:193 > (/usr/src/tests/sys/kqueue/libkqueue/read.c:193) > 10:04:45 >>> read.o:(test_evfilt_read) > 10:04:45 >>> referenced 14 more times > 10:04:45 >>> did you mean: _kevent_cmp > 10:04:45 >>> defined in: main.o > 10:04:45 cc: error: linker command failed with exit code 1 (use -v to see > invocation) > 10:04:45 668.58 real 125.97 user62.12 sys > 10:04:45 > 10:04:45 make[1]: stopped in /usr/src > 10:04:45 > 10:04:45 make: stopped in /usr/src > 10:04:45 Build step 'Execute shell' marked build as failure > 10:04:46 Skipped archiving because build is not successful > 10:04:46 Sending e-mails to: x...@.zzz > 10:04:47 Finished: FAILURE > > Any thoughts? Similar experience? > > Regards, > Ronald. > > signature.asc Description: Message signed with OpenPGP
Re: Buildworld fails with external GCC toolchain
From: Yasuhiro Kimura Subject: Re: Buildworld fails with external GCC toolchain Date: Tue, 15 Feb 2022 08:26:00 +0900 (JST) >> I have amd64 world + kernel building with GCC 9 and the only remaining >> open review not merged yet is https://reviews.freebsd.org/D34147. >> >> It is work to keep it working though and I hadn't worked on it again >> until recently. > > Thanks for letting me know. I tried patch of the review and confirmed > both buildworld and buildkernel succeed with GCC 9 and binutils 2.37. > So I reached start point now and can test binutils 2.38. I tried buildworld and buildkernel with binutils 2.38 and they completed successfully. Just FYI. --- Yasuhiro Kimura
Re: Buildworld fails with external GCC toolchain
From: John Baldwin
Subject: Re: Buildworld fails with external GCC toolchain
Date: Mon, 14 Feb 2022 10:46:29 -0800
>>> Not really, the gcc 9 build has been broken for months, as far as I
>>> know.
>>>
>>> See also: https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc9_build/
>>>
>>> The last build(s) show a different error from yours, though:
>>>
>>> /workspace/src/tests/sys/netinet/libalias/util.c: In function
>>> 'set_udp':
>>> /workspace/src/tests/sys/netinet/libalias/util.c:112:2: error:
>>> converting a packed 'struct ip' pointer (alignment 2) to a 'uint32_t'
>>> {aka 'unsigned int'} pointer (alignment 4) may result in an unaligned
>>> pointer value [-Werror=address-of-packed-member]
>>>112 | uint32_t *up = (void *)p;
>>>| ^~~~
>>> In file included from
>>> /workspace/src/tests/sys/netinet/libalias/util.h:37,
>>> from /workspace/src/tests/sys/netinet/libalias/util.c:39:
>>> /workspace/src/sys/netinet/ip.h:51:8: note: defined here
>>> 51 | struct ip {
>>>|^~
>>>
>>> -Dimitry
>>>
>> Thanks for information. I went back the commit history of main branch
>> about every month and check if buildworld succeeds with GCC. But it
>> didn't succeed even if I went back about a year. And devel/binutils
>> port was update to 2.37 on last August. So I suspect external GCC
>> toolchain doesn't work well after binutils is updated to current
>> version.
>
> I have amd64 world + kernel building with GCC 9 and the only remaining
> open review not merged yet is https://reviews.freebsd.org/D34147.
>
> It is work to keep it working though and I hadn't worked on it again
> until recently.
Thanks for letting me know. I tried patch of the review and confirmed
both buildworld and buildkernel succeed with GCC 9 and binutils 2.37.
So I reached start point now and can test binutils 2.38.
---
Yasuhiro Kimura
Re: Buildworld fails with external GCC toolchain
On 2/12/22 11:34 AM, Yasuhiro Kimura wrote:
From: Dimitry Andric
Subject: Re: Buildworld fails with external GCC toolchain
Date: Fri, 11 Feb 2022 22:53:44 +0100
Not really, the gcc 9 build has been broken for months, as far as I know.
See also: https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc9_build/
The last build(s) show a different error from yours, though:
/workspace/src/tests/sys/netinet/libalias/util.c: In function 'set_udp':
/workspace/src/tests/sys/netinet/libalias/util.c:112:2: error: converting a
packed 'struct ip' pointer (alignment 2) to a 'uint32_t' {aka 'unsigned int'}
pointer (alignment 4) may result in an unaligned pointer value
[-Werror=address-of-packed-member]
112 | uint32_t *up = (void *)p;
| ^~~~
In file included from /workspace/src/tests/sys/netinet/libalias/util.h:37,
from /workspace/src/tests/sys/netinet/libalias/util.c:39:
/workspace/src/sys/netinet/ip.h:51:8: note: defined here
51 | struct ip {
|^~
-Dimitry
Thanks for information. I went back the commit history of main branch
about every month and check if buildworld succeeds with GCC. But it
didn't succeed even if I went back about a year. And devel/binutils
port was update to 2.37 on last August. So I suspect external GCC
toolchain doesn't work well after binutils is updated to current
version.
I have amd64 world + kernel building with GCC 9 and the only remaining
open review not merged yet is https://reviews.freebsd.org/D34147.
It is work to keep it working though and I hadn't worked on it again
until recently.
--
John Baldwin
Re: Buildworld fails with external GCC toolchain
From: Dimitry Andric
Subject: Re: Buildworld fails with external GCC toolchain
Date: Fri, 11 Feb 2022 22:53:44 +0100
> Not really, the gcc 9 build has been broken for months, as far as I know.
>
> See also: https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc9_build/
>
> The last build(s) show a different error from yours, though:
>
> /workspace/src/tests/sys/netinet/libalias/util.c: In function 'set_udp':
> /workspace/src/tests/sys/netinet/libalias/util.c:112:2: error: converting a
> packed 'struct ip' pointer (alignment 2) to a 'uint32_t' {aka 'unsigned int'}
> pointer (alignment 4) may result in an unaligned pointer value
> [-Werror=address-of-packed-member]
> 112 | uint32_t *up = (void *)p;
> | ^~~~
> In file included from /workspace/src/tests/sys/netinet/libalias/util.h:37,
> from /workspace/src/tests/sys/netinet/libalias/util.c:39:
> /workspace/src/sys/netinet/ip.h:51:8: note: defined here
>51 | struct ip {
> |^~
>
> -Dimitry
>
Thanks for information. I went back the commit history of main branch
about every month and check if buildworld succeeds with GCC. But it
didn't succeed even if I went back about a year. And devel/binutils
port was update to 2.37 on last August. So I suspect external GCC
toolchain doesn't work well after binutils is updated to current
version.
---
Yasuhiro Kimura
Re: Buildworld fails with external GCC toolchain
On 11 Feb 2022, at 21:07, Yasuhiro Kimura wrote:
>
> I'm tring to update devel/binutils port to 2.38. When it was updated
> to 2.37.1, there was a suggestion that it should also be checked if
> building base system with GCC succeeds as binutils is a part of
> external GCC toolchain. So I'd like to do it with binutils 2.38 before
> updating the port. And as a preparation for it, I tried building base
> system with current external GCC toolchain (that is, with binutils
> 2.37.1).
>
> At first I read following wiki pages.
>
> https://wiki.freebsd.org/ExternalToolchain
> https://wiki.freebsd.org/ExternalGCC
>
> Next I took following steps.
>
> 1. Make clean install of 14-CURRENT amd64 with the install image of
> 20220210 snapshot.
> 2. Checkout latest main of src repository (d4b0fa45dc1 at that time).
> 3. pkg install amd64-gcc9
> 4. cd /usr/src
> 5. make -j 4 CROSS_TOOLCHAIN=amd64-gcc9 buildworld buildkernel
>
> Then step 5 failed as following.
>
> --
> --- all_subdir_rescue ---
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld: nc.lo: in function `_$$hide$$
> nc.lo main':
> (.text.startup+0xd42): warning: warning: mktemp() possibly used unsafely;
> consider using mkstemp()
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_set_term.o):
> in function `_nc_setupscreen_sp':
> /usr/src/contrib/ncurses/ncurses/base/lib_set_term.c:415: undefined reference
> to `_nc_set_buffer_sp'
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_tstp.o): in
> function `handle_SIGTSTP':
> /usr/src/contrib/ncurses/ncurses/tty/lib_tstp.c:222: undefined reference to
> `flushinp_sp'
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_getch.o): in
> function `check_mouse_activity':
> /usr/src/contrib/ncurses/ncurses/base/lib_getch.c:188: undefined reference to
> `_nc_timed_wait'
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_getstr.o): in
> function `wgetnstr':
> /usr/src/contrib/ncurses/ncurses/base/lib_getstr.c:106: undefined reference
> to `erasechar_sp'
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld:
> /usr/src/contrib/ncurses/ncurses/base/lib_getstr.c:107: undefined reference
> to `killchar_sp'
> collect2: error: ld returned 1 exit status
> *** [rescue] Error code 1
>
> make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue
> --- all_subdir_stand ---
>
> make[2]: stopped in /usr/src
> --- all_subdir_share ---
>
> make[2]: stopped in /usr/src
> --- all_subdir_rescue ---
> 1 error
>
> make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue
> *** [rescue] Error code 2
>
> make[4]: stopped in /usr/src/rescue/rescue
> 1 error
>
> make[4]: stopped in /usr/src/rescue/rescue
>
> make[3]: stopped in /usr/src/rescue
>
> make[2]: stopped in /usr/src
> --- all_subdir_lib ---
>
> make[2]: stopped in /usr/src
> 167.49 real 492.07 user94.42 sys
>
> make[1]: stopped in /usr/src
>
> make: stopped in /usr/src
> --
>
> If I check commit messages of main branch over the last few months, I
> can find some commits that fix warning message displayed by GCC. So
> currently external GCC toolchain seems to work fine. Then what is the
> cause of my build failure? Did I do something wrong?
Not really, the gcc 9 build has been broken for months, as far as I know.
See also: https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc9_build/
The last build(s) show a different error from yours, though:
/workspace/src/tests/sys/netinet/libalias/util.c: In function 'set_udp':
/workspace/src/tests/sys/netinet/libalias/util.c:112:2: error: converting a
packed 'struct ip' pointer (alignment 2) to a 'uint32_t' {aka 'unsigned int'}
pointer (alignment 4) may result in an unaligned pointer value
[-Werror=address-of-packed-member]
112 | uint32_t *up = (void *)p;
| ^~~~
In file included from /workspace/src/tests/sys/netinet/libalias/util.h:37,
from /workspace/src/tests/sys/netinet/libalias/util.c:39:
/workspace/src/sys/netinet/ip.h:51:8: note: defined here
51 | struct ip {
|^~
-Dimitry
signature.asc
Description: Message signed with OpenPGP
Re: buildworld failed
On 8/2/22 15:45, Warner Losh wrote: On Tue, Feb 8, 2022 at 3:43 AM George Abdelmalik wrote: On 7/2/22 03:50, qroxana wrote: I know running make install for /usr/src/tools/build/test-includes can fix this, but this still fails on a newly installed 14.0-CURRENT. --- test-includes --- cd /usr/src/tools/build/test-includes; MACHINE_ARCH=aarch64 MACHINE=arm64 CPUTYPE= CC="cc -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="c++ -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CPP="cpp -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" AS="as" AR="ar" ELFCTL="elfctl" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" STRIPBIN="strip" INSTALL="install -U" PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp test-includes --- sys/abi_compat.c --- --- sys/acct.c --- --- sys/acl.c --- --- sys/aio.c --- --- sys/abi_compat.c --- echo "#include " > sys/abi_compat.c sh: cannot create sys/abi_compat.c: No such file or directory *** [sys/abi_compat.c] Error code 2 make[4]: stopped in /usr/src/tools/build/test-includes --- sys/acct.c --- echo "#include " > sys/acct.c sh: cannot create sys/acct.c: No such file or directory *** [sys/acct.c] Error code 2 make[4]: stopped in /usr/src/tools/build/test-includes --- sys/aio.c --- echo "#include " > sys/aio.c sh: cannot create sys/aio.c: No such file or directory *** [sys/aio.c] Error code 2 make[4]: stopped in /usr/src/tools/build/test-includes --- sys/acl.c --- echo "#include " > sys/acl.c sh: cannot create sys/acl.c: No such file or directory *** [sys/acl.c] Error code 2 Same here for me for the past couple of weeks. Haven't been able to identify why it fails. My hunch was that a particular objdir wasn't being created. As a workaround I edited the Makefile.inc1 to remove the test-includes command (line 1128 I think). I'd really like to understand why this error comes about. If someone has any insights, please share them :) What build options are you using? this is the test to make sure that files can be included on their own. Warner Hi Warner, My make.conf contains: # make.conf(5) to use when building world. MALLOC_PRODUCTION= My src.conf contains: ## src.conf(5) to use when building world. WITHOUT_IPFILTER= WITHOUT_PF= WITHOUT_PPP= WITHOUT_LPR= WITHOUT_NIS= WITHOUT_LIB32= WITHOUT_HYPERV= WITHOUT_APM= WITHOUT_ATM= WITHOUT_FINGER= WITHOUT_FLOPPY= WITHOUT_RADIUS_SUPPORT= WITHOUT_DEBUG_FILES= WITHOUT_TESTS= The build command is: env MAKEOBJDIRPREFIX=$HOME/obj \ make -j2 \ -DNO_CLEAN \ __MAKE_CONF=$HOME/make.conf \ SRCCONF=$HOME/src.conf \ TARGET=amd64 \ TARGET_ARCH=amd64 \ CPUTYPE= \ buildworld Perhaps the issue is that I first build the toolchain as a separate step prior to invoking buildworld, that command is: env MAKEOBJDIRPREFIX=$HOME/obj \ make -j2 \ __MAKE_CONF=$HOME/make.conf \ SRCCONF=$HOME/src.conf \ TARGET=amd64 \ TARGET_ARCH=amd64 \ toolchain Thanks for your interest, George.
Re: buildworld failed
Brooks Davis wrote: > On Tue, Feb 08, 2022 at 02:52:27PM -0800, Simon J. Gerraty wrote: > > Brooks Davis wrote: > > > > > > This would be fine, but should not be necessicary. The sys subdir should > > > be created by AUTOOBJ. > > > > .OBJDIR should be (and is), not .OBJDIR/sys > > We've had support for relative paths in SRCS since 2015 > (cee9be4971a56f2a748eb78df97b72e42fe860ab). If this is broken if some > supported modes we should fix it or remove it (but I belive clang/llvm > depends on it). That logic appears to be in bsd.obj.mk as part of the obj target it depends on SRCS containing paths with / That target does not get run if one is using auto.obj.mk --sjg
Re: buildworld failed
On Tue, Feb 08, 2022 at 02:52:27PM -0800, Simon J. Gerraty wrote: > Brooks Davis wrote: > > > > This would be fine, but should not be necessicary. The sys subdir should > > be created by AUTOOBJ. > > .OBJDIR should be (and is), not .OBJDIR/sys We've had support for relative paths in SRCS since 2015 (cee9be4971a56f2a748eb78df97b72e42fe860ab). If this is broken if some supported modes we should fix it or remove it (but I belive clang/llvm depends on it). -- Brooks signature.asc Description: PGP signature
Re: buildworld failed
I went ahead and committed this as 5ae6cc00111c since we chatted about it here. Warner On Tue, Feb 8, 2022 at 5:10 PM Warner Losh wrote: > > > On Tue, Feb 8, 2022 at 3:52 PM Simon J. Gerraty wrote: > >> Brooks Davis wrote: >> > >> > This would be fine, but should not be necessicary. The sys subdir should >> > be created by AUTOOBJ. >> >> .OBJDIR should be (and is), not .OBJDIR/sys >> making that subdir is up to the makefile and would also fix the problem, >> but given the nature of what the makefile is doing just replacing / with >> _ is simpler. >> > > Agreed. Testing this. > > Warner >
Re: buildworld failed
On Tue, Feb 8, 2022 at 3:52 PM Simon J. Gerraty wrote: > Brooks Davis wrote: > > > > This would be fine, but should not be necessicary. The sys subdir should > > be created by AUTOOBJ. > > .OBJDIR should be (and is), not .OBJDIR/sys > making that subdir is up to the makefile and would also fix the problem, > but given the nature of what the makefile is doing just replacing / with > _ is simpler. > Agreed. Testing this. Warner
Re: buildworld failed
Brooks Davis wrote: > > This would be fine, but should not be necessicary. The sys subdir should > be created by AUTOOBJ. .OBJDIR should be (and is), not .OBJDIR/sys making that subdir is up to the makefile and would also fix the problem, but given the nature of what the makefile is doing just replacing / with _ is simpler.
Re: buildworld failed
Warner Losh wrote: > > Same here for me for the past couple of weeks. Haven't been able to > > identify why it fails. My hunch was that a particular objdir wasn't > > being created. As a workaround I edited the Makefile.inc1 to remove > > the test-includes command (line 1128 I think). > > The sys subdir does not exist. > > Why does it exist for me, though? What's making it for me and not for the OP? Unless you cleaned your tree recently, that could just be an artifact of an earlier version of the makefile. > > Best bet would be to avoid the need: > > Oh, I like this and I agree. Do you want to commit, or should I do the honors? Feel free, I've got my hands full at present.
Re: buildworld failed
On Tue, Feb 08, 2022 at 09:56:19AM -0800, Simon J. Gerraty wrote:
> Warner Losh wrote:
> > --- sys/abi_compat.c ---
> > echo "#include " > sys/abi_compat.c
> > sh: cannot create sys/abi_compat.c: No such file or directory
> > *** [sys/abi_compat.c] Error code 2
> >
> > make[4]: stopped in /usr/src/tools/build/test-includes
> > --- sys/acct.c ---
> > echo "#include " > sys/acct.c
> > sh: cannot create sys/acct.c: No such file or directory
> > *** [sys/acct.c] Error code 2
> >
> > make[4]: stopped in /usr/src/tools/build/test-includes
> > --- sys/aio.c ---
> > echo "#include " > sys/aio.c
> > sh: cannot create sys/aio.c: No such file or directory
> > *** [sys/aio.c] Error code 2
> >
> > make[4]: stopped in /usr/src/tools/build/test-includes
> > --- sys/acl.c ---
> > echo "#include " > sys/acl.c
> > sh: cannot create sys/acl.c: No such file or directory
> > *** [sys/acl.c] Error code 2
> >
> >
> >
> > Same here for me for the past couple of weeks. Haven't been able to
> > identify why it fails. My hunch was that a particular objdir wasn't
> > being created. As a workaround I edited the Makefile.inc1 to remove
> > the test-includes command (line 1128 I think).
>
> The sys subdir does not exist.
> Best bet would be to avoid the need:
>
> diff --git a/tools/build/test-includes/Makefile
> b/tools/build/test-includes/Makefile
> index 3ae39a2cb61..eb9016ecc03 100644
> --- a/tools/build/test-includes/Makefile
> +++ b/tools/build/test-includes/Makefile
> @@ -24,11 +24,11 @@ CFLAGS.event.c= -D_WANT_KEVENT32
> -D_WANT_FREEBSD11_KEVENT
>
> .include "badfiles.inc"
>
> -.for h in ${HDRS}
> +.for h c in ${HDRS:@x@$x ${x:S,/,_,g:R}.c@}
> .if !${BADHDRS:M${h}}
> -SRCS+= ${h:R}.c
> -CLEANFILES+=${h:R}.c
> -${h:R}.c:
> +SRCS+= $c
> +CLEANFILES+=$c
> +$c:
> echo "#include <$h>" > ${.TARGET}
> .endif
> .endfor
>
> so you get:
>
> echo "#include " > sys_abi_compat.c
> echo "#include " > sys_acct.c
> echo "#include " > sys_acl.c
> echo "#include " > sys_aio.c
> echo "#include " > sys_alq.c
> echo "#include " > sys_apm.c
> echo "#include " > sys_arb.c
> echo "#include " > sys_asan.c
> echo "#include " > sys_assym.c
>
> etc
>
This would be fine, but should not be necessicary. The sys subdir should
be created by AUTOOBJ.
-- Brooks
signature.asc
Description: PGP signature
Re: buildworld failed
On Tue, Feb 8, 2022 at 10:56 AM Simon J. Gerraty wrote:
> Warner Losh wrote:
> > --- sys/abi_compat.c ---
> > echo "#include " > sys/abi_compat.c
> > sh: cannot create sys/abi_compat.c: No such file or directory
> > *** [sys/abi_compat.c] Error code 2
> >
> > make[4]: stopped in /usr/src/tools/build/test-includes
> > --- sys/acct.c ---
> > echo "#include " > sys/acct.c
> > sh: cannot create sys/acct.c: No such file or directory
> > *** [sys/acct.c] Error code 2
> >
> > make[4]: stopped in /usr/src/tools/build/test-includes
> > --- sys/aio.c ---
> > echo "#include " > sys/aio.c
> > sh: cannot create sys/aio.c: No such file or directory
> > *** [sys/aio.c] Error code 2
> >
> > make[4]: stopped in /usr/src/tools/build/test-includes
> > --- sys/acl.c ---
> > echo "#include " > sys/acl.c
> > sh: cannot create sys/acl.c: No such file or directory
> > *** [sys/acl.c] Error code 2
> >
> >
> >
> > Same here for me for the past couple of weeks. Haven't been able to
> > identify why it fails. My hunch was that a particular objdir wasn't
> > being created. As a workaround I edited the Makefile.inc1 to remove
> > the test-includes command (line 1128 I think).
>
> The sys subdir does not exist.
>
Why does it exist for me, though? What's making it for me and not for the
OP?
> Best bet would be to avoid the need:
>
Oh, I like this and I agree. Do you want to commit, or should I do the
honors?
Warner
> diff --git a/tools/build/test-includes/Makefile
> b/tools/build/test-includes/Makefile
> index 3ae39a2cb61..eb9016ecc03 100644
> --- a/tools/build/test-includes/Makefile
> +++ b/tools/build/test-includes/Makefile
> @@ -24,11 +24,11 @@ CFLAGS.event.c= -D_WANT_KEVENT32
> -D_WANT_FREEBSD11_KEVENT
>
> .include "badfiles.inc"
>
> -.for h in ${HDRS}
> +.for h c in ${HDRS:@x@$x ${x:S,/,_,g:R}.c@}
> .if !${BADHDRS:M${h}}
> -SRCS+= ${h:R}.c
> -CLEANFILES+=${h:R}.c
> -${h:R}.c:
> +SRCS+= $c
> +CLEANFILES+=$c
> +$c:
> echo "#include <$h>" > ${.TARGET}
> .endif
> .endfor
>
> so you get:
>
> echo "#include " > sys_abi_compat.c
> echo "#include " > sys_acct.c
> echo "#include " > sys_acl.c
> echo "#include " > sys_aio.c
> echo "#include " > sys_alq.c
> echo "#include " > sys_apm.c
> echo "#include " > sys_arb.c
> echo "#include " > sys_asan.c
> echo "#include " > sys_assym.c
>
> etc
>
Re: buildworld failed
Warner Losh wrote:
> --- sys/abi_compat.c ---
> echo "#include " > sys/abi_compat.c
> sh: cannot create sys/abi_compat.c: No such file or directory
> *** [sys/abi_compat.c] Error code 2
>
> make[4]: stopped in /usr/src/tools/build/test-includes
> --- sys/acct.c ---
> echo "#include " > sys/acct.c
> sh: cannot create sys/acct.c: No such file or directory
> *** [sys/acct.c] Error code 2
>
> make[4]: stopped in /usr/src/tools/build/test-includes
> --- sys/aio.c ---
> echo "#include " > sys/aio.c
> sh: cannot create sys/aio.c: No such file or directory
> *** [sys/aio.c] Error code 2
>
> make[4]: stopped in /usr/src/tools/build/test-includes
> --- sys/acl.c ---
> echo "#include " > sys/acl.c
> sh: cannot create sys/acl.c: No such file or directory
> *** [sys/acl.c] Error code 2
>
>
>
> Same here for me for the past couple of weeks. Haven't been able to
> identify why it fails. My hunch was that a particular objdir wasn't
> being created. As a workaround I edited the Makefile.inc1 to remove
> the test-includes command (line 1128 I think).
The sys subdir does not exist.
Best bet would be to avoid the need:
diff --git a/tools/build/test-includes/Makefile
b/tools/build/test-includes/Makefile
index 3ae39a2cb61..eb9016ecc03 100644
--- a/tools/build/test-includes/Makefile
+++ b/tools/build/test-includes/Makefile
@@ -24,11 +24,11 @@ CFLAGS.event.c= -D_WANT_KEVENT32
-D_WANT_FREEBSD11_KEVENT
.include "badfiles.inc"
-.for h in ${HDRS}
+.for h c in ${HDRS:@x@$x ${x:S,/,_,g:R}.c@}
.if !${BADHDRS:M${h}}
-SRCS+= ${h:R}.c
-CLEANFILES+=${h:R}.c
-${h:R}.c:
+SRCS+= $c
+CLEANFILES+=$c
+$c:
echo "#include <$h>" > ${.TARGET}
.endif
.endfor
so you get:
echo "#include " > sys_abi_compat.c
echo "#include " > sys_acct.c
echo "#include " > sys_acl.c
echo "#include " > sys_aio.c
echo "#include " > sys_alq.c
echo "#include " > sys_apm.c
echo "#include " > sys_arb.c
echo "#include " > sys_asan.c
echo "#include " > sys_assym.c
etc
Re: buildworld failed
On Tue, Feb 8, 2022 at 3:43 AM George Abdelmalik wrote: > > On 7/2/22 03:50, qroxana wrote: > > > > I know running make install for /usr/src/tools/build/test-includes can fix > this, > but this still fails on a newly installed 14.0-CURRENT. > > --- test-includes --- > cd /usr/src/tools/build/test-includes; MACHINE_ARCH=aarch64 > MACHINE=arm64 CPUTYPE= CC="cc -target aarch64-unknown-freebsd14.0 > --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target > aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="c++ -target > aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target > aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CPP="cpp -target > aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target > aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp > -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" AS="as" AR="ar" > ELFCTL="elfctl" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" > RANLIB=ranlib STRINGS= SIZE="size" STRIPBIN="strip" INSTALL="install -U" > PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin > SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make > DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp test-includes > --- sys/abi_compat.c --- > --- sys/acct.c --- > --- sys/acl.c --- > --- sys/aio.c --- > --- sys/abi_compat.c --- > echo "#include " > sys/abi_compat.c > sh: cannot create sys/abi_compat.c: No such file or directory > *** [sys/abi_compat.c] Error code 2 > > make[4]: stopped in /usr/src/tools/build/test-includes > --- sys/acct.c --- > echo "#include " > sys/acct.c > sh: cannot create sys/acct.c: No such file or directory > *** [sys/acct.c] Error code 2 > > make[4]: stopped in /usr/src/tools/build/test-includes > --- sys/aio.c --- > echo "#include " > sys/aio.c > sh: cannot create sys/aio.c: No such file or directory > *** [sys/aio.c] Error code 2 > > make[4]: stopped in /usr/src/tools/build/test-includes > --- sys/acl.c --- > echo "#include " > sys/acl.c > sh: cannot create sys/acl.c: No such file or directory > *** [sys/acl.c] Error code 2 > > > Same here for me for the past couple of weeks. Haven't been able to > identify why it fails. My hunch was that a particular objdir wasn't being > created. As a workaround I edited the Makefile.inc1 to remove the > test-includes command (line 1128 I think). > > I'd really like to understand why this error comes about. If someone has > any insights, please share them :) > What build options are you using? this is the test to make sure that files can be included on their own. Warner
Re: buildworld failed
On 7/2/22 03:50, qroxana wrote: I know running make install for /usr/src/tools/build/test-includes can fix this, but this still fails on a newly installed 14.0-CURRENT. --- test-includes --- cd /usr/src/tools/build/test-includes; MACHINE_ARCH=aarch64 MACHINE=arm64 CPUTYPE= CC="cc -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="c++ -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CPP="cpp -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -target aarch64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" AS="as" AR="ar" ELFCTL="elfctl" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" STRIPBIN="strip" INSTALL="install -U" PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp test-includes --- sys/abi_compat.c --- --- sys/acct.c --- --- sys/acl.c --- --- sys/aio.c --- --- sys/abi_compat.c --- echo "#include " > sys/abi_compat.c sh: cannot create sys/abi_compat.c: No such file or directory *** [sys/abi_compat.c] Error code 2 make[4]: stopped in /usr/src/tools/build/test-includes --- sys/acct.c --- echo "#include " > sys/acct.c sh: cannot create sys/acct.c: No such file or directory *** [sys/acct.c] Error code 2 make[4]: stopped in /usr/src/tools/build/test-includes --- sys/aio.c --- echo "#include " > sys/aio.c sh: cannot create sys/aio.c: No such file or directory *** [sys/aio.c] Error code 2 make[4]: stopped in /usr/src/tools/build/test-includes --- sys/acl.c --- echo "#include " > sys/acl.c sh: cannot create sys/acl.c: No such file or directory *** [sys/acl.c] Error code 2 Same here for me for the past couple of weeks. Haven't been able to identify why it fails. My hunch was that a particular objdir wasn't being created. As a workaround I edited the Makefile.inc1 to remove the test-includes command (line 1128 I think). I'd really like to understand why this error comes about. If someone has any insights, please share them :) Regards, George.
Re: buildworld question.
On Thu, Nov 11, 2021, 2:24 PM Jeffrey Bouquet wrote: > > > On Thu, 11 Nov 2021 08:53:47 -0700, Warner Losh wrote: > > > On Thu, Nov 11, 2021 at 5:48 AM Jeffrey Bouquet < > jbt...@iherebuywisely.com> > > wrote: > > > > > Apologies if this applies to STABLE 13, but git is involved... > > > buildworld is failing 4 minutes or so in. > > > would it be useful to re-git the /usr/src? > > > Is there a way to run "make buildworld" for a LESS terse error result? > > > Any other 3rd method to debug the error? > > > > > > > .. > > > /usr/local/bin/clang12 . -o machdep_ldisx.o > > > In file included from /usr/src/lib/libc/gdtoa/machdep_ldisx.c:45: > > > In file included from /usr/src/contrib/gdtoa/gdtoaimp.h:202: > > > In file included from /usr/src/include/pthread.h:49: > > > /usr/src/include/time.h: fatal error: 'sys/_clock_id.h' file not found > > > #include > > > > . > > > I also suspect the missing file might be a malformed missing > > > symlink instead... because the file exists at least once. > > > The error does not indicate from what [ 2nd ] subdir it, or a symlink, > is > > > missing ?? > > > > > > src.conf has several lines such as WITHOUT_CPP=yes, meant I think > > > to reduce build times if that matters. > > > > > > It likely does. It likely means that that file wasn't properly staged and > > so the build is failing. > > > > I'd bisect the file of omissions to see if that's the cause. I'd start by > > removing them all > > and seeing if the problem persists. Not all combinations are supported, > nor > > are > > the vast majority of all bad combinations detected with a nice error > > message. > > > > Warner > > > Same error with the file removed. Next step remove /usr/src and re-git I Try 'git reset --hard'. That will give you a clean tree. Also, what does git status say? >
Re: buildworld question.
On Thu, 11 Nov 2021 08:53:47 -0700, Warner Losh wrote: > On Thu, Nov 11, 2021 at 5:48 AM Jeffrey Bouquet > wrote: > > > Apologies if this applies to STABLE 13, but git is involved... > > buildworld is failing 4 minutes or so in. > > would it be useful to re-git the /usr/src? > > Is there a way to run "make buildworld" for a LESS terse error result? > > Any other 3rd method to debug the error? > > > > .. > > /usr/local/bin/clang12 . -o machdep_ldisx.o > > In file included from /usr/src/lib/libc/gdtoa/machdep_ldisx.c:45: > > In file included from /usr/src/contrib/gdtoa/gdtoaimp.h:202: > > In file included from /usr/src/include/pthread.h:49: > > /usr/src/include/time.h: fatal error: 'sys/_clock_id.h' file not found > > #include > > . > > I also suspect the missing file might be a malformed missing > > symlink instead... because the file exists at least once. > > The error does not indicate from what [ 2nd ] subdir it, or a symlink, is > > missing ?? > > > > src.conf has several lines such as WITHOUT_CPP=yes, meant I think > > to reduce build times if that matters. > > > It likely does. It likely means that that file wasn't properly staged and > so the build is failing. > > I'd bisect the file of omissions to see if that's the cause. I'd start by > removing them all > and seeing if the problem persists. Not all combinations are supported, nor > are > the vast majority of all bad combinations detected with a nice error > message. > > Warner Same error with the file removed. Next step remove /usr/src and re-git I think.
Re: buildworld question.
On Thu, Nov 11, 2021 at 5:48 AM Jeffrey Bouquet wrote: > Apologies if this applies to STABLE 13, but git is involved... > buildworld is failing 4 minutes or so in. > would it be useful to re-git the /usr/src? > Is there a way to run "make buildworld" for a LESS terse error result? > Any other 3rd method to debug the error? > > .. > /usr/local/bin/clang12 . -o machdep_ldisx.o > In file included from /usr/src/lib/libc/gdtoa/machdep_ldisx.c:45: > In file included from /usr/src/contrib/gdtoa/gdtoaimp.h:202: > In file included from /usr/src/include/pthread.h:49: > /usr/src/include/time.h: fatal error: 'sys/_clock_id.h' file not found > #include > . > I also suspect the missing file might be a malformed missing > symlink instead... because the file exists at least once. > The error does not indicate from what [ 2nd ] subdir it, or a symlink, is > missing ?? > > src.conf has several lines such as WITHOUT_CPP=yes, meant I think > to reduce build times if that matters. It likely does. It likely means that that file wasn't properly staged and so the build is failing. I'd bisect the file of omissions to see if that's the cause. I'd start by removing them all and seeing if the problem persists. Not all combinations are supported, nor are the vast majority of all bad combinations detected with a nice error message. Warner
Re: buildworld fails ( stopped in /usr/src/lib/libsysdecode )
On 30/11/2020 16:03, Michal Meloun wrote: On 30.11.2020 13:11, Johan Hendriks wrote: On 30/11/2020 12:29, Hans Petter Selasky wrote: On 11/30/20 11:43 AM, Johan Hendriks wrote: My server running FreeBSD 13.0-CURRENT #7 r368110 fails to build to r368182 I did a make cleanworld && make cleanworld to make sure i use a fresh build but it errors out with the following message. This is a known issue and will be fixed. --HPS Thank you for the conformation. And thank you all for your work on FreeBSD. regards Johan Fixed in r368187. Sorry for troubles. Michal Thank you, no problem and no need for a sorry! ___ 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: buildworld fails ( stopped in /usr/src/lib/libsysdecode )
On 30.11.2020 13:11, Johan Hendriks wrote: On 30/11/2020 12:29, Hans Petter Selasky wrote: On 11/30/20 11:43 AM, Johan Hendriks wrote: My server running FreeBSD 13.0-CURRENT #7 r368110 fails to build to r368182 I did a make cleanworld && make cleanworld to make sure i use a fresh build but it errors out with the following message. This is a known issue and will be fixed. --HPS Thank you for the conformation. And thank you all for your work on FreeBSD. regards Johan Fixed in r368187. Sorry for troubles. Michal ___ 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: buildworld fails ( stopped in /usr/src/lib/libsysdecode )
On 30/11/2020 12:29, Hans Petter Selasky wrote: On 11/30/20 11:43 AM, Johan Hendriks wrote: My server running FreeBSD 13.0-CURRENT #7 r368110 fails to build to r368182 I did a make cleanworld && make cleanworld to make sure i use a fresh build but it errors out with the following message. This is a known issue and will be fixed. --HPS Thank you for the conformation. And thank you all for your work on FreeBSD. regards Johan ___ 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: buildworld fails ( stopped in /usr/src/lib/libsysdecode )
On 11/30/20 11:43 AM, Johan Hendriks wrote: My server running FreeBSD 13.0-CURRENT #7 r368110 fails to build to r368182 I did a make cleanworld && make cleanworld to make sure i use a fresh build but it errors out with the following message. This is a known issue and will be fixed. --HPS ___ 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: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71
On 22/11/2020 18:06, Kyle Evans wrote:
> On Sun, Nov 22, 2020 at 6:00 AM Dimitry Andric wrote:
>> I'd guess it's an unintended side-effect of
>> https://svnweb.freebsd.org/base?view=revision&revision=366697
>> ("install(1): Avoid unncessary fstatfs() calls and use mmap() based on
>> size").
>>
>
> Almost certainly -- before, we would never attempt to mmap() on ZFS.
>
> Tossing arichardson@ into CC as the committer
> Tossing mmacy@ and freqlabs@ into CC as ZFS folks
>
> Looking through sys/contrib/openzfs, there's special handling for mmap
> on linux because it bypasses the page cache and relies on caching in
> ARC. AFAICT the FreeBSD side seems to handle write() to mmap'd
> regions, but doesn't do anything with VOP_MMAPPED which might be
> needed to sync the file when it's mmap'd for reading like this. My
> understanding of how this is supposed to actually work on FreeBSD is
> limited, though, so I defer...
Last time I checked mmap worked correctly with ZFS, that was before the switch.
Perhaps, there was an undetected issue -- this can be tested, e.g., by applying
the install change to stable/12.
Perhaps, the ZFS switch came with a regression.
--
Andriy Gapon
___
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: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71
On Sun, 22 Nov 2020 at 16:06, Kyle Evans wrote:
>
> On Sun, Nov 22, 2020 at 6:00 AM Dimitry Andric wrote:
> >
> > On 22 Nov 2020, at 08:06, Graham Perrin wrote:
> > >
> > > On 20/11/2020 09:57, Graham Perrin wrote:
> > >> On 16/11/2020 09:27, Graham Perrin wrote:
> > >>> Attempting to build r367615 on Friday 13th:
> > >>>
> > >>> …
> > >>>
> > >>> ===> lib/libprocstat/zfs (install)
> > >>> install -U -C -o root -g wheel -m 444
> > >>> /usr/src/lib/libprocstat/libprocstat.h
> > >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/include/
> > >>> ===> lib/libc (obj,all,install)
> > >>> install -U -C -o root -g wheel -m 444 libc.a
> > >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/
> > >>> install -U -s -o root -g wheel -m 444 -S libc.so.7
> > >>> /usr/obj/usr/src/amd64.amd64/tmp/lib/
> > >>> install -U -o root -g wheel -m 444libc.so.7.debug
> > >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/
> > >>> install: short write to
> > >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug:
> > >>> 393216 bytes written, 7462472 bytes asked to write
> > >>> *** [_libinstall] Error code 71
> > >>>
> > >>> make[4]: stopped in /usr/src/lib/libc
> > >>> 1 error
> > >>>
> > >>> make[4]: stopped in /usr/src/lib/libc
> > >>> root@mowa219-gjp4-8570p:/usr/src #
> > >>
> > >> The same problem – short write to
> > >> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug –
> > >> when attempting buildworld of r367847.
> > >>
> > >> If it's relevant: I'm using r367081 for these attempts.
> > >
> > > The same problem when attempting buildworld of r367923. Prior to this I
> > > performed a fresh checkout of /usr/src
> > >
> > > What might cause these failures?
> > >
> > > If it's relevant: I have compression set to gzip-9 for the ZFS dataset
> > > that mounts at /usr
> >
> > I'd guess it's an unintended side-effect of
> > https://svnweb.freebsd.org/base?view=revision&revision=366697
> > ("install(1): Avoid unncessary fstatfs() calls and use mmap() based on
> > size").
> >
>
> Almost certainly -- before, we would never attempt to mmap() on ZFS.
>
> Tossing arichardson@ into CC as the committer
> Tossing mmacy@ and freqlabs@ into CC as ZFS folks
>
> Looking through sys/contrib/openzfs, there's special handling for mmap
> on linux because it bypasses the page cache and relies on caching in
> ARC. AFAICT the FreeBSD side seems to handle write() to mmap'd
> regions, but doesn't do anything with VOP_MMAPPED which might be
> needed to sync the file when it's mmap'd for reading like this. My
> understanding of how this is supposed to actually work on FreeBSD is
> limited, though, so I defer...
>
I'm quite surprised by this, I simply re-used the logic that bin/cp also has.
However, it's possible that this is no longer used in cp due to copy_file_range?
To be honest I'm not sure whether mmap() even improves performance
compared to read/write since the all the MMU setup might be quite
expensive and the data might not even be available so we end up
copying anyway. Maybe we should change install to use read/write
unconditionally? It might also make sense to factor out the
copy_file_range+read/write fallback logic in bin/cp to a library that
can be used in usr.bin/install.
Alex
___
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: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71
On Sun, Nov 22, 2020 at 6:00 AM Dimitry Andric wrote:
>
> On 22 Nov 2020, at 08:06, Graham Perrin wrote:
> >
> > On 20/11/2020 09:57, Graham Perrin wrote:
> >> On 16/11/2020 09:27, Graham Perrin wrote:
> >>> Attempting to build r367615 on Friday 13th:
> >>>
> >>> …
> >>>
> >>> ===> lib/libprocstat/zfs (install)
> >>> install -U -C -o root -g wheel -m 444
> >>> /usr/src/lib/libprocstat/libprocstat.h
> >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/include/
> >>> ===> lib/libc (obj,all,install)
> >>> install -U -C -o root -g wheel -m 444 libc.a
> >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/
> >>> install -U -s -o root -g wheel -m 444 -S libc.so.7
> >>> /usr/obj/usr/src/amd64.amd64/tmp/lib/
> >>> install -U -o root -g wheel -m 444libc.so.7.debug
> >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/
> >>> install: short write to
> >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug:
> >>> 393216 bytes written, 7462472 bytes asked to write
> >>> *** [_libinstall] Error code 71
> >>>
> >>> make[4]: stopped in /usr/src/lib/libc
> >>> 1 error
> >>>
> >>> make[4]: stopped in /usr/src/lib/libc
> >>> root@mowa219-gjp4-8570p:/usr/src #
> >>
> >> The same problem – short write to
> >> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug – when
> >> attempting buildworld of r367847.
> >>
> >> If it's relevant: I'm using r367081 for these attempts.
> >
> > The same problem when attempting buildworld of r367923. Prior to this I
> > performed a fresh checkout of /usr/src
> >
> > What might cause these failures?
> >
> > If it's relevant: I have compression set to gzip-9 for the ZFS dataset that
> > mounts at /usr
>
> I'd guess it's an unintended side-effect of
> https://svnweb.freebsd.org/base?view=revision&revision=366697
> ("install(1): Avoid unncessary fstatfs() calls and use mmap() based on
> size").
>
Almost certainly -- before, we would never attempt to mmap() on ZFS.
Tossing arichardson@ into CC as the committer
Tossing mmacy@ and freqlabs@ into CC as ZFS folks
Looking through sys/contrib/openzfs, there's special handling for mmap
on linux because it bypasses the page cache and relies on caching in
ARC. AFAICT the FreeBSD side seems to handle write() to mmap'd
regions, but doesn't do anything with VOP_MMAPPED which might be
needed to sync the file when it's mmap'd for reading like this. My
understanding of how this is supposed to actually work on FreeBSD is
limited, though, so I defer...
Thanks,
Kyle Evans
___
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: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71
On 22 Nov 2020, at 08:06, Graham Perrin wrote:
>
> On 20/11/2020 09:57, Graham Perrin wrote:
>> On 16/11/2020 09:27, Graham Perrin wrote:
>>> Attempting to build r367615 on Friday 13th:
>>>
>>> …
>>>
>>> ===> lib/libprocstat/zfs (install)
>>> install -U -C -o root -g wheel -m 444
>>> /usr/src/lib/libprocstat/libprocstat.h
>>> /usr/obj/usr/src/amd64.amd64/tmp/usr/include/
>>> ===> lib/libc (obj,all,install)
>>> install -U -C -o root -g wheel -m 444 libc.a
>>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/
>>> install -U -s -o root -g wheel -m 444 -S libc.so.7
>>> /usr/obj/usr/src/amd64.amd64/tmp/lib/
>>> install -U -o root -g wheel -m 444libc.so.7.debug
>>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/
>>> install: short write to
>>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug: 393216
>>> bytes written, 7462472 bytes asked to write
>>> *** [_libinstall] Error code 71
>>>
>>> make[4]: stopped in /usr/src/lib/libc
>>> 1 error
>>>
>>> make[4]: stopped in /usr/src/lib/libc
>>> root@mowa219-gjp4-8570p:/usr/src #
>>
>> The same problem – short write to
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug – when
>> attempting buildworld of r367847.
>>
>> If it's relevant: I'm using r367081 for these attempts.
>
> The same problem when attempting buildworld of r367923. Prior to this I
> performed a fresh checkout of /usr/src
>
> What might cause these failures?
>
> If it's relevant: I have compression set to gzip-9 for the ZFS dataset that
> mounts at /usr
I'd guess it's an unintended side-effect of
https://svnweb.freebsd.org/base?view=revision&revision=366697
("install(1): Avoid unncessary fstatfs() calls and use mmap() based on
size").
If you only revert usr.bin/xinstall to r366696, and then rebuild it,
does it still occur?
-Dimitry
signature.asc
Description: Message signed with OpenPGP
Re: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71
On 17/11/2020 00:39, Konstantin Belousov wrote: On Mon, Nov 16, 2020 at 10:56:06AM +, Graham Perrin wrote: On 16/11/2020 09:32, Benjamin Kaduk wrote: On Mon, Nov 16, 2020 at 09:27:29AM +, Graham Perrin wrote: Attempting to build r367615 on Friday 13th: … ===> lib/libprocstat/zfs (install) install -U -C -o root -g wheel -m 444 /usr/src/lib/libprocstat/libprocstat.h /usr/obj/usr/src/amd64.amd64/tmp/usr/include/ ===> lib/libc (obj,all,install) install -U -C -o root -g wheel -m 444 libc.a /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/ install -U -s -o root -g wheel -m 444 -S libc.so.7 /usr/obj/usr/src/amd64.amd64/tmp/lib/ install -U -o root -g wheel -m 444 libc.so.7.debug /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/ install: short write to /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug: 393216 bytes written, 7462472 bytes asked to write *** [_libinstall] Error code 71 Is your disk/filesystem full? -Ben AVAIL: 204G And what is the type of filesystem you are _installing_ to ? Also what is the type of filesystem for /tmp, and how much space do you have there ? root@mowa219-gjp4-8570p:~ # zfs get available,compression copperbowl/tmp copperbowl/usr NAME PROPERTY VALUE SOURCE copperbowl/tmp available 221G - copperbowl/tmp compression off local copperbowl/usr available 221G - copperbowl/usr compression gzip-9 local root@mowa219-gjp4-8570p:~ # zfs list NAME USED AVAIL REFER MOUNTPOINT copperbowl 213G 221G 88K /copperbowl copperbowl/ROOT 97.5G 221G 88K none copperbowl/ROOT/Waterfox 348M 221G 59.3G / copperbowl/ROOT/r367081e 1.61M 221G 38.0G / copperbowl/ROOT/r367081f 97.2G 221G 39.2G / copperbowl/VirtualBox 288K 221G 288K /usr/local/VirtualBox copperbowl/iocage 4.35G 221G 3.68M /copperbowl/iocage copperbowl/iocage/download 359M 221G 88K /copperbowl/iocage/download copperbowl/iocage/download/12.0-RELEASE 359M 221G 359M /copperbowl/iocage/download/12.0-RELEASE copperbowl/iocage/images 88K 221G 88K /copperbowl/iocage/images copperbowl/iocage/jails 2.75G 221G 88K /copperbowl/iocage/jails copperbowl/iocage/jails/jbrowsers 2.75G 221G 92K /copperbowl/iocage/jails/jbrowsers copperbowl/iocage/jails/jbrowsers/root 2.75G 221G 3.99G /copperbowl/iocage/jails/jbrowsers/root copperbowl/iocage/log 100K 221G 100K /copperbowl/iocage/log copperbowl/iocage/releases 1.24G 221G 88K /copperbowl/iocage/releases copperbowl/iocage/releases/12.0-RELEASE 1.24G 221G 88K /copperbowl/iocage/releases/12.0-RELEASE copperbowl/iocage/releases/12.0-RELEASE/root 1.24G 221G 1.24G /copperbowl/iocage/releases/12.0-RELEASE/root copperbowl/iocage/templates 88K 221G 88K /copperbowl/iocage/templates copperbowl/poudriere 35.9G 221G 88K /copperbowl/poudriere copperbowl/poudriere/data 1.73G 221G 96K /usr/local/poudriere/data copperbowl/poudriere/data/.m 88K 221G 88K /usr/local/poudriere/data/.m copperbowl/poudriere/data/cache 224K 221G 224K /usr/local/poudriere/data/cache copperbowl/poudriere/data/logs 1.71G 221G 1.71G /usr/local/poudriere/data/logs copperbowl/poudriere/data/packages 24.3M 221G 24.3M /usr/local/poudriere/data/packages copperbowl/poudriere/data/wrkdirs 88K 221G 88K /usr/local/poudriere/data/wrkdirs copperbowl/poudriere/jails 2.05G 221G 88K /copperbowl/poudriere/jails copperbowl/poudriere/jails/head 2.05G 221G 2.05G /usr/local/poudriere/jails/head copperbowl/poudriere/ports 32.1G 221G 88K /copperbowl/poudriere/ports copperbowl/poudriere/ports/default 32.1G 221G 32.1G /usr/local/poudriere/ports/default copperbowl/tmp 808K 221G 808K /tmp copperbowl/usr 70.4G 221G 88K /usr copperbowl/usr/home 67.5G 221G 61.9G /usr/home copperbowl/usr/ports 1.83G 221G 1.83G /usr/ports copperbowl/usr/src 1.06G 221G 1.06G /usr/src copperbowl/var 4.14G 221G 88K /var copperbowl/var/audit 88K 221G 88K /var/audit copperbowl/var/crash 3.81G 221G 3.81G /var/crash copperbowl/var/log 15.7M 221G 15.7M /var/log copperbowl/var/mail 136K 221G 136K /var/mail copperbowl/var/tmp
Re: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71
On 20/11/2020 09:57, Graham Perrin wrote: On 16/11/2020 09:27, Graham Perrin wrote: Attempting to build r367615 on Friday 13th: … ===> lib/libprocstat/zfs (install) install -U -C -o root -g wheel -m 444 /usr/src/lib/libprocstat/libprocstat.h /usr/obj/usr/src/amd64.amd64/tmp/usr/include/ ===> lib/libc (obj,all,install) install -U -C -o root -g wheel -m 444 libc.a /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/ install -U -s -o root -g wheel -m 444 -S libc.so.7 /usr/obj/usr/src/amd64.amd64/tmp/lib/ install -U -o root -g wheel -m 444 libc.so.7.debug /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/ install: short write to /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug: 393216 bytes written, 7462472 bytes asked to write *** [_libinstall] Error code 71 make[4]: stopped in /usr/src/lib/libc 1 error make[4]: stopped in /usr/src/lib/libc root@mowa219-gjp4-8570p:/usr/src # The same problem – short write to /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug – when attempting buildworld of r367847. If it's relevant: I'm using r367081 for these attempts. The same problem when attempting buildworld of r367923. Prior to this I performed a fresh checkout of /usr/src What might cause these failures? If it's relevant: I have compression set to gzip-9 for the ZFS dataset that mounts at /usr ___ 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: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71
On 16/11/2020 09:27, Graham Perrin wrote: Attempting to build r367615 on Friday 13th: … ===> lib/libprocstat/zfs (install) install -U -C -o root -g wheel -m 444 /usr/src/lib/libprocstat/libprocstat.h /usr/obj/usr/src/amd64.amd64/tmp/usr/include/ ===> lib/libc (obj,all,install) install -U -C -o root -g wheel -m 444 libc.a /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/ install -U -s -o root -g wheel -m 444 -S libc.so.7 /usr/obj/usr/src/amd64.amd64/tmp/lib/ install -U -o root -g wheel -m 444 libc.so.7.debug /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/ install: short write to /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug: 393216 bytes written, 7462472 bytes asked to write *** [_libinstall] Error code 71 make[4]: stopped in /usr/src/lib/libc 1 error make[4]: stopped in /usr/src/lib/libc root@mowa219-gjp4-8570p:/usr/src # The same problem – short write to /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug – when attempting buildworld of r367847. If it's relevant: I'm using r367081 for these attempts. ___ 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: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71
On Mon, Nov 16, 2020 at 10:56:06AM +, Graham Perrin wrote: > On 16/11/2020 09:32, Benjamin Kaduk wrote: > > On Mon, Nov 16, 2020 at 09:27:29AM +, Graham Perrin wrote: > > > Attempting to build r367615 on Friday 13th: > > > > > > … > > > > > > ===> lib/libprocstat/zfs (install) > > > install -U -C -o root -g wheel -m 444 > > > /usr/src/lib/libprocstat/libprocstat.h > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/ > > > ===> lib/libc (obj,all,install) > > > install -U -C -o root -g wheel -m 444 libc.a > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/ > > > install -U -s -o root -g wheel -m 444 -S libc.so.7 > > > /usr/obj/usr/src/amd64.amd64/tmp/lib/ > > > install -U -o root -g wheel -m 444 libc.so.7.debug > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/ > > > install: short write to > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug: > > > 393216 bytes written, 7462472 bytes asked to write > > > *** [_libinstall] Error code 71 > > Is your disk/filesystem full? > > > > -Ben > AVAIL: 204G And what is the type of filesystem you are _installing_ to ? Also what is the type of filesystem for /tmp, and how much space do you have there ? ___ 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: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71
On 16/11/2020 09:32, Benjamin Kaduk wrote: On Mon, Nov 16, 2020 at 09:27:29AM +, Graham Perrin wrote: Attempting to build r367615 on Friday 13th: … ===> lib/libprocstat/zfs (install) install -U -C -o root -g wheel -m 444 /usr/src/lib/libprocstat/libprocstat.h /usr/obj/usr/src/amd64.amd64/tmp/usr/include/ ===> lib/libc (obj,all,install) install -U -C -o root -g wheel -m 444 libc.a /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/ install -U -s -o root -g wheel -m 444 -S libc.so.7 /usr/obj/usr/src/amd64.amd64/tmp/lib/ install -U -o root -g wheel -m 444 libc.so.7.debug /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/ install: short write to /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug: 393216 bytes written, 7462472 bytes asked to write *** [_libinstall] Error code 71 Is your disk/filesystem full? -Ben AVAIL: 204G ___ 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: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71
On Mon, Nov 16, 2020 at 09:27:29AM +, Graham Perrin wrote: > Attempting to build r367615 on Friday 13th: > > … > > ===> lib/libprocstat/zfs (install) > install -U -C -o root -g wheel -m 444 > /usr/src/lib/libprocstat/libprocstat.h > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/ > ===> lib/libc (obj,all,install) > install -U -C -o root -g wheel -m 444 libc.a > /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/ > install -U -s -o root -g wheel -m 444 -S libc.so.7 > /usr/obj/usr/src/amd64.amd64/tmp/lib/ > install -U -o root -g wheel -m 444 libc.so.7.debug > /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/ > install: short write to > /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/debug/lib/libc.so.7.debug: > 393216 bytes written, 7462472 bytes asked to write > *** [_libinstall] Error code 71 Is your disk/filesystem full? -Ben ___ 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: buildworld: "cp: /dev/null: Invalid argument"
> On 12. Sep 2020, at 11:06, Hartmann, O. wrote: > > On Sat, 12 Sep 2020 10:03:18 +0200 > Michael Gmelin wrote: > >>> On 12. Sep 2020, at 09:55, Hartmann, O. >>> wrote: >>> On Fri, 11 Sep 2020 07:18:33 -0600 >>> Alan Somers wrote: > On Fri, Sep 11, 2020 at 1:57 AM O. Hartmann > wrote: > On Thu, 10 Sep 2020 10:44:08 -0600 > Alan Somers wrote: >> No, it's devfs. I'll fix it. >> On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone >> wrote: >>> I'm curious: does this give a similar issue? >>> touch /tmp/foo >>> cp /tmp/foo /tmo/foo2 >>> I'm wondering if the issue is that copy_file_range isn't >>> handling empty files, or if it's a devfs issue. >>> On Thu, Sep 10, 2020 at 11:45 AM Michael Butler >>> wrote: It seems that SVN r365549 broke "cp /dev/null ..." imb >> On 9/10/20 10:35 AM, Michael Butler wrote: >>> Is anyone else seeing failures like this in building world >>> and, in >>> my >>> case, cron jobs as well? >>> Building >>> /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr >>> --- all_subdir_sbin --- >>> Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel >>> --- all_subdir_stand --- >>> --- zfsboot.ldr --- >>> cp: /dev/null: Invalid argument >>> *** [zfsboot.ldr] Error code 1 >>> make[5]: *** zfsboot.ldr removed >>> --- all_subdir_kerberos5 --- >>> Building > /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log >>> --- all_subdir_stand --- >>> make[5]: stopped in /usr/src/stand/i386/zfsboot >>> .ERROR_TARGET='zfsboot.ldr' >>> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' >>> .MAKE.LEVEL='5' >>> MAKEFILE='' >>> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes >>> silent=yes > verbose' >>> _ERROR_CMD='cp /dev/null zfsboot.ldr;' >>> .CURDIR='/usr/src/stand/i386/zfsboot' >>> .MAKE='make' >>> .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' >>> .TARGETS='all' >>> DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' >>> LD_LIBRARY_PATH='' >>> MACHINE='amd64' >>> MACHINE_ARCH='amd64' >>> MAKEOBJDIRPREFIX='' >>> MAKESYSPATH='/usr/src/share/mk' >>> MAKE_VERSION='20200902' >>> ___ >>> 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" >> ___ >> 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" ___ 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" >>> I still get this error on a couple of boxes, while others seem to >>> buildworld >>> fine. All boxes are at CURRENT revision 365625. It is a bit >>> looking weird to >>> me. Running now a make cleanworld/cleandir on the specific boxes >>> and start building OS again. >>> oh >> I don't know why it's intermittent, but in any case this patch >> should fix it: >> https://reviews.freebsd.org/D26395 >> -Alan I checked on ALL CURRENT boxes. After "make cleanworld cleandir" (or just deleting usr/obj/) and starting a fresh build, those boxes with an newer kernel all fail at the very same point. We use META_MODE on some boxes, switched to WITHOUT_CLEAN these days and cleanded up on some systems therefore. That might be the reason why the problem occurs not consistently on all systems. When will the pacth be committed? >> Alan already committed it: >> https://svnweb.freebsd.org/base?view=revision&revision=365643 >> -m >>> Thanks in advance, >>> oh >> ___ >> 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" > > Sources at: > > At revision 365652. > > Host is running kernel FreeBSD 13.0-CURRENT #20 r365382: Fri Sep 11 > 19:01:26 CEST 2020 amd64. > > make -j4 buildworld buildkernel > > quit with same error as shown below. > > Is there anything that has to prepared before to successfully apply and > run this patch? Well, you have a broken cp binary on your system, which makes the build
Re: buildworld: "cp: /dev/null: Invalid argument"
Am 12.09.20 um 11:05 schrieb Hartmann, O.: > On Sat, 12 Sep 2020 10:03:18 +0200 > Michael Gmelin wrote: > >>> On 12. Sep 2020, at 09:55, Hartmann, O. >>> wrote: >>> >>> On Fri, 11 Sep 2020 07:18:33 -0600 >>> Alan Somers wrote: >>> > On Fri, Sep 11, 2020 at 1:57 AM O. Hartmann > wrote: > > On Thu, 10 Sep 2020 10:44:08 -0600 > Alan Somers wrote: > >> No, it's devfs. I'll fix it. >> >> On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone >> wrote: >>> I'm curious: does this give a similar issue? >>> >>> touch /tmp/foo >>> cp /tmp/foo /tmo/foo2 >>> >>> I'm wondering if the issue is that copy_file_range isn't >>> handling empty files, or if it's a devfs issue. >>> >>> >>> On Thu, Sep 10, 2020 at 11:45 AM Michael Butler >>> wrote: It seems that SVN r365549 broke "cp /dev/null ..." imb On 9/10/20 10:35 AM, Michael Butler wrote: > Is anyone else seeing failures like this in building world > and, in > my > case, cron jobs as well? > > > Building > /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr > --- all_subdir_sbin --- > Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel > --- all_subdir_stand --- > --- zfsboot.ldr --- > cp: /dev/null: Invalid argument > *** [zfsboot.ldr] Error code 1 > make[5]: *** zfsboot.ldr removed > --- all_subdir_kerberos5 --- > Building >>> /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log >>> > --- all_subdir_stand --- > > make[5]: stopped in /usr/src/stand/i386/zfsboot > .ERROR_TARGET='zfsboot.ldr' > >>> > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' > >>> > .MAKE.LEVEL='5' > MAKEFILE='' > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes > silent=yes >>> verbose' > _ERROR_CMD='cp /dev/null zfsboot.ldr;' > .CURDIR='/usr/src/stand/i386/zfsboot' > .MAKE='make' > .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' > .TARGETS='all' > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > LD_LIBRARY_PATH='' > MACHINE='amd64' > MACHINE_ARCH='amd64' > MAKEOBJDIRPREFIX='' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20200902' > > ___ > 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" ___ 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" >>> >> ___ >> 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" > > I still get this error on a couple of boxes, while others seem to > buildworld > fine. All boxes are at CURRENT revision 365625. It is a bit > looking weird to > me. Running now a make cleanworld/cleandir on the specific boxes > and start building OS again. > > oh > I don't know why it's intermittent, but in any case this patch should fix it: https://reviews.freebsd.org/D26395 -Alan >>> >>> I checked on ALL CURRENT boxes. After "make cleanworld cleandir" (or >>> just deleting usr/obj/) and starting a fresh build, those boxes >>> with an newer kernel all fail at the very same point. We use >>> META_MODE on some boxes, switched to WITHOUT_CLEAN these days and >>> cleanded up on some systems therefore. That might be the reason why >>> the problem occurs not consistently on all systems. >>> >>> When will the pacth be committed? >>> >> >> Alan already committed it: >> >> https://svnweb.freebsd.org/base?view=revision&revision=365643 >> >> -m >> >>> Thanks in advance, >>> >>> oh >> ___ >> 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" > > Sources at: > > At revision 365652. > > Host is running kernel FreeBSD 13.0-CURRENT #20 r365382: Fri Sep 11 > 19:01:26 CEST 2020 amd64. > > make -j4 buildworld buildkernel > > quit with same error as shown below. > > Is there anything that has to prepa
Re: buildworld: "cp: /dev/null: Invalid argument"
On Sat, 12 Sep 2020 10:03:18 +0200 Michael Gmelin wrote: > > On 12. Sep 2020, at 09:55, Hartmann, O. > > wrote: > > > > On Fri, 11 Sep 2020 07:18:33 -0600 > > Alan Somers wrote: > > > >>> On Fri, Sep 11, 2020 at 1:57 AM O. Hartmann > >>> wrote: > >>> > >>> On Thu, 10 Sep 2020 10:44:08 -0600 > >>> Alan Somers wrote: > >>> > No, it's devfs. I'll fix it. > > On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone > wrote: > > I'm curious: does this give a similar issue? > > > > touch /tmp/foo > > cp /tmp/foo /tmo/foo2 > > > > I'm wondering if the issue is that copy_file_range isn't > > handling empty files, or if it's a devfs issue. > > > > > > On Thu, Sep 10, 2020 at 11:45 AM Michael Butler > > wrote: > >> > >> It seems that SVN r365549 broke "cp /dev/null ..." > >> > >>imb > >> > >> On 9/10/20 10:35 AM, Michael Butler wrote: > >>> Is anyone else seeing failures like this in building world > >>> and, in > >>> my > >>> case, cron jobs as well? > >>> > >>> > >>> Building > >>> /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr > >>> --- all_subdir_sbin --- > >>> Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel > >>> --- all_subdir_stand --- > >>> --- zfsboot.ldr --- > >>> cp: /dev/null: Invalid argument > >>> *** [zfsboot.ldr] Error code 1 > >>> make[5]: *** zfsboot.ldr removed > >>> --- all_subdir_kerberos5 --- > >>> Building > > /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log > > > >>> --- all_subdir_stand --- > >>> > >>> make[5]: stopped in /usr/src/stand/i386/zfsboot > >>> .ERROR_TARGET='zfsboot.ldr' > >>> > > > >>> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' > >>> > > > >>> .MAKE.LEVEL='5' > >>> MAKEFILE='' > >>> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes > >>> silent=yes > > verbose' > >>> _ERROR_CMD='cp /dev/null zfsboot.ldr;' > >>> .CURDIR='/usr/src/stand/i386/zfsboot' > >>> .MAKE='make' > >>> .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' > >>> .TARGETS='all' > >>> DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > >>> LD_LIBRARY_PATH='' > >>> MACHINE='amd64' > >>> MACHINE_ARCH='amd64' > >>> MAKEOBJDIRPREFIX='' > >>> MAKESYSPATH='/usr/src/share/mk' > >>> MAKE_VERSION='20200902' > >>> > >>> ___ > >>> 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" > >> > >> > >> ___ > >> 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" > > > ___ > 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" > >>> > >>> I still get this error on a couple of boxes, while others seem to > >>> buildworld > >>> fine. All boxes are at CURRENT revision 365625. It is a bit > >>> looking weird to > >>> me. Running now a make cleanworld/cleandir on the specific boxes > >>> and start building OS again. > >>> > >>> oh > >>> > >> > >> I don't know why it's intermittent, but in any case this patch > >> should fix it: > >> https://reviews.freebsd.org/D26395 > >> -Alan > > > > I checked on ALL CURRENT boxes. After "make cleanworld cleandir" (or > > just deleting usr/obj/) and starting a fresh build, those boxes > > with an newer kernel all fail at the very same point. We use > > META_MODE on some boxes, switched to WITHOUT_CLEAN these days and > > cleanded up on some systems therefore. That might be the reason why > > the problem occurs not consistently on all systems. > > > > When will the pacth be committed? > > > > Alan already committed it: > > https://svnweb.freebsd.org/base?view=revision&revision=365643 > > -m > > > Thanks in advance, > > > > oh > ___ > 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" Sources at: At revision 365652. Host is running kernel FreeBSD 13.0-CURRENT #20 r365382: Fri Sep 11 19:01:26 CEST 2020 amd64. make -j4 buildworld buildkernel quit with same error as shown below. Is there anything that has to prepared before to successfully apply and run this patch? [...] -
Re: buildworld: "cp: /dev/null: Invalid argument"
> On 12. Sep 2020, at 09:55, Hartmann, O. wrote: > > On Fri, 11 Sep 2020 07:18:33 -0600 > Alan Somers wrote: > >>> On Fri, Sep 11, 2020 at 1:57 AM O. Hartmann >>> wrote: >>> >>> On Thu, 10 Sep 2020 10:44:08 -0600 >>> Alan Somers wrote: >>> No, it's devfs. I'll fix it. On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone wrote: > I'm curious: does this give a similar issue? > > touch /tmp/foo > cp /tmp/foo /tmo/foo2 > > I'm wondering if the issue is that copy_file_range isn't > handling empty files, or if it's a devfs issue. > > > On Thu, Sep 10, 2020 at 11:45 AM Michael Butler > wrote: >> >> It seems that SVN r365549 broke "cp /dev/null ..." >> >>imb >> >> On 9/10/20 10:35 AM, Michael Butler wrote: >>> Is anyone else seeing failures like this in building world >>> and, in >>> my >>> case, cron jobs as well? >>> >>> >>> Building >>> /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr >>> --- all_subdir_sbin --- >>> Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel >>> --- all_subdir_stand --- >>> --- zfsboot.ldr --- >>> cp: /dev/null: Invalid argument >>> *** [zfsboot.ldr] Error code 1 >>> make[5]: *** zfsboot.ldr removed >>> --- all_subdir_kerberos5 --- >>> Building > /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log > >>> --- all_subdir_stand --- >>> >>> make[5]: stopped in /usr/src/stand/i386/zfsboot >>> .ERROR_TARGET='zfsboot.ldr' >>> > >>> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' >>> > >>> .MAKE.LEVEL='5' >>> MAKEFILE='' >>> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes >>> silent=yes > verbose' >>> _ERROR_CMD='cp /dev/null zfsboot.ldr;' >>> .CURDIR='/usr/src/stand/i386/zfsboot' >>> .MAKE='make' >>> .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' >>> .TARGETS='all' >>> DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' >>> LD_LIBRARY_PATH='' >>> MACHINE='amd64' >>> MACHINE_ARCH='amd64' >>> MAKEOBJDIRPREFIX='' >>> MAKESYSPATH='/usr/src/share/mk' >>> MAKE_VERSION='20200902' >>> >>> ___ >>> 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" >> >> >> ___ >> 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" > ___ 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" >>> >>> I still get this error on a couple of boxes, while others seem to >>> buildworld >>> fine. All boxes are at CURRENT revision 365625. It is a bit looking >>> weird to >>> me. Running now a make cleanworld/cleandir on the specific boxes >>> and start building OS again. >>> >>> oh >>> >> >> I don't know why it's intermittent, but in any case this patch should >> fix it: >> https://reviews.freebsd.org/D26395 >> -Alan > > I checked on ALL CURRENT boxes. After "make cleanworld cleandir" (or > just deleting usr/obj/) and starting a fresh build, those boxes with an > newer kernel all fail at the very same point. We use META_MODE on some > boxes, switched to WITHOUT_CLEAN these days and cleanded up on some > systems therefore. That might be the reason why the problem occurs not > consistently on all systems. > > When will the pacth be committed? > Alan already committed it: https://svnweb.freebsd.org/base?view=revision&revision=365643 -m > Thanks in advance, > > oh ___ 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: buildworld: "cp: /dev/null: Invalid argument"
On Fri, 11 Sep 2020 07:18:33 -0600 Alan Somers wrote: > On Fri, Sep 11, 2020 at 1:57 AM O. Hartmann > wrote: > > > On Thu, 10 Sep 2020 10:44:08 -0600 > > Alan Somers wrote: > > > > > No, it's devfs. I'll fix it. > > > > > > On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone > > > wrote: > > > > I'm curious: does this give a similar issue? > > > > > > > > touch /tmp/foo > > > > cp /tmp/foo /tmo/foo2 > > > > > > > > I'm wondering if the issue is that copy_file_range isn't > > > > handling empty files, or if it's a devfs issue. > > > > > > > > > > > > On Thu, Sep 10, 2020 at 11:45 AM Michael Butler > > > > wrote: > > > > > > > > > > It seems that SVN r365549 broke "cp /dev/null ..." > > > > > > > > > > imb > > > > > > > > > > On 9/10/20 10:35 AM, Michael Butler wrote: > > > > > > Is anyone else seeing failures like this in building world > > > > > > and, in > > my > > > > > > case, cron jobs as well? > > > > > > > > > > > > > > > > > > Building > > /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr > > > > > > --- all_subdir_sbin --- > > > > > > Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel > > > > > > --- all_subdir_stand --- > > > > > > --- zfsboot.ldr --- > > > > > > cp: /dev/null: Invalid argument > > > > > > *** [zfsboot.ldr] Error code 1 > > > > > > make[5]: *** zfsboot.ldr removed > > > > > > --- all_subdir_kerberos5 --- > > > > > > Building > > > > /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log > > > > > > > > > > --- all_subdir_stand --- > > > > > > > > > > > > make[5]: stopped in /usr/src/stand/i386/zfsboot > > > > > > .ERROR_TARGET='zfsboot.ldr' > > > > > > > > > > > > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' > > > > > > > > > > > > .MAKE.LEVEL='5' > > > > > > MAKEFILE='' > > > > > > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes > > > > > > silent=yes > > > > verbose' > > > > > > _ERROR_CMD='cp /dev/null zfsboot.ldr;' > > > > > > .CURDIR='/usr/src/stand/i386/zfsboot' > > > > > > .MAKE='make' > > > > > > .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' > > > > > > .TARGETS='all' > > > > > > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > > > > > > LD_LIBRARY_PATH='' > > > > > > MACHINE='amd64' > > > > > > MACHINE_ARCH='amd64' > > > > > > MAKEOBJDIRPREFIX='' > > > > > > MAKESYSPATH='/usr/src/share/mk' > > > > > > MAKE_VERSION='20200902' > > > > > > > > > > > > ___ > > > > > > 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" > > > > > > > > > > > > > > > ___ > > > > > 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" > > > > > > > ___ > > > 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" > > > > I still get this error on a couple of boxes, while others seem to > > buildworld > > fine. All boxes are at CURRENT revision 365625. It is a bit looking > > weird to > > me. Running now a make cleanworld/cleandir on the specific boxes > > and start building OS again. > > > > oh > > > > I don't know why it's intermittent, but in any case this patch should > fix it: > https://reviews.freebsd.org/D26395 > -Alan I checked on ALL CURRENT boxes. After "make cleanworld cleandir" (or just deleting usr/obj/) and starting a fresh build, those boxes with an newer kernel all fail at the very same point. We use META_MODE on some boxes, switched to WITHOUT_CLEAN these days and cleanded up on some systems therefore. That might be the reason why the problem occurs not consistently on all systems. When will the pacth be committed? Thanks in advance, oh pgpQXGFivRDER.pgp Description: OpenPGP digital signature
Re: buildworld: "cp: /dev/null: Invalid argument"
On Fri, Sep 11, 2020 at 1:57 AM O. Hartmann wrote: > On Thu, 10 Sep 2020 10:44:08 -0600 > Alan Somers wrote: > > > No, it's devfs. I'll fix it. > > > > On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone wrote: > > > > > I'm curious: does this give a similar issue? > > > > > > touch /tmp/foo > > > cp /tmp/foo /tmo/foo2 > > > > > > I'm wondering if the issue is that copy_file_range isn't handling > > > empty files, or if it's a devfs issue. > > > > > > > > > On Thu, Sep 10, 2020 at 11:45 AM Michael Butler > > > wrote: > > > > > > > > It seems that SVN r365549 broke "cp /dev/null ..." > > > > > > > > imb > > > > > > > > On 9/10/20 10:35 AM, Michael Butler wrote: > > > > > Is anyone else seeing failures like this in building world and, in > my > > > > > case, cron jobs as well? > > > > > > > > > > > > > > > Building > /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr > > > > > --- all_subdir_sbin --- > > > > > Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel > > > > > --- all_subdir_stand --- > > > > > --- zfsboot.ldr --- > > > > > cp: /dev/null: Invalid argument > > > > > *** [zfsboot.ldr] Error code 1 > > > > > make[5]: *** zfsboot.ldr removed > > > > > --- all_subdir_kerberos5 --- > > > > > Building > > > /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log > > > > > --- all_subdir_stand --- > > > > > > > > > > make[5]: stopped in /usr/src/stand/i386/zfsboot > > > > > .ERROR_TARGET='zfsboot.ldr' > > > > > > > > > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' > > > > > > > > .MAKE.LEVEL='5' > > > > > MAKEFILE='' > > > > > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes > > > verbose' > > > > > _ERROR_CMD='cp /dev/null zfsboot.ldr;' > > > > > .CURDIR='/usr/src/stand/i386/zfsboot' > > > > > .MAKE='make' > > > > > .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' > > > > > .TARGETS='all' > > > > > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > > > > > LD_LIBRARY_PATH='' > > > > > MACHINE='amd64' > > > > > MACHINE_ARCH='amd64' > > > > > MAKEOBJDIRPREFIX='' > > > > > MAKESYSPATH='/usr/src/share/mk' > > > > > MAKE_VERSION='20200902' > > > > > > > > > > ___ > > > > > 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" > > > > > > > > > > > > ___ > > > > 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" > > > > > ___ > > 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" > > I still get this error on a couple of boxes, while others seem to > buildworld > fine. All boxes are at CURRENT revision 365625. It is a bit looking weird > to > me. Running now a make cleanworld/cleandir on the specific boxes and start > building OS again. > > oh > I don't know why it's intermittent, but in any case this patch should fix it: https://reviews.freebsd.org/D26395 -Alan ___ 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: buildworld: "cp: /dev/null: Invalid argument"
On Thu, 10 Sep 2020 10:44:08 -0600 Alan Somers wrote: > No, it's devfs. I'll fix it. > > On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone wrote: > > > I'm curious: does this give a similar issue? > > > > touch /tmp/foo > > cp /tmp/foo /tmo/foo2 > > > > I'm wondering if the issue is that copy_file_range isn't handling > > empty files, or if it's a devfs issue. > > > > > > On Thu, Sep 10, 2020 at 11:45 AM Michael Butler > > wrote: > > > > > > It seems that SVN r365549 broke "cp /dev/null ..." > > > > > > imb > > > > > > On 9/10/20 10:35 AM, Michael Butler wrote: > > > > Is anyone else seeing failures like this in building world and, in my > > > > case, cron jobs as well? > > > > > > > > > > > > Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr > > > > --- all_subdir_sbin --- > > > > Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel > > > > --- all_subdir_stand --- > > > > --- zfsboot.ldr --- > > > > cp: /dev/null: Invalid argument > > > > *** [zfsboot.ldr] Error code 1 > > > > make[5]: *** zfsboot.ldr removed > > > > --- all_subdir_kerberos5 --- > > > > Building > > /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log > > > > --- all_subdir_stand --- > > > > > > > > make[5]: stopped in /usr/src/stand/i386/zfsboot > > > > .ERROR_TARGET='zfsboot.ldr' > > > > > > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' > > > > > > .MAKE.LEVEL='5' > > > > MAKEFILE='' > > > > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes > > verbose' > > > > _ERROR_CMD='cp /dev/null zfsboot.ldr;' > > > > .CURDIR='/usr/src/stand/i386/zfsboot' > > > > .MAKE='make' > > > > .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' > > > > .TARGETS='all' > > > > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > > > > LD_LIBRARY_PATH='' > > > > MACHINE='amd64' > > > > MACHINE_ARCH='amd64' > > > > MAKEOBJDIRPREFIX='' > > > > MAKESYSPATH='/usr/src/share/mk' > > > > MAKE_VERSION='20200902' > > > > > > > > ___ > > > > 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" > > > > > > > > > ___ > > > 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" > > > ___ > 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" I still get this error on a couple of boxes, while others seem to buildworld fine. All boxes are at CURRENT revision 365625. It is a bit looking weird to me. Running now a make cleanworld/cleandir on the specific boxes and start building OS again. oh ___ 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: buildworld: "cp: /dev/null: Invalid argument"
On Thu, 10 Sep 2020 10:35:08 -0400 Michael Butler wrote: > Is anyone else seeing failures like this in building world and, in my > case, cron jobs as well? > > > Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr > --- all_subdir_sbin --- > Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel > --- all_subdir_stand --- > --- zfsboot.ldr --- > cp: /dev/null: Invalid argument > *** [zfsboot.ldr] Error code 1 > make[5]: *** zfsboot.ldr removed > --- all_subdir_kerberos5 --- > Building > /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log > --- all_subdir_stand --- > > make[5]: stopped in /usr/src/stand/i386/zfsboot > .ERROR_TARGET='zfsboot.ldr' > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' > .MAKE.LEVEL='5' > MAKEFILE='' > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes > verbose' _ERROR_CMD='cp /dev/null zfsboot.ldr;' > .CURDIR='/usr/src/stand/i386/zfsboot' > .MAKE='make' > .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' > .TARGETS='all' > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > LD_LIBRARY_PATH='' > MACHINE='amd64' > MACHINE_ARCH='amd64' > MAKEOBJDIRPREFIX='' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20200902' > > ___ > 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" Same here with revision 365625 Regards, oh pgpl5iD5CLlJ0.pgp Description: OpenPGP digital signature
Re: buildworld: "cp: /dev/null: Invalid argument"
On 9/10/20 12:17 PM, Ryan Stone wrote: > I'm curious: does this give a similar issue? > > touch /tmp/foo > cp /tmp/foo /tmo/foo2 > > I'm wondering if the issue is that copy_file_range isn't handling > empty files, or if it's a devfs issue. An empty file doesn't generate the error .. imb@vm01:/home/imb> touch xx imb@vm01:/home/imb> cp xx yy imb@vm01:/home/imb> imb@vm01:/home/imb> cp /dev/null yy cp: /dev/null: Invalid argument imb@vm01:/home/imb> > > On Thu, Sep 10, 2020 at 11:45 AM Michael Butler > wrote: >> It seems that SVN r365549 broke "cp /dev/null ..." >> >> imb >> >> On 9/10/20 10:35 AM, Michael Butler wrote: >>> Is anyone else seeing failures like this in building world and, in my >>> case, cron jobs as well? >>> >>> >>> Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr >>> --- all_subdir_sbin --- >>> Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel >>> --- all_subdir_stand --- >>> --- zfsboot.ldr --- >>> cp: /dev/null: Invalid argument >>> *** [zfsboot.ldr] Error code 1 >>> make[5]: *** zfsboot.ldr removed >>> --- all_subdir_kerberos5 --- >>> Building /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log >>> --- all_subdir_stand --- >>> >>> make[5]: stopped in /usr/src/stand/i386/zfsboot >>> .ERROR_TARGET='zfsboot.ldr' >>> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' >>> .MAKE.LEVEL='5' >>> MAKEFILE='' >>> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' >>> _ERROR_CMD='cp /dev/null zfsboot.ldr;' >>> .CURDIR='/usr/src/stand/i386/zfsboot' >>> .MAKE='make' >>> .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' >>> .TARGETS='all' >>> DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' >>> LD_LIBRARY_PATH='' >>> MACHINE='amd64' >>> MACHINE_ARCH='amd64' >>> MAKEOBJDIRPREFIX='' >>> MAKESYSPATH='/usr/src/share/mk' >>> MAKE_VERSION='20200902' >>> >>> ___ >>> 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" >> >> ___ >> 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" ___ 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: buildworld: "cp: /dev/null: Invalid argument"
It seems that SVN r365549 broke "cp /dev/null ..." imb On 9/10/20 10:35 AM, Michael Butler wrote: > Is anyone else seeing failures like this in building world and, in my > case, cron jobs as well? > > > Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr > --- all_subdir_sbin --- > Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel > --- all_subdir_stand --- > --- zfsboot.ldr --- > cp: /dev/null: Invalid argument > *** [zfsboot.ldr] Error code 1 > make[5]: *** zfsboot.ldr removed > --- all_subdir_kerberos5 --- > Building /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log > --- all_subdir_stand --- > > make[5]: stopped in /usr/src/stand/i386/zfsboot > .ERROR_TARGET='zfsboot.ldr' > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' > .MAKE.LEVEL='5' > MAKEFILE='' > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' > _ERROR_CMD='cp /dev/null zfsboot.ldr;' > .CURDIR='/usr/src/stand/i386/zfsboot' > .MAKE='make' > .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' > .TARGETS='all' > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > LD_LIBRARY_PATH='' > MACHINE='amd64' > MACHINE_ARCH='amd64' > MAKEOBJDIRPREFIX='' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20200902' > > ___ > 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" ___ 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: buildworld: "cp: /dev/null: Invalid argument"
No, it's devfs. I'll fix it. On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone wrote: > I'm curious: does this give a similar issue? > > touch /tmp/foo > cp /tmp/foo /tmo/foo2 > > I'm wondering if the issue is that copy_file_range isn't handling > empty files, or if it's a devfs issue. > > > On Thu, Sep 10, 2020 at 11:45 AM Michael Butler > wrote: > > > > It seems that SVN r365549 broke "cp /dev/null ..." > > > > imb > > > > On 9/10/20 10:35 AM, Michael Butler wrote: > > > Is anyone else seeing failures like this in building world and, in my > > > case, cron jobs as well? > > > > > > > > > Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr > > > --- all_subdir_sbin --- > > > Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel > > > --- all_subdir_stand --- > > > --- zfsboot.ldr --- > > > cp: /dev/null: Invalid argument > > > *** [zfsboot.ldr] Error code 1 > > > make[5]: *** zfsboot.ldr removed > > > --- all_subdir_kerberos5 --- > > > Building > /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log > > > --- all_subdir_stand --- > > > > > > make[5]: stopped in /usr/src/stand/i386/zfsboot > > > .ERROR_TARGET='zfsboot.ldr' > > > > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' > > > .MAKE.LEVEL='5' > > > MAKEFILE='' > > > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes > verbose' > > > _ERROR_CMD='cp /dev/null zfsboot.ldr;' > > > .CURDIR='/usr/src/stand/i386/zfsboot' > > > .MAKE='make' > > > .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' > > > .TARGETS='all' > > > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > > > LD_LIBRARY_PATH='' > > > MACHINE='amd64' > > > MACHINE_ARCH='amd64' > > > MAKEOBJDIRPREFIX='' > > > MAKESYSPATH='/usr/src/share/mk' > > > MAKE_VERSION='20200902' > > > > > > ___ > > > 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" > > > > > > ___ > > 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" > ___ 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: buildworld: "cp: /dev/null: Invalid argument"
I'm curious: does this give a similar issue? touch /tmp/foo cp /tmp/foo /tmo/foo2 I'm wondering if the issue is that copy_file_range isn't handling empty files, or if it's a devfs issue. On Thu, Sep 10, 2020 at 11:45 AM Michael Butler wrote: > > It seems that SVN r365549 broke "cp /dev/null ..." > > imb > > On 9/10/20 10:35 AM, Michael Butler wrote: > > Is anyone else seeing failures like this in building world and, in my > > case, cron jobs as well? > > > > > > Building /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr > > --- all_subdir_sbin --- > > Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel > > --- all_subdir_stand --- > > --- zfsboot.ldr --- > > cp: /dev/null: Invalid argument > > *** [zfsboot.ldr] Error code 1 > > make[5]: *** zfsboot.ldr removed > > --- all_subdir_kerberos5 --- > > Building /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log > > --- all_subdir_stand --- > > > > make[5]: stopped in /usr/src/stand/i386/zfsboot > > .ERROR_TARGET='zfsboot.ldr' > > .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta' > > .MAKE.LEVEL='5' > > MAKEFILE='' > > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' > > _ERROR_CMD='cp /dev/null zfsboot.ldr;' > > .CURDIR='/usr/src/stand/i386/zfsboot' > > .MAKE='make' > > .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot' > > .TARGETS='all' > > DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp' > > LD_LIBRARY_PATH='' > > MACHINE='amd64' > > MACHINE_ARCH='amd64' > > MAKEOBJDIRPREFIX='' > > MAKESYSPATH='/usr/src/share/mk' > > MAKE_VERSION='20200902' > > > > ___ > > 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" > > > ___ > 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" ___ 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: buildworld failed (usr.bin/kyua)
On 3/28/2020 4:29 AM, Brooks Davis wrote:
> On Fri, Mar 27, 2020 at 08:07:08PM +, Brooks Davis wrote:
>> On Fri, Mar 27, 2020 at 06:40:18PM +0500, Ruslan Garipov wrote:
>>> I failed to update FreeBSD 13.0-CURRENT amd64 r359231 to r359351.
>>>
>>> End of the build log:
>>>
>>> $ su root -c "make -j16 buildworld"
>>> ...
>>> ld: error: unable to find library -lkyua_cli_pie
>>> ld: error: unable to find library -lkyua_drivers_pie
>>> ld: error: unable to find library -lkyua_model_pie
>>> ld: error: unable to find library -llutok_pie
>>> ld: error: unable to find library -lkyua_engine_pie
>>> ld: error: unable to find library -llutok_pie
>>> ld: error: unable to find library -lkyua_utils_pie
>>> ld: error: unable to find library -llutok_pie
>>> ld: error: unable to find library -lkyua_store_pie
>>> ld: error: unable to find library -lkyua_model_pie
>>> ld: error: unable to find library -llutok_pie
>>> ld: error: unable to find library -lkyua_utils_pie
>>> ld: error: unable to find library -llutok_pie
>>> ld: error: unable to find library -lkyua_engine_pie
>>> ld: error: unable to find library -llutok_pie
>>> ld: error: unable to find library -lkyua_utils_pie
>>> ld: error: unable to find library -llutok_pie
>>> ld: error: unable to find library -lkyua_model_pie
>>> ld: error: unable to find library -llutok_pie
>>> ld: error: unable to find library -lkyua_store_pie
>>> ld: error: too many errors emitted, stopping now (use -error-limit=0
>>> to see all errors)
>>> c++: error: linker command failed with exit code 1 (use -v to see
>>> invocation)
>>> --- all_subdir_lib ---
>>> --- cpuset_getdomain.po ---
>>> --- all_subdir_usr.bin ---
>>> *** [kyua] Error code 1
>>>
>>> make[4]: stopped in /usr/src/usr.bin/kyua
>>> 1 error
>>>
>>> make[4]: stopped in /usr/src/usr.bin/kyua
>>> *** [all_subdir_usr.bin/kyua] Error code 2
>>> ...
>>>
>>> May be it's related to r359260[1]. Therefore, here is my TEST-settings:
>>>
>>> $ fgrep TEST /etc/src.conf
>>> WITHOUT_GOOGLETEST=
>>> WITHOUT_TESTS=
>>> WITH_TESTS_SUPPORT=
>>>
>>> Also what has confused me: it's a virtual machine which failed to build.
>>> A physical one built userland and kernel just fine. Both the physical
>>> and virtual machines have almost the same (differ only by CPU
>>> "selection" options) make.conf and src.conf and different kernel
>>> configurations. Both the machines were FreeBSD 13.0-CURRENT amd64
>>> r359231. I've started to build on clean systems (no /usr/obj at all).
>>>
>>> Can anyone help me to resolve this issue?
>>
>> I've replicated this issue and it goes back the the way
>> WITH_TESTS_SUPPORT was implemented way back in r273449
>>
>> This patch fixes WITHOUT_TESTS=t WITH_TESTS_SUPPORT=t for me.
>>
>> Index: Makefile.inc1
>> ===
>> --- Makefile.inc1 (revision 359367)
>> +++ Makefile.inc1 (working copy)
>> @@ -1100,7 +1100,7 @@
>> @echo
>> "--"
>> ${_+_}cd ${.CURDIR}; \
>> ${WMAKE} -DNO_FSCHG MK_HTML=no -DNO_LINT MK_MAN=no \
>> -MK_PROFILE=no MK_TESTS=no MK_TESTS_SUPPORT=${MK_TESTS}
>> libraries
>> +MK_PROFILE=no MK_TESTS=no libraries
>> everything: .PHONY
>> @echo
>> @echo
>> "--
>>
>> I've not committed it yet because I'm trying to figure out why this was
>> needed. I simply don't see how there could be a race between lib/aft and
>> libexec/aft as described. I suspect this may have been an error.
>
> I've committed a different fix in r359382.
Thanks a lot! I'll try it latter.
>
> The above change fixed the case at hand, but broke the default.
>
> -- Brooks
>
___
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: buildworld failed (usr.bin/kyua)
On Fri, Mar 27, 2020 at 08:07:08PM +, Brooks Davis wrote:
> On Fri, Mar 27, 2020 at 06:40:18PM +0500, Ruslan Garipov wrote:
> > I failed to update FreeBSD 13.0-CURRENT amd64 r359231 to r359351.
> >
> > End of the build log:
> >
> > $ su root -c "make -j16 buildworld"
> > ...
> > ld: error: unable to find library -lkyua_cli_pie
> > ld: error: unable to find library -lkyua_drivers_pie
> > ld: error: unable to find library -lkyua_model_pie
> > ld: error: unable to find library -llutok_pie
> > ld: error: unable to find library -lkyua_engine_pie
> > ld: error: unable to find library -llutok_pie
> > ld: error: unable to find library -lkyua_utils_pie
> > ld: error: unable to find library -llutok_pie
> > ld: error: unable to find library -lkyua_store_pie
> > ld: error: unable to find library -lkyua_model_pie
> > ld: error: unable to find library -llutok_pie
> > ld: error: unable to find library -lkyua_utils_pie
> > ld: error: unable to find library -llutok_pie
> > ld: error: unable to find library -lkyua_engine_pie
> > ld: error: unable to find library -llutok_pie
> > ld: error: unable to find library -lkyua_utils_pie
> > ld: error: unable to find library -llutok_pie
> > ld: error: unable to find library -lkyua_model_pie
> > ld: error: unable to find library -llutok_pie
> > ld: error: unable to find library -lkyua_store_pie
> > ld: error: too many errors emitted, stopping now (use -error-limit=0
> > to see all errors)
> > c++: error: linker command failed with exit code 1 (use -v to see
> > invocation)
> > --- all_subdir_lib ---
> > --- cpuset_getdomain.po ---
> > --- all_subdir_usr.bin ---
> > *** [kyua] Error code 1
> >
> > make[4]: stopped in /usr/src/usr.bin/kyua
> > 1 error
> >
> > make[4]: stopped in /usr/src/usr.bin/kyua
> > *** [all_subdir_usr.bin/kyua] Error code 2
> > ...
> >
> > May be it's related to r359260[1]. Therefore, here is my TEST-settings:
> >
> > $ fgrep TEST /etc/src.conf
> > WITHOUT_GOOGLETEST=
> > WITHOUT_TESTS=
> > WITH_TESTS_SUPPORT=
> >
> > Also what has confused me: it's a virtual machine which failed to build.
> > A physical one built userland and kernel just fine. Both the physical
> > and virtual machines have almost the same (differ only by CPU
> > "selection" options) make.conf and src.conf and different kernel
> > configurations. Both the machines were FreeBSD 13.0-CURRENT amd64
> > r359231. I've started to build on clean systems (no /usr/obj at all).
> >
> > Can anyone help me to resolve this issue?
>
> I've replicated this issue and it goes back the the way
> WITH_TESTS_SUPPORT was implemented way back in r273449
>
> This patch fixes WITHOUT_TESTS=t WITH_TESTS_SUPPORT=t for me.
>
> Index: Makefile.inc1
> ===
> --- Makefile.inc1 (revision 359367)
> +++ Makefile.inc1 (working copy)
> @@ -1100,7 +1100,7 @@
> @echo
> "--"
> ${_+_}cd ${.CURDIR}; \
> ${WMAKE} -DNO_FSCHG MK_HTML=no -DNO_LINT MK_MAN=no \
> - MK_PROFILE=no MK_TESTS=no MK_TESTS_SUPPORT=${MK_TESTS}
> libraries
> + MK_PROFILE=no MK_TESTS=no libraries
> everything: .PHONY
> @echo
> @echo
> "--
>
> I've not committed it yet because I'm trying to figure out why this was
> needed. I simply don't see how there could be a race between lib/aft and
> libexec/aft as described. I suspect this may have been an error.
I've committed a different fix in r359382.
The above change fixed the case at hand, but broke the default.
-- Brooks
signature.asc
Description: PGP signature
Re: buildworld failed (usr.bin/kyua)
On Fri, Mar 27, 2020 at 06:40:18PM +0500, Ruslan Garipov wrote:
> I failed to update FreeBSD 13.0-CURRENT amd64 r359231 to r359351.
>
> End of the build log:
>
> $ su root -c "make -j16 buildworld"
> ...
> ld: error: unable to find library -lkyua_cli_pie
> ld: error: unable to find library -lkyua_drivers_pie
> ld: error: unable to find library -lkyua_model_pie
> ld: error: unable to find library -llutok_pie
> ld: error: unable to find library -lkyua_engine_pie
> ld: error: unable to find library -llutok_pie
> ld: error: unable to find library -lkyua_utils_pie
> ld: error: unable to find library -llutok_pie
> ld: error: unable to find library -lkyua_store_pie
> ld: error: unable to find library -lkyua_model_pie
> ld: error: unable to find library -llutok_pie
> ld: error: unable to find library -lkyua_utils_pie
> ld: error: unable to find library -llutok_pie
> ld: error: unable to find library -lkyua_engine_pie
> ld: error: unable to find library -llutok_pie
> ld: error: unable to find library -lkyua_utils_pie
> ld: error: unable to find library -llutok_pie
> ld: error: unable to find library -lkyua_model_pie
> ld: error: unable to find library -llutok_pie
> ld: error: unable to find library -lkyua_store_pie
> ld: error: too many errors emitted, stopping now (use -error-limit=0
> to see all errors)
> c++: error: linker command failed with exit code 1 (use -v to see
> invocation)
> --- all_subdir_lib ---
> --- cpuset_getdomain.po ---
> --- all_subdir_usr.bin ---
> *** [kyua] Error code 1
>
> make[4]: stopped in /usr/src/usr.bin/kyua
> 1 error
>
> make[4]: stopped in /usr/src/usr.bin/kyua
> *** [all_subdir_usr.bin/kyua] Error code 2
> ...
>
> May be it's related to r359260[1]. Therefore, here is my TEST-settings:
>
> $ fgrep TEST /etc/src.conf
> WITHOUT_GOOGLETEST=
> WITHOUT_TESTS=
> WITH_TESTS_SUPPORT=
>
> Also what has confused me: it's a virtual machine which failed to build.
> A physical one built userland and kernel just fine. Both the physical
> and virtual machines have almost the same (differ only by CPU
> "selection" options) make.conf and src.conf and different kernel
> configurations. Both the machines were FreeBSD 13.0-CURRENT amd64
> r359231. I've started to build on clean systems (no /usr/obj at all).
>
> Can anyone help me to resolve this issue?
I've replicated this issue and it goes back the the way
WITH_TESTS_SUPPORT was implemented way back in r273449
This patch fixes WITHOUT_TESTS=t WITH_TESTS_SUPPORT=t for me.
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 359367)
+++ Makefile.inc1 (working copy)
@@ -1100,7 +1100,7 @@
@echo
"--"
${_+_}cd ${.CURDIR}; \
${WMAKE} -DNO_FSCHG MK_HTML=no -DNO_LINT MK_MAN=no \
- MK_PROFILE=no MK_TESTS=no MK_TESTS_SUPPORT=${MK_TESTS}
libraries
+ MK_PROFILE=no MK_TESTS=no libraries
everything: .PHONY
@echo
@echo
"--
I've not committed it yet because I'm trying to figure out why this was
needed. I simply don't see how there could be a race between lib/aft and
libexec/aft as described. I suspect this may have been an error.
-- Brooks
signature.asc
Description: PGP signature
Re: Buildworld dying wint lldb?
Steve Kargl wrote: Anyone else see ===> usr.bin/clang/lldb (all) c++ -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -I/usr/src/contrib/llvm-project/lldb/include -I/usr/obj/usr/src/amd64.amd64/usr.bin/clang/lldb -march=bdver2 -I/usr/src/contrib/llvm-project/clang/include -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" -DDEFAULT_SYSROOT=\"\" -DLLVM_TARGET_ENABLE_AARCH64 -DLLVM_TARGET_ENABLE_ARM -DLLVM_TARGET_ENABLE_MIPS -DLLVM_TARGET_ENABLE_POWERPC -DLLVM_TARGET_ENABLE_RISCV -DLLVM_TARGET_ENABLE_SPARC -DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler -DLLVM_ NATIVE_TARGET=LLVMInitializeX86Target -DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections -fdata-sections -gline-tables-only -Wno-format-zero-length -fstack-protector-strong -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-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -fno-exceptions -fno-rtti -std=c++11 -stdlib=libc++ -Wno-c++11-extensions -Wl,--gc-sections -o lldb.full Driver.o /usr/obj/usr/src/amd64.amd64/lib/clang/liblldb/liblldb.a /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a -ledit -lexecinfo -lpanel -lncursesw -lz -lpthread ld: error: undefined symbol: lldb_private::ClangModulesDeclVendor::Create(lldb_private::Target&) referenced by Target.cpp:2487 (/usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2487) This is 'make buildworld' with an empty //usr/obj. My /etc/sr.conf has WITHOUT_TESTS="yes" WITH_LLDB="yes" Looking at src.conf(5), this is already default setting for amd64. And given that it's default, no, I'm not seeing this doing buildworld with recent checkouts. WITH_BSD_GREP="YES" WITH_LLVM_TARGET_AARCH64="NO" WITH_LLVM_TARGET_ARM="NO" WITH_LLVM_TARGET_MIPS="NO" WITH_LLVM_TARGET_POWERPC="NO" WITH_LLVM_TARGET_SPARC="NO" WITH_LLVM_TARGET_X86="YES" These settings don't do what you likely expect them to do as src.conf(5) explicitly states (and confirmed by your build log excerpt above): The values of variables are ignored regardless of their setting; even if they would be set to “FALSE” or “NO”. So you'd want the WITHOUT ones. ___ 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: buildworld on CPU-A, installworld on CPU-B ends up with SIGILL
On 11/26/2019 12:09 AM, Miroslav Lachman wrote: > Ruslan Garipov wrote on 2019/11/25 19:26: > > [...] > >>> I didn't tried this with current but I am using it with stable (11.3 at >>> this time). Building on Xeon E3-1240v3 and installing on many different >>> machines. Some of them are 10+ years old AMD Opteron, some Xeon E5649, >>> some 10 years old Intel Pentium. >>> So at least it worked in the past (11.3 amd64). Did you use this >>> workflow in the past / did it work? >> No, unfortunately I didn't. Always built world/kernel on target host. >> >>> I remember some issue in the past which was (accidentally?) fixed by >>> running "make buildworld && make builkernel && make installkernel && >>> make installworld" on the build host (to some different DESTDIR) and >>> then "make installkernel && make installworld" on the target host (build >>> machine is shared via NFS) >> Therefore, this trick somehow "fixes" /usr/obj shared on the build >> machine? I'll try this later. Thanks! > > Yes, I think so. But I am not a developer nor I know much about how > build process works. I've tried to installkernel/installworld with non-default DESTDIR, it doesn't help for GENERIC kernel. But... After I had failed with that DESTDIR, I decided to update kernel/world on the build machine to the revision I tried to deploy (r355085). I cleaned result of the previous build, restored make.conf and src.conf specifying sandybridge† there as value of CPUTYPE and explicit -march, build and install kernel and world. Then I cleaned result of the build again, run buildworld and buildkernel preparing to investigate the build logs. But before doing that, I decided to run `make installkernel` once again on a target machine, and ... bang! It completed successfully! mergemaster, installworld -- the same! Everything completed smoothly. I updated the source to r355105 on the build machine, buildworld and buildkernel there -- installkernel, mergemaster, installworld on a target machine completed with no errors. To be honest, I don't know what exactly was a reason for my previous failure. Because I've tried to build with sandybridge in the configs. May be r355085 helped me, I don't know. In any case, I should inspect the build log, I believe. Miroslav, thanks for support! † This is the oldest chip we have on our ESXi hosts. ___ 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: buildworld on CPU-A, installworld on CPU-B ends up with SIGILL
Ruslan Garipov wrote on 2019/11/25 19:26: [...] I didn't tried this with current but I am using it with stable (11.3 at this time). Building on Xeon E3-1240v3 and installing on many different machines. Some of them are 10+ years old AMD Opteron, some Xeon E5649, some 10 years old Intel Pentium. So at least it worked in the past (11.3 amd64). Did you use this workflow in the past / did it work? No, unfortunately I didn't. Always built world/kernel on target host. I remember some issue in the past which was (accidentally?) fixed by running "make buildworld && make builkernel && make installkernel && make installworld" on the build host (to some different DESTDIR) and then "make installkernel && make installworld" on the target host (build machine is shared via NFS) Therefore, this trick somehow "fixes" /usr/obj shared on the build machine? I'll try this later. Thanks! Yes, I think so. But I am not a developer nor I know much about how build process works. Miroslav Lachman ___ 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: buildworld on CPU-A, installworld on CPU-B ends up with SIGILL
On 11/25/2019 10:30 PM, Miroslav Lachman wrote: > Ruslan Garipov wrote on 2019/11/25 15:06: >> Hello. >> >> I want to build kernel and world (of FreeBSD 13.0-CURRENT) on a fast >> virtual machine for other ones (all the virtual machines are hosted on >> VMware EXSi hypervisors, which have different physical CPUs). >> >> After `make -j16 buildworld` has finished successfully on the build >> machine, I get there, for example, >> /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/install program having the >> shlxq instruction (one from the BMI2 instruction set extensions). This >> eventually causes make installkernel and make installworld to fail with >> SIGILL on a virtual machine which must consume built world and kernel, >> and which is hosted on another ESXi instance, with older physical CPU >> (read: with CPU not implementing shlxq). >> >> The build machine (FreeBSD 13.0-CURRENT r354802) builds (x)install using >> the following commands (a part of buildworld): >> >> $ cc -O2 -pipe -O2 -march=x86-64 -pipe -I/usr/src/contrib/mtree >> -I/usr/src/lib/libnetbsd -DHAVE_STRUCT_STAT_ST_FLAGS=1 -MD >> -MF.depend.xinstall.o -MTxinstall.o -std=gnu99 -Wno-format-zero-length >> -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include >> -c /usr/src/usr.bin/xinstall/xinstall.c -o xinstall.o >> $ cc -O2 -pipe -O2 -march=x86-64 -pipe -I/usr/src/contrib/mtree >> -I/usr/src/lib/libnetbsd -DHAVE_STRUCT_STAT_ST_FLAGS=1 -MD >> -MF.depend.getid.o -MTgetid.o -std=gnu99 -Wno-format-zero-length >> -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include >> -c /usr/src/contrib/mtree/getid.c -o getid.o >> $ cc -O2 -pipe -O2 -march=x86-64 -pipe -I/usr/src/contrib/mtree >> -I/usr/src/lib/libnetbsd -DHAVE_STRUCT_STAT_ST_FLAGS=1 -std=gnu99 >> -Wno-format-zero-length -Qunused-arguments >> -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -static >> -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib -o xinstall xinstall.o >> getid.o -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libmd -lmd -legacy >> >> This produces xintstall with `shlxq`s: >> >> $ llvm-objdump --disassemble xinstall | grep -c shlxq >> 135 >> >> I believe statically linked /usr/lib/libmd.a is a stuff which brings >> `shlxq`s into the xinstall. I didn't examine it further, sorry... >> >> My question is: is it possible to buildworld without issuing >> instructions which are native for the host CPU? I have neither >> /etc/make.conf, nor /etc/src.conf on the build machine. Is it possible >> at all for FreeBSD CURRENT to be built outside a host and installed on >> the host later? >> >> Just as a reference: >> >> My build machine has Intel(R) Xeon(R) Gold 6150 CPU that supports BMI2: >> >> # cpucontrol -i 7 /dev/cpuctl0 >> cpuid level 0x7: 0x 0xd19f6ffb 0x0018 0xbc00 >> >> (Bit 08 in EBX is set) >> >> , and a consuming machine has Intel(R) Xeon(R) CPU E5-4617 CPU that >> doesn't support BMI2: >> >> # cpucontrol -i 7 /dev/cpuctl0 >> cpuid level 0x7: 0x 0x0002 0x 0xbc00 >> >> (Bit 08 in EBX is unset). >> >> Both machines install kernel and world without any problem, if they were >> built locally. > > I didn't tried this with current but I am using it with stable (11.3 at > this time). Building on Xeon E3-1240v3 and installing on many different > machines. Some of them are 10+ years old AMD Opteron, some Xeon E5649, > some 10 years old Intel Pentium. > So at least it worked in the past (11.3 amd64). Did you use this > workflow in the past / did it work? No, unfortunately I didn't. Always built world/kernel on target host. > I remember some issue in the past which was (accidentaly?) fixed by > running "make buildworld && make builkernel && make installkernel && > make installworld" on the build host (to some different DESTDIR) and > then "make installkernel && make installworld" on the target host (build > machine is shared via NFS) Therefore, this trick somehow "fixes" /usr/obj shared on the build machine? I'll try this later. Thanks! > > Miroslav Lachman > ___ 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: buildworld on CPU-A, installworld on CPU-B ends up with SIGILL
Ruslan Garipov wrote on 2019/11/25 15:06: Hello. I want to build kernel and world (of FreeBSD 13.0-CURRENT) on a fast virtual machine for other ones (all the virtual machines are hosted on VMware EXSi hypervisors, which have different physical CPUs). After `make -j16 buildworld` has finished successfully on the build machine, I get there, for example, /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/install program having the shlxq instruction (one from the BMI2 instruction set extensions). This eventually causes make installkernel and make installworld to fail with SIGILL on a virtual machine which must consume built world and kernel, and which is hosted on another ESXi instance, with older physical CPU (read: with CPU not implementing shlxq). The build machine (FreeBSD 13.0-CURRENT r354802) builds (x)install using the following commands (a part of buildworld): $ cc -O2 -pipe -O2 -march=x86-64 -pipe -I/usr/src/contrib/mtree -I/usr/src/lib/libnetbsd -DHAVE_STRUCT_STAT_ST_FLAGS=1 -MD -MF.depend.xinstall.o -MTxinstall.o -std=gnu99 -Wno-format-zero-length -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -c /usr/src/usr.bin/xinstall/xinstall.c -o xinstall.o $ cc -O2 -pipe -O2 -march=x86-64 -pipe -I/usr/src/contrib/mtree -I/usr/src/lib/libnetbsd -DHAVE_STRUCT_STAT_ST_FLAGS=1 -MD -MF.depend.getid.o -MTgetid.o -std=gnu99 -Wno-format-zero-length -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -c /usr/src/contrib/mtree/getid.c -o getid.o $ cc -O2 -pipe -O2 -march=x86-64 -pipe -I/usr/src/contrib/mtree -I/usr/src/lib/libnetbsd -DHAVE_STRUCT_STAT_ST_FLAGS=1 -std=gnu99 -Wno-format-zero-length -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -static -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib -o xinstall xinstall.o getid.o -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libmd -lmd -legacy This produces xintstall with `shlxq`s: $ llvm-objdump --disassemble xinstall | grep -c shlxq 135 I believe statically linked /usr/lib/libmd.a is a stuff which brings `shlxq`s into the xinstall. I didn't examine it further, sorry... My question is: is it possible to buildworld without issuing instructions which are native for the host CPU? I have neither /etc/make.conf, nor /etc/src.conf on the build machine. Is it possible at all for FreeBSD CURRENT to be built outside a host and installed on the host later? Just as a reference: My build machine has Intel(R) Xeon(R) Gold 6150 CPU that supports BMI2: # cpucontrol -i 7 /dev/cpuctl0 cpuid level 0x7: 0x 0xd19f6ffb 0x0018 0xbc00 (Bit 08 in EBX is set) , and a consuming machine has Intel(R) Xeon(R) CPU E5-4617 CPU that doesn't support BMI2: # cpucontrol -i 7 /dev/cpuctl0 cpuid level 0x7: 0x 0x0002 0x 0xbc00 (Bit 08 in EBX is unset). Both machines install kernel and world without any problem, if they were built locally. I didn't tried this with current but I am using it with stable (11.3 at this time). Building on Xeon E3-1240v3 and installing on many different machines. Some of them are 10+ years old AMD Opteron, some Xeon E5649, some 10 years old Intel Pentium. So at least it worked in the past (11.3 amd64). Did you use this workflow in the past / did it work? I remember some issue in the past which was (accidentaly?) fixed by running "make buildworld && make builkernel && make installkernel && make installworld" on the build host (to some different DESTDIR) and then "make installkernel && make installworld" on the target host (build machine is shared via NFS) Miroslav Lachman ___ 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: buildworld falure: truncated or malformed archive
On Wed, Jan 2, 2019, 1:42 PM John Baldwin On 12/31/18 12:08 PM, Warner Losh wrote: > > On Mon, Dec 31, 2018, 1:36 PM Ryan Stone > > >> Does this mean that it's currently impossible to build a world with > >> debug symbols? > >> > > > > Yes. Clang is simply too big until 64 bit offset support goes in. > > We actually build clang (and llvm) with stripped down debug symbols by > default. If you don't put any DEBUG_* foo in src.conf you will get debug > symbols for all of the world including the limited ones for clang. (We > use -gline-tables-only or some > Yea, DEBUG_FLAGS=-g is what breaks it... Warner > ___ 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: buildworld falure: truncated or malformed archive
On 12/31/18 12:08 PM, Warner Losh wrote: > On Mon, Dec 31, 2018, 1:36 PM Ryan Stone >> Does this mean that it's currently impossible to build a world with >> debug symbols? >> > > Yes. Clang is simply too big until 64 bit offset support goes in. We actually build clang (and llvm) with stripped down debug symbols by default. If you don't put any DEBUG_* foo in src.conf you will get debug symbols for all of the world including the limited ones for clang. (We use -gline-tables-only or some such for clang). -- 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"
Re: buildworld falure: truncated or malformed archive
There's always 'WITHOUT_CLANG=1' in src.conf. Best, Conrad On Mon, Dec 31, 2018 at 12:09 PM Warner Losh wrote: > > On Mon, Dec 31, 2018, 1:36 PM Ryan Stone > > Does this mean that it's currently impossible to build a world with > > debug symbols? > > > > Yes. Clang is simply too big until 64 bit offset support goes in. > > Warner > > > > ___ > 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" ___ 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: buildworld falure: truncated or malformed archive
On Mon, Dec 31, 2018, 1:36 PM Ryan Stone Does this mean that it's currently impossible to build a world with > debug symbols? > Yes. Clang is simply too big until 64 bit offset support goes in. Warner > ___ 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: buildworld falure: truncated or malformed archive
Does this mean that it's currently impossible to build a world with debug symbols? ___ 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: buildworld falure: truncated or malformed archive
On Thu, 27 Dec 2018 at 19:16, Warner Losh wrote: > > On Thu, Dec 27, 2018, 5:29 PM Ed Maste > >> On Thu, 27 Dec 2018 at 14:35, Ryan Stone wrote: >> > >> > I seem to recall something about libarchive or ar having a bug >> > creating archives > 4GB, >> >> Indeed, FreeBSD's bespoke ar does not support the /SYM64/ format >> needed for offsets >4GB. imp@ also ran into this; I'm not sure what's >> causing libclang.a to be >4GB. Is there one object file that's >> unreasonably large? > > > For me it was a DEBUG_FLAGS=-g I had in make.conf that I'd forgotten about. > > Ar should fail to create a .a that's >4GB. Yes - at least, one with a symbol table. It's PR234454. Next month two co-op students will start working for the FreeBSD Foundation and adding 64-bit /SYM64/ support to ar will probably make a good starting project for one of them. ___ 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: buildworld falure: truncated or malformed archive
On Thu, Dec 27, 2018, 5:29 PM Ed Maste On Thu, 27 Dec 2018 at 14:35, Ryan Stone wrote: > > > > I seem to recall something about libarchive or ar having a bug > > creating archives > 4GB, > > Indeed, FreeBSD's bespoke ar does not support the /SYM64/ format > needed for offsets >4GB. imp@ also ran into this; I'm not sure what's > causing libclang.a to be >4GB. Is there one object file that's > unreasonably large? > For me it was a DEBUG_FLAGS=-g I had in make.conf that I'd forgotten about. Ar should fail to create a .a that's >4GB. Warner > ___ > 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" > ___ 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: buildworld falure: truncated or malformed archive
On Thu, 27 Dec 2018 at 14:35, Ryan Stone wrote: > > I seem to recall something about libarchive or ar having a bug > creating archives > 4GB, Indeed, FreeBSD's bespoke ar does not support the /SYM64/ format needed for offsets >4GB. imp@ also ran into this; I'm not sure what's causing libclang.a to be >4GB. Is there one object file that's unreasonably large? ___ 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: buildworld falure: truncated or malformed archive
On Thu, Dec 27, 2018, 2:36 PM Ryan Stone I'm trying to update an old (~May 2018) -head system to the latest, > but I'm getting a persistent error during buildworld: > > ld: error: /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a: > could not get the member for symbol > > _ZN5clang17MultiplexConsumerC1ENSt3__16vectorINS1_10unique_ptrINS_11ASTConsumerENS1_14default_deleteIS4_NS1_9allocatorIS7_: > truncated or malformed archive (terminator characters in archive > member "dC" not the correct "`\n" values for the archive member header > for tOutputExprEj > > I seem to recall something about libarchive or ar having a bug > creating archives > 4GB, but I tried doing a "make install" from > lib/libarchive and usr.bin/ar and doing a rebuild, and that doesn't > seem to have resolved the issue. I also made sure to try a build with > a clean /usr/obj with no success. Any ideas how I can get past this? > Remove any DEBUG_FLAGS. .a files can't be larger than 4GB. Clang / llvm now explodes the limit. Warner ___ > 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" > ___ 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: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools
In my testing 338129 fixed the issue. Seems like the problem is that
bsd.crunchgen.mk iterates over all directories to do a make obj when
it does the bootstrap-tools phase.
On Tue, 21 Aug 2018 at 14:49, Warner Losh wrote:
>
>
>
> On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin wrote:
>>
>> On 8/20/18 9:00 PM, O. Hartmann wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA512
>> >
>> > Am Mon, 20 Aug 2018 21:24:21 +0200
>> > "O. Hartmann" schrieb:
>> >
>> >> -BEGIN PGP SIGNED MESSAGE-
>> >> Hash: SHA512
>> >>
>> >> Building NanoBSD world on CURRENT r338113 fails due to:
>> >>
>> >> [...]
>> >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde && MK_TESTS=no
>> >> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1
>> >> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/sources/CURRENT/src/amd64.amd64/rescue/rescue
>> >> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE
>> >> CRUNCH_CFLAGS=-DRESCUE
>> >> MK_AUTO_OBJ=no obj make[5]:
>> >> "/pool/sources/CURRENT/src/tools/build/mk/Makefile.boot"
>> >> line 18: Do not include ${SRCTOP}/sys when building bootstrap tools.
>> >> Copy the header to
>> >> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was caused by
>> >> Makefile
>> >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde] Error
>> >> code 1
>> >>
>> >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue
>> >> [...]
>> >>
>> >>
>> >> This problem occured during today's source updates since I was able to
>> >> build the NanoBSD
>> >> image I intend to build yesterday ~ r338060.
>> >>
>> >> What is going wrong?
>> >
>> > It seems the problem has been introduced after r338095, since r338095
>> > builds ok, while
>> > r338096 doesn't.
>>
>> 338096 added this check to catch a kind of error in our Makefiles. Alex
>> (cc'd) can
>> help with figuring out what the error is.
>
>
> Except we're not building anything, we're making obj in rescue... It looks
> like a false positive...
>
> Warner
___
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: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools
I think relaxing the check to just avoid includes of "${SRCTOP}/sys" is
probably the best solution. It would be nice to also handle the
${.CURDIR}/../../sys case but since it's just there to prevent ABI issues
that's probably fine.
Alex
On Tue, 21 Aug 2018 at 15:19 Warner Losh wrote:
> On Tue, Aug 21, 2018 at 8:16 AM, Warner Losh wrote:
>
>> There's a half a dozen special targets, however. clean comes to mind...
>>
>>
>> However, this test is needlessly restrictive:
>>
>> .if
>> !empty(CFLAGS:M*${SRCTOP}/sys*:N*${SRCTOP}/sys/cddl/compat*:N*${SRCTOP}/sys/crypto*)
>>
>> since it matches
>>
>> CFLAGS+=-I${SRCTOP}/sys/sys/disk
>>
>> which is totally legit. It's designed to be legit everywhere for building
>> on Linux...
>>
>> .if
>> !empty(CFLAGS:M*${SRCTOP}/sys:N*${SRCTOP}/sys/cddl/compat:N*${SRCTOP}/sys/crypto)
>>
>> would be a better test, imho.
>>
>
> Although, I could passively agressively work around it with
>
> CFLAGS+=-I${.CURDIR}/../../sys/sys/disk
>
> which also kinda defeats its purpose...
>
> Warner
>
>
>> Warner
>>
>> On Tue, Aug 21, 2018 at 8:11 AM, Alexander Richardson <
>> arichard...@freebsd.org> wrote:
>>
>>> In my testing 338129 fixed the issue. Seems like the problem is that
>>> bsd.crunchgen.mk iterates over all directories to do a make obj when
>>> it does the bootstrap-tools phase.
>>> On Tue, 21 Aug 2018 at 14:49, Warner Losh wrote:
>>> >
>>> >
>>> >
>>> > On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin
>>> wrote:
>>> >>
>>> >> On 8/20/18 9:00 PM, O. Hartmann wrote:
>>> >> > -BEGIN PGP SIGNED MESSAGE-
>>> >> > Hash: SHA512
>>> >> >
>>> >> > Am Mon, 20 Aug 2018 21:24:21 +0200
>>> >> > "O. Hartmann" schrieb:
>>> >> >
>>> >> >> -BEGIN PGP SIGNED MESSAGE-
>>> >> >> Hash: SHA512
>>> >> >>
>>> >> >> Building NanoBSD world on CURRENT r338113 fails due to:
>>> >> >>
>>> >> >> [...]
>>> >> >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde &&
>>> MK_TESTS=no
>>> >> >> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1
>>> >> >>
>>> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/sources/CURRENT/src/amd64.amd64/rescue/rescue
>>> >> >> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE
>>> CRUNCH_CFLAGS=-DRESCUE
>>> >> >> MK_AUTO_OBJ=no obj make[5]:
>>> "/pool/sources/CURRENT/src/tools/build/mk/Makefile.boot"
>>> >> >> line 18: Do not include ${SRCTOP}/sys when building bootstrap
>>> tools. Copy the header to
>>> >> >> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was
>>> caused by Makefile
>>> >> >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde]
>>> Error code 1
>>> >> >>
>>> >> >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue
>>> >> >> [...]
>>> >> >>
>>> >> >>
>>> >> >> This problem occured during today's source updates since I was
>>> able to build the NanoBSD
>>> >> >> image I intend to build yesterday ~ r338060.
>>> >> >>
>>> >> >> What is going wrong?
>>> >> >
>>> >> > It seems the problem has been introduced after r338095, since
>>> r338095 builds ok, while
>>> >> > r338096 doesn't.
>>> >>
>>> >> 338096 added this check to catch a kind of error in our Makefiles.
>>> Alex (cc'd) can
>>> >> help with figuring out what the error is.
>>> >
>>> >
>>> > Except we're not building anything, we're making obj in rescue... It
>>> looks like a false positive...
>>> >
>>> > Warner
>>>
>>
>>
___
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: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools
On Tue, Aug 21, 2018 at 8:16 AM, Warner Losh wrote:
> There's a half a dozen special targets, however. clean comes to mind...
>
>
> However, this test is needlessly restrictive:
>
> .if !empty(CFLAGS:M*${SRCTOP}/sys*:N*${SRCTOP}/sys/cddl/compat*:
> N*${SRCTOP}/sys/crypto*)
>
> since it matches
>
> CFLAGS+=-I${SRCTOP}/sys/sys/disk
>
> which is totally legit. It's designed to be legit everywhere for building
> on Linux...
>
> .if !empty(CFLAGS:M*${SRCTOP}/sys:N*${SRCTOP}/sys/cddl/compat:N*
> ${SRCTOP}/sys/crypto)
>
> would be a better test, imho.
>
Although, I could passively agressively work around it with
CFLAGS+=-I${.CURDIR}/../../sys/sys/disk
which also kinda defeats its purpose...
Warner
> Warner
>
> On Tue, Aug 21, 2018 at 8:11 AM, Alexander Richardson <
> arichard...@freebsd.org> wrote:
>
>> In my testing 338129 fixed the issue. Seems like the problem is that
>> bsd.crunchgen.mk iterates over all directories to do a make obj when
>> it does the bootstrap-tools phase.
>> On Tue, 21 Aug 2018 at 14:49, Warner Losh wrote:
>> >
>> >
>> >
>> > On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin wrote:
>> >>
>> >> On 8/20/18 9:00 PM, O. Hartmann wrote:
>> >> > -BEGIN PGP SIGNED MESSAGE-
>> >> > Hash: SHA512
>> >> >
>> >> > Am Mon, 20 Aug 2018 21:24:21 +0200
>> >> > "O. Hartmann" schrieb:
>> >> >
>> >> >> -BEGIN PGP SIGNED MESSAGE-
>> >> >> Hash: SHA512
>> >> >>
>> >> >> Building NanoBSD world on CURRENT r338113 fails due to:
>> >> >>
>> >> >> [...]
>> >> >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde &&
>> MK_TESTS=no
>> >> >> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1
>> >> >> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/
>> sources/CURRENT/src/amd64.amd64/rescue/rescue
>> >> >> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE
>> CRUNCH_CFLAGS=-DRESCUE
>> >> >> MK_AUTO_OBJ=no obj make[5]: "/pool/sources/CURRENT/src/too
>> ls/build/mk/Makefile.boot"
>> >> >> line 18: Do not include ${SRCTOP}/sys when building bootstrap
>> tools. Copy the header to
>> >> >> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was
>> caused by Makefile
>> >> >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde]
>> Error code 1
>> >> >>
>> >> >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue
>> >> >> [...]
>> >> >>
>> >> >>
>> >> >> This problem occured during today's source updates since I was able
>> to build the NanoBSD
>> >> >> image I intend to build yesterday ~ r338060.
>> >> >>
>> >> >> What is going wrong?
>> >> >
>> >> > It seems the problem has been introduced after r338095, since
>> r338095 builds ok, while
>> >> > r338096 doesn't.
>> >>
>> >> 338096 added this check to catch a kind of error in our Makefiles.
>> Alex (cc'd) can
>> >> help with figuring out what the error is.
>> >
>> >
>> > Except we're not building anything, we're making obj in rescue... It
>> looks like a false positive...
>> >
>> > Warner
>>
>
>
___
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: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools
There's a half a dozen special targets, however. clean comes to mind...
However, this test is needlessly restrictive:
.if
!empty(CFLAGS:M*${SRCTOP}/sys*:N*${SRCTOP}/sys/cddl/compat*:N*${SRCTOP}/sys/crypto*)
since it matches
CFLAGS+=-I${SRCTOP}/sys/sys/disk
which is totally legit. It's designed to be legit everywhere for building
on Linux...
.if
!empty(CFLAGS:M*${SRCTOP}/sys:N*${SRCTOP}/sys/cddl/compat:N*${SRCTOP}/sys/crypto)
would be a better test, imho.
Warner
On Tue, Aug 21, 2018 at 8:11 AM, Alexander Richardson <
arichard...@freebsd.org> wrote:
> In my testing 338129 fixed the issue. Seems like the problem is that
> bsd.crunchgen.mk iterates over all directories to do a make obj when
> it does the bootstrap-tools phase.
> On Tue, 21 Aug 2018 at 14:49, Warner Losh wrote:
> >
> >
> >
> > On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin wrote:
> >>
> >> On 8/20/18 9:00 PM, O. Hartmann wrote:
> >> > -BEGIN PGP SIGNED MESSAGE-
> >> > Hash: SHA512
> >> >
> >> > Am Mon, 20 Aug 2018 21:24:21 +0200
> >> > "O. Hartmann" schrieb:
> >> >
> >> >> -BEGIN PGP SIGNED MESSAGE-
> >> >> Hash: SHA512
> >> >>
> >> >> Building NanoBSD world on CURRENT r338113 fails due to:
> >> >>
> >> >> [...]
> >> >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde &&
> MK_TESTS=no
> >> >> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1
> >> >> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/
> pool/sources/CURRENT/src/amd64.amd64/rescue/rescue
> >> >> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE
> CRUNCH_CFLAGS=-DRESCUE
> >> >> MK_AUTO_OBJ=no obj make[5]: "/pool/sources/CURRENT/src/
> tools/build/mk/Makefile.boot"
> >> >> line 18: Do not include ${SRCTOP}/sys when building bootstrap
> tools. Copy the header to
> >> >> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was
> caused by Makefile
> >> >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde]
> Error code 1
> >> >>
> >> >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue
> >> >> [...]
> >> >>
> >> >>
> >> >> This problem occured during today's source updates since I was able
> to build the NanoBSD
> >> >> image I intend to build yesterday ~ r338060.
> >> >>
> >> >> What is going wrong?
> >> >
> >> > It seems the problem has been introduced after r338095, since r338095
> builds ok, while
> >> > r338096 doesn't.
> >>
> >> 338096 added this check to catch a kind of error in our Makefiles.
> Alex (cc'd) can
> >> help with figuring out what the error is.
> >
> >
> > Except we're not building anything, we're making obj in rescue... It
> looks like a false positive...
> >
> > Warner
>
___
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: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools
On Tue, Aug 21, 2018 at 7:49 AM, Warner Losh wrote:
>
>
> On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin wrote:
>
>> On 8/20/18 9:00 PM, O. Hartmann wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA512
>> >
>> > Am Mon, 20 Aug 2018 21:24:21 +0200
>> > "O. Hartmann" schrieb:
>> >
>> >> -BEGIN PGP SIGNED MESSAGE-
>> >> Hash: SHA512
>> >>
>> >> Building NanoBSD world on CURRENT r338113 fails due to:
>> >>
>> >> [...]
>> >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde &&
>> MK_TESTS=no
>> >> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1
>> >> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/
>> sources/CURRENT/src/amd64.amd64/rescue/rescue
>> >> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE
>> CRUNCH_CFLAGS=-DRESCUE
>> >> MK_AUTO_OBJ=no obj make[5]: "/pool/sources/CURRENT/src/too
>> ls/build/mk/Makefile.boot"
>> >> line 18: Do not include ${SRCTOP}/sys when building bootstrap tools.
>> Copy the header to
>> >> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was caused
>> by Makefile
>> >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde] Error
>> code 1
>> >>
>> >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue
>> >> [...]
>> >>
>> >>
>> >> This problem occured during today's source updates since I was able to
>> build the NanoBSD
>> >> image I intend to build yesterday ~ r338060.
>> >>
>> >> What is going wrong?
>> >
>> > It seems the problem has been introduced after r338095, since r338095
>> builds ok, while
>> > r338096 doesn't.
>>
>> 338096 added this check to catch a kind of error in our Makefiles. Alex
>> (cc'd) can
>> help with figuring out what the error is.
>>
>
> Except we're not building anything, we're making obj in rescue... It
> looks like a false positive...
>
weird, I'm dying elsewhere.
You can recreate this with
cd tools/tools/nanobsd/embedded
sh -c ../nanobsd.sh -c qemu-amd64-uefi.cfg
it dies in mkimg. We have LOCAL_XTOOL_DIRS=usr.bin/mkimg so it's building
in stage 3. It's likely because of
CFLAGS+=-I${SRCTOP}/sys/sys/disk
which is 100% legit always by design, so the test in this case is a false
positive and must be relaxed.
I'm guessing that the rescue case above is similar: we're building an
different tool early.
Warner
___
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: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools
On Tue, Aug 21, 2018 at 12:38 AM, John Baldwin wrote:
> On 8/20/18 9:00 PM, O. Hartmann wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Am Mon, 20 Aug 2018 21:24:21 +0200
> > "O. Hartmann" schrieb:
> >
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA512
> >>
> >> Building NanoBSD world on CURRENT r338113 fails due to:
> >>
> >> [...]
> >> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde &&
> MK_TESTS=no
> >> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1
> >> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/
> pool/sources/CURRENT/src/amd64.amd64/rescue/rescue
> >> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE
> CRUNCH_CFLAGS=-DRESCUE
> >> MK_AUTO_OBJ=no obj make[5]: "/pool/sources/CURRENT/src/
> tools/build/mk/Makefile.boot"
> >> line 18: Do not include ${SRCTOP}/sys when building bootstrap tools.
> Copy the header to
> >> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was caused
> by Makefile
> >> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde] Error
> code 1
> >>
> >> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue
> >> [...]
> >>
> >>
> >> This problem occured during today's source updates since I was able to
> build the NanoBSD
> >> image I intend to build yesterday ~ r338060.
> >>
> >> What is going wrong?
> >
> > It seems the problem has been introduced after r338095, since r338095
> builds ok, while
> > r338096 doesn't.
>
> 338096 added this check to catch a kind of error in our Makefiles. Alex
> (cc'd) can
> help with figuring out what the error is.
>
Except we're not building anything, we're making obj in rescue... It looks
like a false positive...
Warner
___
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: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools
On 8/20/18 9:00 PM, O. Hartmann wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am Mon, 20 Aug 2018 21:24:21 +0200
> "O. Hartmann" schrieb:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> Building NanoBSD world on CURRENT r338113 fails due to:
>>
>> [...]
>> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde && MK_TESTS=no
>> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1
>> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/sources/CURRENT/src/amd64.amd64/rescue/rescue
>> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE
>> CRUNCH_CFLAGS=-DRESCUE
>> MK_AUTO_OBJ=no obj make[5]:
>> "/pool/sources/CURRENT/src/tools/build/mk/Makefile.boot"
>> line 18: Do not include ${SRCTOP}/sys when building bootstrap tools. Copy
>> the header to
>> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was caused by
>> Makefile
>> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde] Error code 1
>>
>> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue
>> [...]
>>
>>
>> This problem occured during today's source updates since I was able to build
>> the NanoBSD
>> image I intend to build yesterday ~ r338060.
>>
>> What is going wrong?
>
> It seems the problem has been introduced after r338095, since r338095 builds
> ok, while
> r338096 doesn't.
338096 added this check to catch a kind of error in our Makefiles. Alex (cc'd)
can
help with figuring out what the error is.
--
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"
Re: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Mon, 20 Aug 2018 21:24:21 +0200
"O. Hartmann" schrieb:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Building NanoBSD world on CURRENT r338113 fails due to:
>
> [...]
> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde && MK_TESTS=no
> UPDATE_DEPENDFILE=no _RECURSING_CRUNCH=1
> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/sources/CURRENT/src/amd64.amd64/rescue/rescue
> make MK_AUTO_OBJ=no DIRPRFX=rescue/rescue/gbde/ -DRESCUE
> CRUNCH_CFLAGS=-DRESCUE
> MK_AUTO_OBJ=no obj make[5]:
> "/pool/sources/CURRENT/src/tools/build/mk/Makefile.boot"
> line 18: Do not include ${SRCTOP}/sys when building bootstrap tools. Copy
> the header to
> ${WORLDTMP}/legacy in tools/build/Makefile instead. Error was caused by
> Makefile
> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde] Error code 1
>
> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue
> [...]
>
>
> This problem occured during today's source updates since I was able to build
> the NanoBSD
> image I intend to build yesterday ~ r338060.
>
> What is going wrong?
It seems the problem has been introduced after r338095, since r338095 builds
ok, while
r338096 doesn't.
>
> I've set the following for NanoBSD's build and install:
>
> # BUILDWORLD ONLY
> # Options to put in make.conf during buildworld only
> CONF_BUILD='
> CFLAGS=-O3 -pipe
> MALLOC_PRODUCTION=YES
> INSTALL_NODEBUG=YES
> '
> # Options to put in make.conf during installworld only
> CONF_INSTALL='
> WITHOUT_TOOLCHAIN=YES
> WITHOUT_CROSS_COMPILER=YES
> WITHOUT_DOCCOMPRESS=YES
> WITHOUT_INSTALLLIB=YES
> WITHOUT_BINUTILS=YES
> #
> #WITHOUT_ACCT=YES
> WITHOUT_AMD=YES
> WITHOUT_APM=YES
> WITHOUT_ASSERT_DEBUG=YES
> WITHOUT_AT=YES
> WITHOUT_ATM=YES
> WITHOUT_BHYVE=YES
> WITHOUT_BLUETOOTH=YES
> WITHOUT_BOOTPARAMD=YES
> WITHOUT_BOOTPD=YES
> WITHOUT_BSDINSTALL=YES
> #WITHOUT_BSD_CPIO=YES
> #WITHOUT_BSNMP=YES
> #WITHOUT_BZIP2=YES
> WITHOUT_CALENDAR=YES
> #WITHOUT_CCD=YES
> WITHOUT_CDDL=YES
> WITHOUT_CLANG_FULL=YES
> WITHOUT_CTM=YES
> #WITHOUT_CUSE=YES
> WITHOUT_CXX=YES
> WITHOUT_DICT=YES
> WITHOUT_DIALOG=YES
> WITHOUT_EXAMPLES=YES
> WITHOUT_EE=YES
> WITHOUT_FINGER=YES
> WITHOUT_FLOPPY=YES
> WITHOUT_FREEBSD_UPDATE=YES
> WITHOUT_FDT=YES
> WITHOUT_GAMES=YES
> WITHOUT_GCOV=YES
> WITHOUT_GDB=YES
> WITHOUT_HAST=YES
> WITHOUT_HTML=YES
> WITHOUT_HYPERV=YES
> #WITHOUT_INET6=YES
> #WITHOUT_INETD=YES
> WITHOUT_IPFILTER=YES
> WITHOUT_ISCSI=YES
> WITHOUT_KDUMP=YES
> WITHOUT_KERNEL_SYMBOLS=YES
> #WITHOUT_LDNS=YES
> WITHOUT_LOCATE=YES
> WITHOUT_LPR=YES
> #WITHOUT_MAIL=YES
> #WITHOUT_MAILWRAPPER=YES
> #WITHOUT_MAKE=YES
> WITHOUT_MAN=YES
> WITHOUT_MAN_UTILS=YES
> WITHOUT_NDIS=YES
> #WITHOUT_NETCAT=YES
> #WITHOUT_NIS=YES
> #WITHOUT_NLS_CATALOGS=YES
> #WITHOUT_NS_CACHING=YES
> WITHOUT_NAND=YES
> WITHOUT_OFED=YES
> WITHOUT_PC_SYSINSTALL=YES
> WITHOUT_PF=YES
> WITHOUT_PKGBOOTSTRAP=YES
> WITHOUT_PMC=YES
> WITHOUT_PORTSNAP=YES
> #WITHOUT_PPP=YES
> WITHOUT_QUOTAS=YES
> WITHOUT_RBOOTD=YES
> WITHOUT_RCMDS=YES
> #WITHOUT_RESCUE=YES
> #WITHOUT_ROUTED=YES
> #WITHOUT_SENDMAIL=YES
> WITHOUT_SHAREDOCS=YES
> WITHOUT_SVNLITE=YES
> WITHOUT_TALK=YES
> #WITHOUT_TCSH=YES
> WITHOUT_TELNET=YES
> WITHOUT_TEXTPROC=YES
> WITHOUT_TFTP=YES
> #WITHOUT_WIRELESS=YES
> WITHOUT_ZFS=YES
> '
>
> # BUILD and INSTALL!
> # Options to put in make.conf during both build- & installworld.
> # See man src.conf(5) for more details on WITHOUT_ tags.
> CONF_WORLD='
> WITH_KERNEL_RETPOLINE=YES
> WITH_LLVM_TARGET_BPF=YES
> WITHOUT_TESTS=YES
> WITHOUT_TESTS_SUPPORT=YES
> WITHOUT_ASSERT_DEBUG=YES
> WITHOUT_CCD=YES
> #WITHOUT_BINUTILS_BOOTSTRAP=YES
> WITHOUT_DEBUG_FILES=YES
> #WITHOUT_ICONV=YES
> WITHOUT_ISCSI=YES
> WITHOUT_LIB32=YES
> #WITHOUT_LLVM_TARGET_ALL=YES
> WITH_ZONEINFO_LEAPSECONDS_SUPPORT=YES
> WITHOUT_SVN=YES
> WITH_SORT_THREADS=YES
> WITH_EXTRA_TCP_STACKS=YES
> #
> INSTALL_NODEBUG=YES
> '
>
>
>
> - --
> O. Hartmann
>
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
> -BEGIN PGP SIGNATURE-
>
> iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3sVgAAKCRDS528fyFhY
> lL4MAgCaS8UeE6FwJIeUa5Q+9hf80DJkde+oopttIL2Jz9LcbN1CRU5JTc2jJ9Vb
> vO380RVTNO4M0Ge0M0m2wDCx4xzuAf9YYdjW/xTXbh09YcTlt3l22pn1aaHYrdMk
> pOYA3FUw8xi09cniyQHBOr4mvjKI07GtgLKTEINU3SuS9CmFjCzg
> =vFP+
> -END PGP SIGNATURE-
> ___
> 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"
- --
O. Hartmann
Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-
iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3sd/wAKCRDS528fyFhY
lM7PAf4oZ05VCbM8DZXqUz23f/eYlU57DOTJRmHrC7PUisD8GR4YananlyvtmCz/
H40KXUxsg2820cVv5n6
Re: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found
On Tue, Apr 10, 2018, Kristof Provost wrote: > On 9 Apr 2018, at 13:10, Vladimir Zakharov wrote: > > On Mon, Apr 09, 2018, Kristof Provost wrote: > > > On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote: > > > > > > For several days buildworld fails for me with the following > > > error. Cleaning > > > and > > > rebuilding didn't help. > > > > > > ===> tests/sys/netpfil/pf/ioctl (all) > > > --- validation --- > > > (cd /usr/src/tests/sys/netpfil/pf/ioctl && > > > DEPENDFILE=.depend.validation > > > NO_SUBDIR=1 make -f /usr/src/tests/sys/netpfil/pf/ioctl/Makefile > > > _RECURSING_PROGS=t PROG=validation ) > > > Building > > > /home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/ > > > validation.o > > > --- validation.o --- > > > In file included from > > > /usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35: > > > /home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10: > > > fatal > > > error: 'netpfil/pf/pf.h' file not found > > > #include > > > ^ > > It should be fully fixed as of r332358. > Thanks for the report. Works for me. Thanks. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra ___ 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: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found
On 9 Apr 2018, at 13:10, Vladimir Zakharov wrote: On Mon, Apr 09, 2018, Kristof Provost wrote: On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote: For several days buildworld fails for me with the following error. Cleaning and rebuilding didn't help. ===> tests/sys/netpfil/pf/ioctl (all) --- validation --- (cd /usr/src/tests/sys/netpfil/pf/ioctl && DEPENDFILE=.depend.validation NO_SUBDIR=1 make -f /usr/src/tests/sys/netpfil/pf/ioctl/Makefile _RECURSING_PROGS=t PROG=validation ) Building /home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/ validation.o --- validation.o --- In file included from /usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35: /home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10: fatal error: 'netpfil/pf/pf.h' file not found #include ^ It should be fully fixed as of r332358. Thanks for the report. Regards, Kristof ___ 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: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found
On Mon, Apr 09, 2018, Kristof Provost wrote:
> On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote:
>
> For several days buildworld fails for me with the following error.
> Cleaning
> and
> rebuilding didn't help.
>
> ===> tests/sys/netpfil/pf/ioctl (all)
> --- validation ---
> (cd /usr/src/tests/sys/netpfil/pf/ioctl && DEPENDFILE=.depend.validation
> NO_SUBDIR=1 make -f /usr/src/tests/sys/netpfil/pf/ioctl/Makefile
> _RECURSING_PROGS=t PROG=validation )
> Building /home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/
> validation.o
> --- validation.o ---
> In file included from /usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35:
> /home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10: fatal
> error: 'netpfil/pf/pf.h' file not found
> #include
> ^
> 1 error generated.
> *** [validation.o] Error code 1
>
> make[8]: stopped in /usr/src/tests/sys/netpfil/pf/ioctl
>
>
> My /etc/src.conf (I have PF switched off):
>
> Ah, that’s my fault. I didn’t consider people who’d switch off pf when I added
> the new ioctl tests.
>
> You can work around the issue by removing the new tests yourself, or by
> building pf in anyway (it won’t do anything unless you load the module and
> activate it).
>
> This should be a workaround for you until I can commit a better fix:
>
> diff --git a/tests/sys/netpfil/pf/Makefile b/tests/sys/netpfil/pf/Makefile
> index c055e6840bd..259e1275d9c 100644
> --- a/tests/sys/netpfil/pf/Makefile
> +++ b/tests/sys/netpfil/pf/Makefile
> @@ -3,7 +3,6 @@
> PACKAGE= tests
>
> TESTSDIR= ${TESTSBASE}/sys/netpfil/pf
> -TESTS_SUBDIRS+=ioctl
>
> ATF_TESTS_SH+= pass_block \
> forward \
Thanks. I've applied this fix for now and managed to update.
--
Regards, | "In theory there is no difference between theory
Vladimir Zakharov | and practice. In practice there is."- Yogi Berra
___
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: buildworld fails: fatal error: 'netpfil/pf/pf.h' file not found
On 9 Apr 2018, at 10:50, Vladimir Zakharov wrote:
For several days buildworld fails for me with the following error.
Cleaning and
rebuilding didn't help.
===> tests/sys/netpfil/pf/ioctl (all)
--- validation ---
(cd /usr/src/tests/sys/netpfil/pf/ioctl &&
DEPENDFILE=.depend.validation NO_SUBDIR=1 make -f
/usr/src/tests/sys/netpfil/pf/ioctl/Makefile _RECURSING_PROGS=t
PROG=validation )
Building
/home/obj/usr/src/amd64.amd64/tests/sys/netpfil/pf/ioctl/validation.o
--- validation.o ---
In file included from
/usr/src/tests/sys/netpfil/pf/ioctl/validation.c:35:
/home/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:49:10: fatal
error: 'netpfil/pf/pf.h' file not found
#include
^
1 error generated.
*** [validation.o] Error code 1
make[8]: stopped in /usr/src/tests/sys/netpfil/pf/ioctl
My /etc/src.conf (I have PF switched off):
Ah, that’s my fault. I didn’t consider people who’d switch off pf
when I added the new ioctl tests.
You can work around the issue by removing the new tests yourself, or by
building pf in anyway (it won’t do anything unless you load the module
and activate it).
This should be a workaround for you until I can commit a better fix:
diff --git a/tests/sys/netpfil/pf/Makefile
b/tests/sys/netpfil/pf/Makefile
index c055e6840bd..259e1275d9c 100644
--- a/tests/sys/netpfil/pf/Makefile
+++ b/tests/sys/netpfil/pf/Makefile
@@ -3,7 +3,6 @@
PACKAGE= tests
TESTSDIR= ${TESTSBASE}/sys/netpfil/pf
-TESTS_SUBDIRS+=ioctl
ATF_TESTS_SH+= pass_block \
forward \
Regards,
Kristof
___
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: Buildworld failing during llvm
On 18 February 2018 at 09:52, Ben Woods wrote: > Hi everyone, > > My attempts to build FreeBSD 12-current have been failing as of yesterday > with the error below. This problem persists with current at the time of > writing this email (r329497). > > Given llvm was updated to 6.0 around that time, I suspect it is related: > https://svnweb.freebsd.org/base?view=revision&revision=329410 > > > --- clang.full --- > c++ -O2 -pipe -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang > -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm > -I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include > -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL > -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS > -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" > -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" > -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" > -ffunction-sections -fdata-sections -g -O0 -Qunused-arguments > -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -std=c++11 > -fno-exceptions -fno-rtti -g -O0 -stdlib=libc++ -Wno-c++11-extensions > -Wl,--gc-sections -static -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib > -o clang.full cc1_main.o cc1as_main.o driver.o > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang/libclang.a > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz -lz > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/ncurses/ncursesw > -lncursesw -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libthr > -lpthread -legacy > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a: > could not read symbols: Malformed archive > c++: error: linker command failed with exit code 1 (use -v to see > invocation) > *** [clang.full] Error code 1 > > > Regards, > Ben > > -- > From: Benjamin Woods > woods...@gmail.com > I found this issue was caused by having the following line in my /etc/make.conf (which I had there for some ports debugging): DEBUG_FLAGS=-g -O0 I wouldn't have thought this should cause the clang build to fail... Regards, Ben -- From: Benjamin Woods woods...@gmail.com ___ 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: Buildworld failing during llvm
On 18 Feb 2018, at 02:52, Ben Woods wrote: > > My attempts to build FreeBSD 12-current have been failing as of yesterday > with the error below. This problem persists with current at the time of > writing this email (r329497). > > Given llvm was updated to 6.0 around that time, I suspect it is related: > https://svnweb.freebsd.org/base?view=revision&revision=329410 > > > --- clang.full --- > c++ -O2 -pipe > -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang > -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm > -I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include > -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL > -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS > -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" > -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" > -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -ffunction-sections > -fdata-sections -g -O0 -Qunused-arguments > -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -std=c++11 > -fno-exceptions -fno-rtti -g -O0 -stdlib=libc++ -Wno-c++11-extensions > -Wl,--gc-sections -static -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib > -o clang.full cc1_main.o cc1as_main.o driver.o > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang/libclang.a > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz -lz > -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/ncurses/ncursesw > -lncursesw -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libthr > -lpthread -legacy > /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a: > could not read symbols: Malformed archive Hi Ben, This is most likely because you are setting CFLAGS to "-g -O0", which causes libllvm.a and libclang.a to become too big (>2GiB) for ar to handle. Then the linker finds the archive malformed. John Baldwin added some special handling for libraries under lib/clang, so they emit smaller debug information, so just leave out -g from your CFLAGS, buildworld will automatically take care of applying the right -g flags in all the various places. -Dimitry signature.asc Description: Message signed with OpenPGP
