Excerpts from Stefan Schulze Frielinghaus's message of Dezember 3, 2025 3:03 pm: > From: Stefan Schulze Frielinghaus <[email protected]> > > While experimenting with a new warning, I was running into build errors > for libphobos as e.g. > > libtool: compile: mv -f "atomic.o" "core/.libs/atomic.o" > mv: cannot stat 'atomic.o': No such file or directory > > or when building libgo like > > libtool: compile: mv -f "tables.o" ".libs/unicode.o" > mv: cannot stat 'tables.o': No such file or directory > > These boil down to the fact that test _LT_COMPILER_C_O evaluates to "no" > for those, i.e., we have > > lt_cv_prog_compiler_c_o=yes > lt_cv_prog_compiler_c_o_D=no > > likewise > > lt_cv_prog_compiler_c_o=yes > lt_cv_prog_compiler_c_o_GO=no > > and at the same time _LT_ENABLE_LOCK/need_locks evaluates to "no" which > breaks parallel builds due to races on those files. Although I think > for a parallel build need_locks should be rather set to "yes" in case > _LT_COMPILER_C_O evaluates to "no", this patch enables a parallel build > without the need of locks. > > _LT_COMPILER_C_O evaluates to "no" in the first place because > boilerplate is computed with a different CC when it is compared to. > When boilerplate is computed, CC equals xgcc which means we emit > warnings of the form > > xgcc: warning: ... > d21: warning: ... > > whereas when we compute _LT_COMPILER_C_O, CC is changed shortly before > to gdc so we end up with warnings of the form > > gdc: warning: ... > d21: warning: ... > > which ultimately means the check whether the warning is expected fails > and we do not set _LT_COMPILER_C_O to "yes". > > Fixed by moving the computation of boilerplate after setting CC to > gdc/gccgo. > > PR d/122794 >
Hi, OK for libphobos part of patch. Thanks, Iain.
