Example of Bryan Drewery's "Something is very wrong" (from his disabling head/Makefile)?: obj-cross-tools path referenced but file is under obj-bootstrap-tools
Mark Millard
markmi at dsl-only.net
Fri Nov 3 03:38:20 UTC 2017
[The rebuilding is not your problem. . . Its a
file system time problem.]
On 2017-Nov-2, at 8:16 PM, Mark Millard <markmi at dsl-only.net> wrote:
> On 2017-Nov-2, at 8:08 PM, Bryan Drewery <bdrewery at FreeBSD.org> wrote:
>
>> On 11/2/2017 7:47 PM, Mark Millard wrote:
>>> [Top post as it does not flow with the prior material.]
>>>
>>> Back-to-back repeats of the same buildworld buildkernel
>>> command are rebuilding lots of obj-lib32 *.o files and
>>> the like each time under WITH_META_MODE=yes for -r325351.
>>>
>>
>> I think it is expected since I had to change the objdirs for build/cross
>> tools again to fix your report.
>
> FYI: that was after several prior builds with -r325351. It is
> not just a first-repeat example.
>
>> I am very confused how I never hit the issue you and Matt ran into. I
>> had this commit sitting in my test branch for days. It may just be due
>> to SYSTEM_COMPILER getting triggered. There's so many combinations of
>> options in the early build that it's impossible to test all of them.
>
> I had WITH_META_MODE=yes as I normally do but had done
> the rm -fr of the tree content as well (because of
> directory tree structure mismatches that would be in
> the new build).
>
>> Anyway if it continues to happen please also pass -dM to your make as it
>> will tell us why it is rebuilding.
>
> I'm about to try that.
It reported a more up-to-date file.
But looking the timestamp was in the future (tomorrow,
almost 24 hours away):
# ls -lT /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/runetype.h
-rwxr-xr-x 1 root wheel 3906 Nov 3 20:13:14 2017 /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/runetype.h
Apparently one or more of the times when I booted the
virtual machine recently it ended up with a bad time
and part of at least /usr/include has the problem with
timestamps:
# ls -lT /usr/include/runetype.h
-r--r--r-- 1 root wheel 3906 Nov 3 22:48:30 2017 /usr/include/runetype.h
(The time for the active boot is fine.)
Sorry for the noise.
>>> Script started on Thu Nov 2 18:34:57 2017
>>> Command: env __MAKE_CONF=/root/src.configs/make.conf SRCCONF=/dev/null SRC_ENV_CONF=/root/src.configs/src.conf.amd64-clang.amd64-host WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/amd64_clang/amd64.amd64 make -j4 buildworld buildkernel
>>>
>>> vs.
>>>
>>> Script started on Thu Nov 2 18:34:57 2017
>>> Command: env __MAKE_CONF=/root/src.configs/make.conf SRCCONF=/dev/null SRC_ENV_CONF=/root/src.configs/src.conf.amd64-clang.amd64-host WITH_META_MODE=yes MAKEOBJDIRPREFIX=/usr/obj/amd64_clang/amd64.amd64 make -j4 buildworld buildkernel
>>>
>>>
>>> # svnlite status -u -r325351 /usr/src | sort
>>> * 320623 /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h
>>> ? /usr/src/sys/amd64/conf/GENERIC-DBG
>>> ? /usr/src/sys/amd64/conf/GENERIC-NODBG
>>> ? /usr/src/sys/arm/conf/GENERIC-DBG
>>> ? /usr/src/sys/arm/conf/GENERIC-NODBG
>>> ? /usr/src/sys/arm64/conf/GENERIC-DBG
>>> ? /usr/src/sys/arm64/conf/GENERIC-NODBG
>>> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG
>>> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG
>>> ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG
>>> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG
>>> M 325351 /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
>>> M 325351 /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
>>> M 325351 /usr/src/crypto/openssl/crypto/armcap.c
>>> M 325351 /usr/src/lib/libkvm/kvm_powerpc.c
>>> M 325351 /usr/src/lib/libkvm/kvm_private.c
>>> M 325351 /usr/src/sys/arm/allwinner/aw_usbphy.c
>>> M 325351 /usr/src/sys/arm64/arm64/identcpu.c
>>> M 325351 /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi
>>> M 325351 /usr/src/sys/boot/ofw/Makefile.inc
>>> M 325351 /usr/src/sys/boot/powerpc/Makefile.inc
>>> M 325351 /usr/src/sys/boot/powerpc/boot1.chrp/Makefile
>>> M 325351 /usr/src/sys/boot/powerpc/kboot/Makefile
>>> M 325351 /usr/src/sys/boot/uboot/Makefile.inc
>>> M 325351 /usr/src/sys/conf/kmod.mk
>>> M 325351 /usr/src/sys/conf/ldscript.powerpc
>>> M 325351 /usr/src/sys/kern/subr_pcpu.c
>>> M 325351 /usr/src/sys/powerpc/aim/mmu_oea64.c
>>> M 325351 /usr/src/sys/powerpc/ofw/ofw_machdep.c
>>> M 325351 /usr/src/sys/powerpc/powerpc/interrupt.c
>>> M 325351 /usr/src/sys/powerpc/powerpc/mp_machdep.c
>>> M 325351 /usr/src/sys/powerpc/powerpc/trap.c
>>>
>>>
>>> --------------------------------------------------------------
>>>>>> stage 5.1: building lib32 shim libraries
>>> --------------------------------------------------------------
>>> . . .
>>> --- obj ---
>>> --- lib/libgcc_eh__PL ---
>>> Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/lib/libgcc_eh/libunwind.o
>>> --- gnu/lib/libssp/libssp_nonshared__PL ---
>>> Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/gnu/lib/libssp/libssp_nonshared/_libinstall
>>> . . .
>>> . . .
>>>
>>> And so on.
>>
>> ===
>> Mark Millard
>> markmi at dsl-only.net
>>
>> On 2017-Nov-2, at 5:30 PM, Bryan Drewery <bdrewery at FreeBSD.org> wrote:
>>
>> On 11/2/17 3:44 PM, Mark Millard wrote:
>>>> Author: bdrewery
>>>> Date: Thu Nov 2 22:23:00 2017
>>>> New Revision: 325347
>>>> URL:
>>>> https://svnweb.freebsd.org/changeset/base/325347
>>>>
>>>>
>>>> Log:
>>>> Something is very wrong
>>>>
>>>> Modified:
>>>> head/Makefile
>>>>
>>>> Modified: head/Makefile
>>>> ==============================================================================
>>>> --- head/Makefile Thu Nov 2 21:58:18 2017 (r325346)
>>>> +++ head/Makefile Thu Nov 2 22:23:00 2017 (r325347)
>>>> @@ -1,3 +1,4 @@
>>>> +.error Bad revision, please wait for a fix in head
>>>> #
>>>> # $FreeBSD$
>>>> #
>>>
>>> I just happened to have started a cross build before
>>> this showed up based on -r325332 . It got:
>>>
>>> --- clang-tblgen.full ---
>>> c++: error: no such file or directory: '/usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/clang/libllvmminimal/libllvmminimal.a'
>>> *** [clang-tblgen.full] Error code 1
>>
>> Someone else reported this one as well but I have not been able to
>> reproduce it yet.
>>
>> I've tweaked the commit causing it though, r325329. Fixed in r325350.
>>
>>>
>>> But find shows:
>>>
>>> # find /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7 -name "libllvmminimal*" -print | more
>>> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal
>>> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal/libllvmminimal.a
>>> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal/libllvmminimal.a.meta
>>>
>>> Comparing side-by-side shows obj-cross-tools vs.
>>> obj-bootstrap-tools :
>>>
>>> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/clang/libllvmminimal/libllvmminimal.a
>>> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal/libllvmminimal.a
>>>
>>>
>>> ===
>>> Mark Millard
>>> markmi at dsl-only.net
>>>
>>
>>
>
===
Mark Millard
markmi at dsl-only.net
More information about the freebsd-hackers
mailing list