Created attachment 881790 [details] emerge --info When building (e.g.) www-servers/apache-2.4.58-r2, compile job goes into infinite loop, with line after line of output showing "libtool: compile: Waiting for unixd.o.lock to be removed" I found lots of really old bugs for a variety of packages with similar "libtool infinite loop" symptoms, and as in some of those cases, this happens for me only if PORTAGE_TMPDIR is not on the root partition. This is not happening on all of my machines - only on my ASUS tinkerboard-s (armv7l). emerge --info output is attached. Work arounds: (1) create /root/portage_tmpdir and modify /etc/portage/make.conf to point at it PORTAGE_TMPDIR="/root/portage_tmpdir" (2) create a per-package rule, for example /etc/portage/env/portage_tmpdir_on_rootfs.conf with contents -- PORTAGE_TMPDIR="/root/portage_tmpdir" where the indicated directory (owned by portage) looks like this -- drwxrwxrwt 4 portage portage 4096 Nov 5 09:28 portage_tmpdir and /etc/portage/package.env/package.env contains ... www-servers/apache portage_tmpdir_on_rootfs.conf ... Today's result with workaround #2: >>> www-servers/apache-2.4.58-r2 merged. >>> Completed (1 of 1) www-servers/apache-2.4.58-r2::gentoo Otherwise, here is today's build-failure output (without the workaround):
Build failure output is appended to attachment, following emerge --info output
What type of filesystem does PORTAGE_TMPDIR live on? Please share your mount table.
I suspect the copy of libtool installed by dev-libs/apr might be broken on your system. Specifically, need_locks is set to "yes" when it should be "no". Please attach /usr/share/apr/build/libtool so I can confirm this. Assuming that is the case, please rebuild dev-libs/apr and attach the resulting build log. I am looking for a line that looks like this, but with "no" in place of "yes". > checking if x86_64-pc-linux-gnu-gcc supports -c -o file.o... rm: cannot remove 'conftest*': No such file or directory > yes
Please also attach config.log if you rebuild dev-libs/apr and get "no" for a result from that configure check.
Mount table as requested -- # mount /dev/mmcblk0p2 on / type ext4 (rw,noatime) devtmpfs on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=10240k,nr_inodes=84975,mode=755) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) tmpfs on /run type tmpfs (rw,nosuid,nodev,size=188596k,nr_inodes=819200,mode=755) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime) configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) none on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime) /dev/mmcblk0p1 on /boot type vfat (rw,nosuid,nodev,noexec,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
(In reply to Mike Gilbert from comment #2) > What type of filesystem does PORTAGE_TMPDIR live on? Please share your mount > table. Answer: ext4 Most recent instance of this error is on arm system using the following simple /etc/fstab -- PARTUUID=129fa078-01 /boot vfat noatime,noauto,nodev,nosuid,noexec 1 2 PARTUUID=129fa078-02 / ext4 noatime 0 1 /var/cache/swap/swap1 none swap sw 0 0
Created attachment 884428 [details] /usr/share/apr/build/libtool attached as requested /usr/share/apr/build/libtool attached as requested
(In reply to Joe from comment #7) > Created attachment 884428 [details] > /usr/share/apr/build/libtool attached as requested > # Must we lock files when doing compilation? > need_locks="yes" Yep, this is broken.
Please build dev-libs/apr with FEATURES="keepwork", and then attach this file: /var/tmp/portage/dev-libs/apr-1.7.4-r1/work/apr-1.7.4/config.log
Created attachment 884469 [details] /var/tmp/portage/dev-libs/apr-1.7.4-r1/work/apr-1.7.4/config.log archived with "tar cvjpf config.log.tbz2 config.log" Note: running emerge -av1 dev-libs/apr completes without error, but dev-libs/apr enters infinite loop when compiled as a dependency of www-servers/apache. So, trying to complete your request by running FEATURES="keepwork" emerge -av1 www-servers/apache failed --The error looks like this -- ... libtool: compile: Waiting for apr_brigade.o.lock to be removed libtool: compile: Waiting for apr_buckets.o.lock to be removed libtool: compile: Waiting for apr_buckets_alloc.o.lock to be removed libtool: compile: Waiting for apr_buckets_eos.o.lock to be removed libtool: compile: Waiting for apr_buckets_file.o.lock to be removed ... but this did not produce the file requested... cat: /var/tmp/portage/dev-libs/apr-1.7.4-r1/work/apr-1.7.4/config.log: No such file or directory I'm not sure it be helpful, because the problem does not occur when compiling apr directly, but I also ran FEATURES="keepwork -distcc" emerge -av1 dev-libs/apr --> (>>> Completed (1 of 1) dev-libs/apr-1.7.4-r1::gentoo) and I've attached /var/tmp/portage/dev-libs/apr-1.7.4-r1/work/apr-1.7.4/config.log Note also a correction to my initial report. The entire rootfs of this armv7a system is on one partition (only the bootfs is on another partition - kernel, bootloader configuration). So while my work-arounds did work previously, it was not because it was moving portage_tmpdir to the rootfs partition... Currently, this error occurs when compiling www-servers/apache regardless of portage_tmpdir location
I didn't realize distcc was in play at all here. That is a likely source of the problem. You said this config.log was generated with FEATURES="-distcc", but I see many distcc calls in the log. I'm not sure we are looking at the right file. In any case, the config.log file does contain this test result: > configure:17213: checking if armv7a-unknown-linux-gnueabihf-gcc supports -c -o file.o > configure:17261: result: no That "no" is supposed to be a "yes". I suspect distcc is causing this breakage. Given how broken distcc is, I have no interest in troubleshooting this.
Just reading through the relevant configure test, it will conclude that the compiler does not support "-c -o" if the command generates any unexpected output on stderr. It looks like you have distcc set up to log verbosely, which likely causes unexpected output on stderr. If you can configure distcc to operate silently, I suspect this problem will be resolved.
Created attachment 884567 [details] Output of # FEATURES="keepwork" emerge -av1 dev-libs/apr-util distcc removed entirely, the problem persists. Also now have similar problem on another armv7 system (raspberry pi 2 b) with no distcc. So, no distcc output on stderr or elsewhere, this most recent failure of www-servers/apache occurred during compile of dependency dev-libs/apr-util. Trying direct-compile of apr-util, I still get the same infinite loop failure. Output attached
also looked for but could not find a residual config.log file from keepwork for in /var/tmp/portage/dev-libs/apr-util-1.6.3/ tree...
OK. I discovered that the broken libtool referred to in Comments 3 and 8 was still in place. (/usr/share/apr/build/libtool containing "> # Must we lock files when doing compilation? > need_locks="yes" ) Which was possibly (though I don't know for certain) broken by a ***previous*** install attempt while distcc was still "on." So, I rolled back with -- emerge -avC www-servers/apache dev-libs/apr dev-libs/apr-util Then I confirmed there was no longer a /usr/share/apr/build/libtool present on the system, and then I did a fresh apache install with -- emerge -av1 www-servers/apache ... which completed with no error, installing in order -- dev-libs/apr-1.7.4-r1 dev-libs/apr-util-1.6.3 app-admin/apache-tools-2.4.58 www-servers/apache-2.4.58-r2 Issue resolved
Closing this as a duplicate. *** This bug has been marked as a duplicate of bug 40992 ***
