I send a patch .. >>> Emerging (19 of 35) sys-firmware/ipxe-1.0.0_p20130225 * ipxe-1.0.0_p20130225-09c5109.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking ipxe-1.0.0_p20130225-09c5109.tar.bz2 to /tmp/portage/sys-firmware/ipxe-1.0.0_p20130225/work >>> Source unpacked in /tmp/portage/sys-firmware/ipxe-1.0.0_p20130225/work >>> Preparing source in /tmp/portage/sys-firmware/ipxe-1.0.0_p20130225/work/ipxe-09c5109/src ... >>> Source prepared. >>> Configuring source in /tmp/portage/sys-firmware/ipxe-1.0.0_p20130225/work/ipxe-09c5109/src ... >>> Source configured. >>> Compiling source in /tmp/portage/sys-firmware/ipxe-1.0.0_p20130225/work/ipxe-09c5109/src ... make -j2 bin/808610de.rom Makefile.housekeeping:111: GNU gold is unsuitable for building iPXE Makefile.housekeeping:112: Use GNU ld instead Makefile.housekeeping:113: *** Unsuitable build environment found. Stop. * ERROR: sys-firmware/ipxe-1.0.0_p20130225 failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=sys-firmware/ipxe-1.0.0_p20130225'`, * the complete build log and the output of `emerge -pqv '=sys-firmware/ipxe-1.0.0_p20130225'`. * The complete build log is located at '/var/log/portage/build/sys-firmware/ipxe-1.0.0_p20130225:20130629-114727.log.gz'. * For convenience, a symlink to the build log is located at '/tmp/portage/sys-firmware/ipxe-1.0.0_p20130225/temp/build.log.gz'. * The ebuild environment file is located at '/tmp/portage/sys-firmware/ipxe-1.0.0_p20130225/temp/environment'. * Working directory: '/tmp/portage/sys-firmware/ipxe-1.0.0_p20130225/work/ipxe-09c5109/src' * S: '/tmp/portage/sys-firmware/ipxe-1.0.0_p20130225/work/ipxe-09c5109/src'
Created attachment 352244 [details, diff] ebuild patch turn on verbose build, try to replace ld.gold with ld.bfd, set some toolchain vars build log: https://xmw.de/tmp/ipxe-1.0.0_p20130624-r1:20130629-134435.log
Comment on attachment 352244 [details, diff] ebuild patch >--- ipxe-1.0.0_p20130624.ebuild 2013-06-28 00:18:30.000000000 +0200 >+++ ipxe-1.0.0_p20130624-r1.ebuild 2013-06-29 15:46:03.115595892 +0200 >@@ -4,6 +4,8 @@ > > EAPI=5 > >+inherit flag-o-matic toolchain-funcs >+ > GIT_REV="936134ed460618e18cc05d677a442d43d5e739a1" > GIT_SHORT="936134e" > >@@ -39,6 +41,35 @@ > #define CONSOLE_VMWARE > EOF > fi >+ >+ #package rejects the Gnu gold linker, bug https://bugs.gentoo.org/475202 >+ LD=$(tc-getLD) >+ if ${LD} -v | grep -i "GNU gold" >/dev/null ; then >+ if which "${LD}.bfd" >/dev/null ; then >+ elog "overiding GNU gold linker with ld.bfd (bug 475202)" >+ LD="${LD}.bfd" >+ else >+ elog "GNU gold linker is rejected by the package (bug 475202)" >+ fi >+ fi You can skip this check entirely by simply setting LD=$(tc-getLD).bfd >+ >+ # verbose build, respect gcc, ld, >+ # maybe just set CROSS_COMPILE to $(tc-getCC) without -gcc >+ # HOST_CC is used to compile util/zbin to be later run in the >+ # build process >+ sed -e '1iV := 1' \ >+ -e "/\(C\|LD\)FLAGS/d" \ >+ -e "/^AR\t*:=/s|:=.*|:= $(tc-getAR)|" \ >+ -e "/^CC\t*:=/s|:=.*|:= $(tc-getCC)|" \ >+ -e "/^LD\t*:=/s|:=.*|:= ${LD}|" \ >+ -e "/^OBJCOPY\t*:=/s|:=.*|:= $(tc-getOBJCOPY)|" \ >+ -e "/^OBJDUMP\t*:=/s|:=.*|:= $(tc-getPROG OBJDUMP objdump)|" \ >+ -e "/^RANLIB\t*:=/s|:=.*|:= $(tc-getRANLIB)|" \ >+ -e "/^HOST_CC\t*:=/s|:=.*|:= $(tc-getCC) ${CFLAGS} ${LDFLAGS}|" \ >+ -i Makefile Injecting values for make variables like that is pretty bad. Also, making it build verbosely merely requires setting Q='' on the make command line. Why don't we override this in the make command line? This is a bit bothersome because we want to avoid changing all the emake invocations here, so: @@ -44,27 +46,31 @@ } src_compile() { + ipxemake() { + emake Q='' CC=$(tc-getCC) LD=$(tc-getLD) AR=$(tc-getAR) ${*} + } + export NO_WERROR=1 if use qemu; then And then: s|emake|ipxemake|g >+ export CFLAGS= >+ export LDFLAGS= >+ > } > > src_compile() {
This is really a dup of bug #438058.
Based on both of your feedbacks, I've committed a patch that should address the issue. Basically's its rej's approach but with a reference back to the actual bug for 16-bit code issues for people that wonder why. Let me know if this isn't acceptable to either of you.
