https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: net-fs/openafs-1.8.8.1-r1 fails to compile. Discovered on: amd64 (internal ref: ci) NOTE: If you think this is a GCC-11 related issue, please block bug 732706.
Created attachment 758688 [details] build.log.xz build log and emerge --info (compressed because it exceeds attachment limit, use 'xzless' to read it)
I can't reproduce this problem, but my guess that this is a parallel build issue (and I don't have hardware even close to -j43 to reproduce). Could you please try with -j1 in the same environment?
Created attachment 758714 [details, diff] openafs-afsint.patch Please test the following patch. It is suitable to be put into /etc/portage/patches/net-fs/openafs/ . I can only test that it does not break working build. Also similar issues may be in another places: the codebase is vast.
(In reply to Andrew Savchenko from comment #2) > I can't reproduce this problem, but my guess that this is a parallel build > issue (and I don't have hardware even close to -j43 to reproduce). > > Could you please try with -j1 in the same environment? I can reproduce also with -j1 but only when sys-devel/binutils-config and sys-devel/gcc-config are built with USE="-native-symlinks"
There are many problems here: 1) CC, LD and OBJDUMP are not passed to kernel's Makefile during module build. This is easy to fix. 2) Somehow generated code is different depending on whether we have native symlinks or not. I haven't figured out why this happens yet.
(In reply to Andrew Savchenko from comment #3) > Created attachment 758714 [details, diff] [details, diff] > openafs-afsint.patch > > Please test the following patch. It is suitable to be put into > /etc/portage/patches/net-fs/openafs/ . I can only test that it does not > break working build. > > Also similar issues may be in another places: the codebase is vast. KDUMP has been removed from upstream master. It's beyond broken on several platforms and hasn't worked for years (see https://gerrit.openafs.org/#/c/14623 ). There's current discussion within the openafs release-team on when it gets removed from stable the stable branch.
Oops.. replied too soon without looking more closely (I saw "KDUMP" in one of the above diffs). I can take a look at a little of what's going on. There is a recent upstream patch to afs.h that does some reorganizing of the code to put in into the proper location.
Looking at the build log. It could be that with a high number of parallel processes is causing problems. Could you see what happens if you pull in the upstream master commit: libafs: Serialize INSTDIRS/DESTDIRS and COMPDIRS (commit hash: 3db8c37e8ef6bea0f03ef6b8f82ed93d52937d7d) (gerrit: https://gerrit.openafs.org/14137 ) The commit itself is fairly simple, just adds the following line to the src/libafs/Makefile.common.in file. $(INSTDIRS) $(DESTDIRS): $(COMPDIRS) afsint.h is "built" from some of the xdr code (rxgen) and it's possible that this step isn't being completed before trying to build some of the kernel (or ukernel) code. There is a possibility that another dependency needs to be added when building libuafs
