This is an auto-filled bug because net-libs/libhubbub calls directly CC. Attached build log and emerge --info
Created attachment 633536 [details] build.log build log and emerge --info
Hi Agostino, libhubbub makes use of dev-util/netsurf-buildsystem, the variables passed in to make comes from /usr/share/netsurf-buildsystem/gentoo-helpers.sh Could you please advise on what exactly your auto-filed system is indicating is wrong here, this is the command that gets executed as a result of netsurf-buildsystem. make -j6 NSSHARED=/usr/share/netsurf-buildsystem LIBDIR=lib64 PREFIX=/usr Q= CC=x86_64-pc-linux-gnu-gcc LD=x86_64-pc-linux-gnu-ld HOST_CC=$(CC) CCOPT= CCNOOPT= CCDBG= LDDBG= AR=x86_64-pc-linux-gnu-ar WARNFLAGS= COMPONENT_TYPE=lib-shared netsurf in turn uses tc-getCC to locate the C compiler. I do note this from the gentoo-helpers.sh file which could potentially be suspect and prevent cross-compiling: 9 CC="$(tc-getCC)" 10 LD="$(tc-getLD)" 11 HOST_CC="\$(CC)" 16 AR="$(tc-getAR)" But this would be a bug in netsurf-buildsystem, not libhubbub, so I'm not quite following the issue here.
(In reply to Jaco Kroon from comment #2) > Could you please advise on what exactly your auto-filed system is indicating > is wrong here, this is the command that gets executed as a result of > netsurf-buildsystem. The affected line is: make: cc: Command not found So while it states CC="$(tc-getCC)" (that is x86_64-pc-linux-gnu-gcc) it uses cc.
Hi Agostino, Right, so the specific issue is BUILD_CC. /usr/share/netsurf-buildsystem/makefiles/Makefile.tools 58 BUILD_CC ?= cc 74 ifeq ($(BUILD),) 75 BUILD := $(shell $(BUILD_CC) -dumpmachine) 76 ifeq ($(BUILD),) 77 $(error "Failed to guess BUILD") 78 endif 79 endif Would this then not be a bug in /usr/share/netsurf-buildsystem/gentoo-helpers.sh which doesn't properly set BUILD_CC? dev-util/netsurf-buildsystem-1.8 Unfortunately it seems this package is maintainer-needed. A quick search shows quite a few users of this build system: dev-libs/libcss dev-libs/libnsfb dev-libs/libnsutils dev-libs/libparserutils dev-libs/libutf8proc dev-libs/libwapcaplet dev-libs/nsgenbind media-libs/libnsbmp media-libs/libnsgif media-libs/libnspsl media-libs/librosprite media-libs/libsvgtiny net-libs/libdom net-libs/libhubbub www-client/netsurf I don't mind doing a once-off PR on netsurf-buildsystem but don't have capacity to take on more packages still. My question is what needs to be set to what? I note there is HOST_CC="\$(CC)" already (Although I don't see this used in the actual build system). Looks like we need to add BUILD_CC="$(tc-getBUILD_CC)" to the gentoo-helpers.sh script? Possibly a few others for CPP? BUILD_CXX and CXX being visible in the build system. Adding philipp.ammann@posteo.de as he was the last person to bump netsurf-buildsystem. If you have opinions on this please.
In order to test the PR I removed the /usr/bin/cc symlink from my system and then proceeded the build libhubbub after installing the new updated variant of netsurf-buildsystem.
(In reply to Jaco Kroon from comment #4) > Unfortunately it seems this package is maintainer-needed. A quick search > shows quite a few users of this build system: > > dev-libs/libcss > dev-libs/libnsfb > dev-libs/libnsutils > dev-libs/libparserutils > dev-libs/libutf8proc > dev-libs/libwapcaplet > dev-libs/nsgenbind > media-libs/libnsbmp > media-libs/libnsgif > media-libs/libnspsl > media-libs/librosprite > media-libs/libsvgtiny > net-libs/libdom > net-libs/libhubbub > www-client/netsurf All these packages are dependencies of www-client/netsurf and ... > I don't mind doing a once-off PR on netsurf-buildsystem but don't have > capacity to take on more packages still. ... since I'm proxy-maintaining netsurf already, I can do the same for its dependencies. > My question is what needs to be > set to what? I note there is HOST_CC="\$(CC)" already (Although I don't see > this used in the actual build system). > > Looks like we need to add BUILD_CC="$(tc-getBUILD_CC)" to the > gentoo-helpers.sh script? Without having looked at toolchain*.eclass: That sounds like the proper way to do it. No patching required, and it's probably the way upstream intended it to be done. It *should* even work with crossdev (though testing it is gonna be fun...). > Possibly a few others for CPP? BUILD_CXX and CXX being visible in the build > system. IMO: Just add the C++ variables and be done with it. What do you think?
https://github.com/gentoo/gentoo/pull/15629 Already done in the PR @ Adding the C++ variables. If you don't mind eyeballing that at the very least I'd appreciate. Basicaly the whole thing is to add: CXX=$(..) BUILD_CXX=$(..) BUILD_CC=$(..) can't find that there is a HOST_CXX in the system as per HOST_CC. So I think for the moment the PR should be adequate.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ae58cbc4df32bfc463141f4b8d93012ae86485c6 commit ae58cbc4df32bfc463141f4b8d93012ae86485c6 Author: Jaco Kroon <jaco@uls.co.za> AuthorDate: 2020-05-03 17:44:15 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2020-05-13 13:16:46 +0000 dev-util/netsurf-buildsystem: BUILD_CC, CXX and BUILD_CXX Closes: https://bugs.gentoo.org/718010 Package-Manager: Portage-2.3.89, Repoman-2.3.20 Signed-off-by: Jaco Kroon <jaco@uls.co.za> Closes: https://github.com/gentoo/gentoo/pull/15629 Signed-off-by: Joonas Niilola <juippis@gentoo.org> dev-util/netsurf-buildsystem/files/gentoo-helpers-r1.sh | 3 +++ ...etsurf-buildsystem-1.8.ebuild => netsurf-buildsystem-1.8-r1.ebuild} | 0 2 files changed, 3 insertions(+)
