updating x11-base/xorg-server-1.7.7-r1 causes ebuild to enter endless loop of: libtool: compile: Waiting for --shave-mode=compile.o.lock to be removed Reproducible: Always Steps to Reproduce: 1. emerge x11-base/xorg-server-1.7.7-r1 Actual Results: Making all in doc Making all in include Making all in dix libtool: compile: Waiting for --shave-mode=compile.o.lock to be removed libtool: compile: Waiting for --shave-mode=compile.o.lock to be removed ... Expected Results: successful build
Please attach the full build log and emerge --info =x11-base/xorg-server-1.7.7-r1 output. Thank you.
Created attachment 244409 [details] build.log
Created attachment 244411 [details] emerge --info x11-base/xorg-server
Created attachment 244413 [details] environment
I apologize for not having the information immediately available, I filed another unrelated bug around the same time and forgot to attend to this one.
Please try with distcc disabled. Thanks
I turned the distcc off and emerged and it worked. Thank you. . What can be done to identify what caused the problem for distcc? It seems that since the emerged worked without distcc then there is a problem with distcc that needs to be identified and addressed. Is there a team that oversees distcc and should this bug be assigned to them? I can provide ebuild information (using preserve) on the build process that can be analyzed and compared if desired.
Reopening
Reassigning. Thanks
Hi, I don't think this issue is particular to xorg, I encountered it for a lot of package (but it was when doing OpenEmbedded builds, not even Gentoo). It seems that libtool doesn't like it when gcc writes to stderr when doing configuration tests, and this can happen with distcc... this can lead to issues when running conftests (I have seen yesterday that printing to stderr (eg. DISTCC_VERBOSE=1 during -fPIC -DPIC tests would cause libraries to not use PIC...) or when compiling stuff (for some reason the "shave" macros, used by some packages has this issue). Probably libtool developers figured out that checking for gcc return code wasn't enough... and wanted to ensure that nothing goes on stderr too. That sounds stupid, but that's what is happening.