On Feb 21, 2023, at 11:56, Mark Millard <mark...@yahoo.com> wrote: > On Feb 21, 2023, at 04:55, Peter <p...@citylink.dinoex.sub.org> wrote: > >> On Mon, Feb 20, 2023 at 08:44:59PM -0800, Mark Millard wrote: >> ! Peter <pmc_at_citylink.dinoex.sub.org> wrote on >> ! Date: Tue, 21 Feb 2023 03:45:12 UTC : >> ! >> ! > on /some/ of my nodes, META_MODE seems not being honored anymore: >> ! > I had to build them another time, and the lengthy lib/clang gets >> ! > built all over again (tried two times). >> ! > This is so since 13.2 (BETA2). It did work in 13.1 (RELENG), at least >> ! > according to the timing from the logfiles. >> ! > >> ! > Now I'm trying to figure out the difference, because I have some >> ! > nodes where it appears to more-or-less work (have seen buildworld >> ! > take 5 minutes), and others where it doesn't (take an hour to build). >> ! > The thing is scripted, so it is not so very likely an operator error >> ! > (while not impossible either). >> ! > >> ! > But it seems difficult to figure out details: "make -n" seems to not >> ! > care about META_MODE, while META_MODE suppresses all useful output from >> ! > make. And the docs say there are *.meta files (yes there are), but no >> ! > info about how to verify their content, or how to get make tell what >> ! > it is going to do and why (and the buildworld is not the most easy >> ! > to understand target)... >> ! > >> ! > So, some inspiration would be welcome... >> ! >> ! On thing to check on is if filemon.ko is loaded and operational. >> ! META_MODE greatly depends on it. >> >> That should be the case - 'kldstat' shows it (and I've seen warnings >> where it didn't). >> >> ! Another thing to know is that the following are very different >> ! for what all is built for the "(again #0)" line vs. the other >> ! two "again" lines, using buildworld as an example context. >> ! Imagine here the the first buildworld rebuilds llvm/clang >> ! materials. >> ! >> ! # cd /usr/src/ >> ! # env WITH_META_MODE=yes make buildworld >> ! # env WITH_META_MODE=yes make installworld >> ! # env WITH_META_MODE=yes make buildworld (again #0) >> ! ## no more rebuilds below? >> ! # env WITH_META_MODE=yes make buildworld (again #1) >> ! # env WITH_META_MODE=yes make buildworld (again #2) >> >> But what is the difference between #0 and #1? > > awk, cp, ln, rm, sed, and many more from > . . ./tmp/legacy/usr/sbin/have new dates > for rebuilds after installworld (that targets > the running system). Not true for #1 and #2. > > The dates on these tools being more recent than > the files that they were involved in producing > leads to rebuilding those files. That in turn > leads to other files being rebuilt. > > make with -dM reports the likes of: > > file '. . ./tmp/legacy/usr/sbin/awk' is newer than the target... > > explicitly as it goes. As I remember tmp/legacy/usr/sbin/ > was always part of the path for what I found. > > One still has to trace back to were rebuild a rebuild > is not due to something rebuilt in earlier in the same > build. Noting that tmp/legacy/usr/sbin/awk is reported > as newer than its target, leaves the question of how > it ended up being newer: earlier in same build vs. > before build activity? It too must be traced back > to something based on just material from prior to > the build in question. > > Note that the above make sequence was only intended > for showing the dependency, not as instructions for a > normal update sequence. > >> . . . >> >> ! See: >> ! >> ! >> https://lists.freebsd.org/pipermail/freebsd-current/2021-January/078488.html > > This (and later messages in the thread) are about the > "awk, cp, ln, rm, sed, and many more" that make with -dM > explicitly reports (likely from tmp/legacy/usr/sbin/ ). > If you trust the make date comparisons, it is the easiest > way to find out what has "is newer than the target" status > that leads to starting a rebuild sequence. (Other dependent > things then rebuild based on this rebuild. One still has > to trace back to where things start.) > > I did not do the analysis of how (e.g.) tmp/legacy/usr/sbin/awk > ended up being newer than such a target and, so, causing a > rebuild of that target. I was going the direction: that > it is newer really is unlikely to justify the rebuild for > the target(s) in question. The other direction about how > it got to be newer is also relevant.
Using awk as an example, for the (re)build of awk in: /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/usr.bin/awk/ in my context, here is a list of files that installworld installs that contribute to the build (and a couple of "Fork" lines): (from /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/usr.bin/awk/awk.full.meta ) E 51580 /bin/sh R 51580 /etc/libmap.conf R 51580 /usr/local/etc/libmap.d R 51580 /usr/local/etc/libmap.d/mesa.conf R 51580 /var/run/ld-elf.so.hints R 51580 /lib/libedit.so.8 R 51580 /lib/libc.so.7 R 51580 /lib/libtinfow.so.9 R 51580 /usr/share/locale/C.UTF-8/LC_CTYPE F 51580 51585 E 51585 /usr/bin/cc R 51585 /etc/libmap.conf R 51585 /usr/local/etc/libmap.d R 51585 /usr/local/etc/libmap.d/mesa.conf R 51585 /var/run/ld-elf.so.hints R 51585 /lib/libz.so.6 R 51585 /usr/lib/libexecinfo.so.1 R 51585 /lib/libncursesw.so.9 R 51585 /lib/libtinfow.so.9 R 51585 /lib/libthr.so.3 R 51585 /lib/libc++.so.1 R 51585 /lib/libcxxrt.so.1 R 51585 /lib/libm.so.5 R 51585 /lib/libc.so.7 R 51585 /lib/libelf.so.2 R 51585 /lib/libgcc_s.so.1 F 51585 51607 E 51607 /usr/bin/ld R 51607 /etc/libmap.conf R 51607 /usr/local/etc/libmap.d R 51607 /usr/local/etc/libmap.d/mesa.conf R 51607 /var/run/ld-elf.so.hints R 51607 /usr/lib/libexecinfo.so.1 R 51607 /lib/libtinfow.so.9 R 51607 /lib/libz.so.6 R 51607 /lib/libthr.so.3 R 51607 /lib/libc++.so.1 R 51607 /lib/libcxxrt.so.1 R 51607 /lib/libm.so.5 R 51607 /lib/libc.so.7 R 51607 /lib/libelf.so.2 R 51607 /lib/libgcc_s.so.1 So, any of those getting new dates are examples of how installworld can lead to the following buildworld creating an updated (installation place): /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/usr/sbin/awk ( sbin/ is really a symbolic link to ../bin/ ). That in turn leads to various other things being rebuilt that had awk involved. (This was a partial summary as, for example, there could be local .o files involved with dependencies not noted above but that contribute to whatever example program is picked.) >> ! >> ! and: >> ! >> ! https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257616 . >> >> Thank You, that's exactly the inspiration I was looking for! >> Diving back in... > === Mark Millard marklmi at yahoo.com
