Le 05/01/2020 à 05:37, Bruce Dubbs a écrit : > On 1/4/20 7:45 PM, Ken Moffat wrote: >> On Sat, Jan 04, 2020 at 05:11:18PM -0500, Scott Andrews wrote: >>> >>> On 1/4/20 1:45 PM, Flareon Zulu wrote: >>>> >>>> On January 4, 2020, at 09:47, Scott Andrews >>>> <scott.andr...@columbus.rr.com> wrote: >>>> >>>>> Anyone have this error? >>>>> ar cr libgrep.a glthread/lock.o glthread/threadlib.o kwset.o m-fgrep.o >>>>> m-regex.o mbrlen.o regex.o >>>>> ranlib libgrep.a >>>>> make[3]: Leaving directory >>>>> '/mnt/lfs/source/gettext-0.20.1/gettext-tools/libgrep' >>>>> Making all in src >>>>> here=`pwd`; \ >>>>> cd ../../libtextstyle/lib && \ >>>>> /usr/bin/make install-nobase_includeHEADERS >>>>> install-nobase_nodist_includeHEADERS includedir="$here" >>>>> make[3]: *** No rule to make target 'install-nobase_includeHEADERS'. >>>> Stop. >>>>> make[2]: *** [Makefile:3955: textstyle.h] Error 2 >>>>> make[1]: *** [Makefile:2173: all-recursive] Error 1 >>>>> make: *** [Makefile:2041: all] Error 2 >>>>> Didn't see anything on the list about this >>>>> Gettext-0.19.8.1 is ok >>>>> -- >> >>>> >>>> Especially in light of this: https://savannah.gnu.org/bugs/?56333 >>>> >>>> It seems there could be an issue with build order, essentially. I didn't >>>> have an issue, but some people online have had this happen, they're just >>>> not on this list. >>>> >>>> Flareon Zulu >>>> >>> Could very well be, I will follow up on the link you posted and see if I >>> caqn make sense in it. >>> >>> >> The usual workaround for what that sounds like is "make -j1". >> Apologies if you are already doing that. My most recent example of >> that was in bison on a Skylake (an i3 so I'd been running make -j4 : >> perhaps -j3 or -j2 might have sufficed). On other machines (haswell >> i7, ryzen 3400G) make -j8 was fine. Modern CPUs can be a pain. >> >> And that is another thing to learn from LFS - ISTR that dropping >> back to -j1 in case of problems is mentioned in the FAQ. > > In section 4.5. About SBUs, the last sentence in the note: > > "If you run into a problem with a build step, revert back to a single > processor build to properly analyze the error messages." > > This may be the cause of the error, but I think it is unlikely. The last > release of gettext was in May and we certainly would have run into the problem > before this if it has a race condition. >
Hmmm, in our automated build (jhalfs), gettext used to be blacklisted for optimizations (means it was compiled with make -j1), until December 21st, when I've removed blacklist in jhalfs. I've built several times since then at -j8 on a Haswell, so gettext can be compilled at -j8 on that CPU, but maybe, as Ken mentioned, modern CPU's could do something different... If there is more evidence that there is a race condition in gettext, I'll blacklist it again. Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
