Makefile:141: recipe for target '/var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/xen' failed Steps: Note: I have in /etc/portage/package.keywords/xen >=app-emulation/xen-4.7.1 I tried emerging app-emulation/xen-4.8.0 just released on 12/5/2016 1) emerge app-emulation/xen Logs &etc. to follow shortly.
Created attachment 455552 [details] emerge --info
Created attachment 455554 [details] emerge -pqv
Created attachment 455556 [details] build.log
Created attachment 455558 [details] environment
Here's the tail end of the emerge for quick reference: make[2]: Leaving directory '/var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/arch/x86' Makefile:141: recipe for target '/var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/xen' failed make[1]: *** [/var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/xen] Error 2 make[1]: Leaving directory '/var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen' Makefile:45: recipe for target 'build' failed make: *** [build] Error 2 make: Leaving directory '/var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen' * ERROR: app-emulation/xen-4.8.0::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=app-emulation/xen-4.8.0::gentoo'`, * the complete build log and the output of `emerge -pqv '=app-emulation/xen-4.8.0::gentoo'`. * The complete build log is located at '/var/tmp/portage/app-emulation/xen-4.8.0/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/app-emulation/xen-4.8.0/temp/environment'. * Working directory: '/var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0' * S: '/var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0' >>> Failed to emerge app-emulation/xen-4.8.0, Log file: >>> '/var/tmp/portage/app-emulation/xen-4.8.0/temp/build.log' * Messages for package app-emulation/xen-4.8.0: * To avoid automounting and auto(un)installing with /boot, * just export the DONT_MOUNT_BOOT variable. * Messages for package app-emulation/xen-tools-4.8.0: * Official Xen Guide and the offical wiki page: * https://wiki.gentoo.org/wiki/Xen * http://wiki.xen.org/wiki/Main_Page * * Recommended to utilise the xencommons script to config sytem At boot * Add by use of rc-update on completion of the install * The qemu-bridge-helper is renamed to the xen-bridge-helper in the in source * build of qemu. This allows for app-emulation/qemu to be emerged concurrently * with the qemu capable xen. It is up to the user to distinguish between and utilise * the qemu-bridge-helper and the xen-bridge-helper. File bugs of any issues that arise * Messages for package app-emulation/xen-4.8.0: * ERROR: app-emulation/xen-4.8.0::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=app-emulation/xen-4.8.0::gentoo'`, * the complete build log and the output of `emerge -pqv '=app-emulation/xen-4.8.0::gentoo'`. * The complete build log is located at '/var/tmp/portage/app-emulation/xen-4.8.0/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/app-emulation/xen-4.8.0/temp/environment'. * Working directory: '/var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0' * S: '/var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0' * GNU info directory index is up-to-date. !!! existing preserved libs: >>> package: sys-libs/ncurses-6.0-r1 * - /usr/lib64/libform.so.5 * - /usr/lib64/libform.so.5.9 * used by /usr/bin/ccmake (dev-util/cmake-3.5.2-r1) * - /lib64/libncursesw.so.5 * - /lib64/libncursesw.so.5.9 * used by /bin/nano (app-editors/nano-2.5.3) * used by /usr/lib64/python2.7/lib-dynload/_curses.so (dev-lang/python-2.7.10-r1) * used by /usr/lib64/python2.7/lib-dynload/readline.so (dev-lang/python-2.7.10-r1) * used by 2 other files * - /lib64/libncurses.so.5 * - /lib64/libncurses.so.5.9 * used by /lib64/libreadline.so.6.3 (sys-libs/readline-6.3_p8-r2) * used by /usr/bin/ccmake (dev-util/cmake-3.5.2-r1) * used by /usr/bin/emacs-24 (app-editors/emacs-24.5-r3) * - /usr/lib64/libpanelw.so.5 * - /usr/lib64/libpanelw.so.5.9 * used by /usr/lib64/python2.7/lib-dynload/_curses_panel.so (dev-lang/python-2.7.10-r1) * used by /usr/lib64/python3.4/lib-dynload/_curses_panel.cpython-34.so (dev-lang/python-3.4.3-r1) Use emerge @preserved-rebuild to rebuild packages using these libraries * IMPORTANT: config file '/etc/conf.d/hostname' needs updating. * See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS * sections of the emerge man page to learn how to update config files. * IMPORTANT: 1 news items need reading for repository 'gentoo'. * Use eselect news read to view new items. zeta xen-4.8.0 #
here's the problem at line 1347: efi/buildid.o: file not recognized: File format is ambiguous efi/buildid.o: matching formats: coff-x86-64 pe-x86-64 Makefile:175: recipe for target '/var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/xen.efi' failed this is the same problem I had when I compiled Xen 4.8 outside of the ebuilds, see: https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00991.html However, I corrected the problem by upgrading my binutils to 2.27. Perhaps since binutils is slot controlled, the emerge used the current approved one rather than 2.27 which is masked?
In the environment.log file, lines 27+: declare DEPEND="|| ( >=dev-lang/python-2.7.5-r2:2.7 ) efi? ( >=sys-devel/binutils-2.22[multitarget] ) !efi? ( >=sys-devel/binutils-2.22 ) " zeta xen-4.8.0 # eselect binutils list [1] x86_64-pc-linux-gnu-2.25.1 * [2] x86_64-pc-linux-gnu-2.27 zeta xen-4.8.0 # zeta xen-4.8.0 # eselect binutils set x86_64-pc-linux-gnu-2.27 * Switching to x86_64-pc-linux-gnu-2.27 ... [ ok ] * Please remember to run: * # . /etc/profile zeta xen-4.8.0 # . /etc/profile zeta xen-4.8.0 # eselect binutils list [1] x86_64-pc-linux-gnu-2.25.1 [2] x86_64-pc-linux-gnu-2.27 * zeta xen-4.8.0 # I then proceeded with: emerge app-emulation/xen and it failed, again, with: /var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/common/symbols-dummy.o -o /var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/.xen-syms.0 x86_64-pc-linux-gnu-ld -mi386pep --subsystem=10 --image-base=0xffff82d080000000 --stack=0,0 --heap=0,0 --strip-debug --section-alignment=0x200000 --file-alignment=0x20 --major-image-version=4 --minor-image-version=8 --major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 --minor-subsystem-version=0 --build-id=sha1 -T efi.lds -N prelink-efi.o efi/relocs-dummy.o /var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/common/symbols-dummy.o efi/buildid.o -o /var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/.xen.efi.0xffff82d080000000.0 && x86_64-pc-linux-gnu-ld -mi386pep --subsystem=10 --image-base=0xffff82d0c0000000 --stack=0,0 --heap=0,0 --strip-debug --section-alignment=0x200000 --file-alignment=0x20 --major-image-version=4 --minor-image-version=8 --major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 --minor-subsystem-version=0 --build-id=sha1 -T efi.lds -N prelink-efi.o efi/relocs-dummy.o /var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/common/symbols-dummy.o efi/buildid.o -o /var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/.xen.efi.0xffff82d0c0000000.0 && : efi/buildid.o: file not recognized: File format is ambiguous efi/buildid.o: matching formats: coff-x86-64 pe-x86-64 It looks like the ebuild is overriding my selection of binutils 2.27. Remember, I successfully got paste this problem of "file not recognized: File format is ambiguous" using binutils 2.27. Unfortunately, I do not know how to override an ebuild setting, but I'll investigate. If this bug is not further updated with a resolution of specifying binutils to 2.27, the please suggest a way I can override what appears to be a decision to require a lower version of binutils.
I removed bintutils 2.25.... leaving only 2.27 and then tried again: USE="efi" emerge app-emulation/xen but the same problem occurred: x86_64-pc-linux-gnu-ld -T xen.lds -N prelink.o --build-id=sha1 \ /var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/common/symbols-dummy.o -o /var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/.xen-syms.0 x86_64-pc-linux-gnu-ld -mi386pep --subsystem=10 --image-base=0xffff82d080000000 --stack=0,0 --heap=0,0 --strip-debug --section-alignment=0x200000 --file-alignment=0x20 --major-image-version=4 --minor-image-version=8 --major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 --minor-subsystem-version=0 --build-id=sha1 -T efi.lds -N prelink-efi.o efi/relocs-dummy.o /var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/common/symbols-dummy.o efi/buildid.o -o /var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/.xen.efi.0xffff82d080000000.0 && x86_64-pc-linux-gnu-ld -mi386pep --subsystem=10 --image-base=0xffff82d0c0000000 --stack=0,0 --heap=0,0 --strip-debug --section-alignment=0x200000 --file-alignment=0x20 --major-image-version=4 --minor-image-version=8 --major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 --minor-subsystem-version=0 --build-id=sha1 -T efi.lds -N prelink-efi.o efi/relocs-dummy.o /var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/common/symbols-dummy.o efi/buildid.o -o /var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/.xen.efi.0xffff82d0c0000000.0 && : efi/buildid.o: file not recognized: File format is ambiguous efi/buildid.o: matching formats: coff-x86-64 pe-x86-64 Makefile:175: recipe for target '/var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/xen.efi' failed After the failure, I confirmed I'm using binutils 2.27: zeta xen-4.8.0 # binutils-config -l [1] x86_64-pc-linux-gnu-2.27 * zeta xen-4.8.0 # Apparently somoene else ran into the same problem with binutils 2.27: https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg01007.html What's odd is that when I compiled outside of Gentoo's portage, using binutils 2.27 allowed me to overcome that juncture. Yet, when building with the ebuild and having only binutils 2.27 on my system (I removed the earlier version), I'm still blocked.
I couldn't re-produce this problem, both sys-devel/binutils-2.26.1 sys-devel/binutils-2.27 works fine here as I'm running a testing system (using ACCEPT_KEYWORDS="amd64 ~amd64") while yours is stable system.. not sure if this is the problem.
I actually couldn't reproduce this problem at my stable box, even it works fine with binutils-2.25 gen64s21 ~ # binutils-config -l [1] x86_64-pc-linux-gnu-2.25.1 * gen64s21 ~ # gcc-config -l [1] x86_64-pc-linux-gnu-4.9.3 * gen64s21 ~ # eix -e xen [?] app-emulation/xen Available versions: 4.6.0-r9^st ~4.6.0-r10^st ~4.6.1^st ~4.6.1-r1^st ~4.6.1-r2^st ~4.6.1-r3^st {custom-cflags debug efi flask} Installed versions: 4.8.0^st(15:32:54 12/09/16)(efi flask -custom-cflags -debug) Homepage: http://xen.org/ Description: The Xen virtual machine monitor
A comment on the Xen mailing list made me wonder if parallel processing was the culprit. https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg01022.html raised this question: Is that newer version similarly configured, or is your success simply because of the two conflicting target types not being there at the same time? My /etc/portage/make.conf contained "-j9", so I reset it to "-j1" to avoid a possible race condition: #MAKEOPTS="-j9" MAKEOPTS="-j1" When I tried to re-emerge, it still failed at the same point: efi/buildid.o: file not recognized: File format is ambiguous efi/buildid.o: matching formats: coff-x86-64 pe-x86-64 Makefile:175: recipe for target '/var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/xen.efi' failed I think what I'll do is "make clean" the staged Xen 4.8 and then recompile and capture everything in a log and then compare the two logs at the point failure. I'll update here with my findings after I accomplish that task.
My out-of-portage build failed, too, with the same error. The log of my out of portage "make world" is at: http://napadata.net/paste/view/eb7c1d97 and in reviewing the log, I've determined that the problem may be occurring at line 1521: objcopy -I ihex -O binary buildid.ihex buildid.o because the next operation is the one that triggers the failure at lines 2236: efi/buildid.o: file not recognized: File format is ambiguous efi/buildid.o: matching formats: coff-x86-64 pe-x86-64 I have placed a zip archive of the efi directory, as well as the efi directory at: http://napadata.net/2016/zeta/20161209/
Another person running Gentoo commented on the Xen Forum: I have the same problem with binutils-2.27 on gentoo. Worked around it by adding " -b coff-x86-64 " to the ld command line before $(note_file). Running with gentoo-sources-4.8.12-gentoo-r1 as dom0 kernel. Compiled with gcc set to x86_64-pc-linux-gnu-5.4.0 . Apart from that seems to be running nicely, in early test :-) https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg01007.html I determined what he was talking about, to wit, modifying Makefile under ...xen/arch/x86. I adopted his insertions of which there are three: $(TARGET).efi: prelink-efi.o $(note_file) efi.lds efi/relocs-dummy.o $(BASEDIR)/common/symbols-dummy.o efi/mkreloc $(foreach base, $(VIRT_BASE) $(ALT_BASE), \ $(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< efi/relocs-dummy.o \ $(BASEDIR)/common/symbols-dummy.o -b coff-x86-64 $(note_file) -o $(@D)/.$(@F).$(base).0 &&) : $(guard) efi/mkreloc $(foreach base,$(VIRT_BASE) $(ALT_BASE),$(@D)/.$(@F).$(base).0) >$(@D)/.$(@F).0r.S $(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).0 \ | $(guard) $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort >$(@D)/.$(@F).0s.S $(guard) $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0r.o $(@D)/.$(@F).0s.o $(foreach base, $(VIRT_BASE) $(ALT_BASE), \ $(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< \ $(@D)/.$(@F).0r.o $(@D)/.$(@F).0s.o -b coff-x86-64 $(note_file) -o $(@D)/.$(@F).$(base).1 &&) : $(guard) efi/mkreloc $(foreach base,$(VIRT_BASE) $(ALT_BASE),$(@D)/.$(@F).$(base).1) >$(@D)/.$(@F).1r.S $(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).1 \ | $(guard) $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort >$(@D)/.$(@F).1s.S $(guard) $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o $(guard) $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T efi.lds -N $< \ $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o -b coff-x86-64 $(note_file) -o $@ if $(guard) false; then rm -f $@; echo 'EFI support disabled'; \ else $(NM) -pa --format=sysv $(@D)/$(@F) \ | $(BASEDIR)/tools/symbols --xensyms --sysv --sort >$(@D)/$(@F).map; fi rm -f $(@D)/.$(@F).[0-9]* and successfully executed the command from line 2235 of the Out of Portage log referenced above (correlates to line 1346 of the Build log): ld -mi386pep --subsystem=10 --image-base=0xffff82d080000000 --stack=0,0 --heap=0,0 --strip-debug --section-alignment=0x200000 --file-alignment=0x20 --major-image-version=4 --minor-image-version=8 --major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 --minor-subsystem-version=0 --build-id=sha1 -T efi.lds -N prelink-efi.o efi/relocs-dummy.o /usr/local/src/xen-4.8.0/xen/common/symbols-dummy.o -b coff-x86-64 efi/buildid.o -o /usr/local/src/xen-4.8.0/xen/.xen.efi.0xffff82d080000000.0 && ld -mi386pep --subsystem=10 --image-base=0xffff82d0c0000000 --stack=0,0 --heap=0,0 --strip-debug --section-alignment=0x200000 --file-alignment=0x20 --major-image-version=4 --minor-image-version=8 --major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 --minor-subsystem-version=0 --build-id=sha1 -T efi.lds -N prelink-efi.o efi/relocs-dummy.o /usr/local/src/xen-4.8.0/xen/common/symbols-dummy.o -b coff-x86-64 efi/buildid.o -o /usr/local/src/xen-4.8.0/xen/.xen.efi.0xffff82d0c0000000.0 && : I'll make a patch and upload to this bug. Summary: An explicit "input-format" format using the ld flag of "-b" is required to resolve the ambiguity binutils might encounter. My system treated the file as ambiguous, whereas Yixun Lan's system did not find the input file ambiguous. I do not have an explanation other than how binutils is installed may be contextual dependent upon the system it is installed on.
Created attachment 455684 [details, diff] patch for Xen-4.8.0 Modifies xen/arch/x86/Makefile so that input files are explicitly described as "coff-x86-64". On some Gentoo systems, binutils (2.27) reads the input files as possibly two types of files and because of the ambiguity, breaks the build with the error message: efi/buildid.o: file not recognized: File format is ambiguous efi/buildid.o: matching formats: coff-x86-64 pe-x86-64 Makefile:175: recipe for target '/var/tmp/portage/app-emulation/xen-4.8.0/work/xen-4.8.0/xen/xen.efi' failed This patch adds 3 line parameters " -b coff-x86-64 " in the "ld" statement.
Created attachment 455686 [details] modified ebuild differs from original simply by adding a single line (2nd line) to incorporate a patch: epatch "${FILESDIR}"/${PN}-4.6-efi.patch epatch "${FILESDIR}"/${PN}-4.8.0-coff-x86-64.patch Confirmed and successfully built xen-4.8.0 on a UEFI system. Note: have not confirmed whether I can launch or load Xen, there are still possible outstanding issues, but those issues are outside the scope of the xen-4.8.0 ebuild.
I will endeavor to submit the proposed patch the the Xen development team, but their procedure to submit patches involves some work and thus more time.
GOOD NEWS!! update: I succeeded. It's a very problematic manner involving launching efi file from the EFI shell, but I have successfully launched my kernel as DOM0 atop an instance of XEN 4.8.0 -- I'm assuming that by run 'xl info' in my session and getting output I've succeeded: zeta jlpoole # xl info host : zeta release : 4.4.26-gentoo version : #1 SMP Wed Dec 7 20:56:22 PST 2016 machine : x86_64 nr_cpus : 8 max_cpu_id : 7 nr_nodes : 1 cores_per_socket : 8 threads_per_core : 1 cpu_mhz : 2400 hw_caps : b7ebfbff:43d8e3bf:28100800:00000101:00000000:00002282:00000000:00000100 virt_caps : hvm total_memory : 63207 free_memory : 129 sharing_freed_memory : 0 sharing_used_memory : 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 8 xen_extra : .0 xen_version : 4.8.0 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : xen_commandline : console=vga,com1 com1=9600 loglvl=all cc_compiler : x86_64-pc-linux-gnu-gcc (Gentoo 4.9.3 p1.5, pie-0.6.4) 4.9.3 cc_compile_by : cc_compile_domain : [unknown] cc_compile_date : Fri Dec 9 09:25:39 PST 2016 build_id : 22b45f9d3e22085c9d9f204322ed8920 xend_config_format : 4 zeta jlpoole # The question is, where to document everything?? I'll ask for suggestions on the Gentoo forum. I'm leaving this marked "UNCOFIRMED" since I have a patch that I believe may be helpful to people whose binutils is unable to distinguish "coff-x86-64" from "pe-x86-64".
For what is worth, here's a video of launching the Xen EFI at: https://www.youtube.com/watch?v=sjHzXfjVnxw
Looking at your diff, you chose coff, EFI spec calls for PE. How certain are you that COFF is the right choice here?
There is no reason behind my choice of COFF, it just worked.
Confirming hitting bug. Patch works. Thank You Mr. Poole!
The underlying issue still was not resolved. For further information, follow the thread on the Xen Developer's list: https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg02709.html
Thanks, can confirm on xen 4.8.1. The patch works.
Looks like that with binutils 2.28.1 it's not needed any more.
Sorry, this is not fixed yet, I forgot I've the patch in my /etc/portage/patches. The patch is still needed.
I have started building Xen straight from source, and just now I tried rebuilding binutils WITHOUT USE="multitarget". Unpatched xen builds without a hitch WITH efi.
(In reply to Håkon Alstadheim from comment #26) > I have started building Xen straight from source, and just now I tried > rebuilding binutils WITHOUT USE="multitarget". > > Unpatched xen builds without a hitch WITH efi. Which version of xen did you build? I've tried with 4.8.2 and binutils with USE=-multitarget and it failed :(
(In reply to Tomáš Mózes from comment #27) > (In reply to Håkon Alstadheim from comment #26) > > I have started building Xen straight from source, and just now I tried > > rebuilding binutils WITHOUT USE="multitarget". > > > > Unpatched xen builds without a hitch WITH efi. > > Which version of xen did you build? I've tried with 4.8.2 and binutils with > USE=-multitarget and it failed :( I've only tried with 4.10.0-rc2 Double-checked now, and the makefile patch is NOT applied to my build. # xl info | grep xen_version xen_version : 4.10.0-rc # eix -e binutils [I] sys-devel/binutils Available versions: [...snip...] Installed versions: 2.28.1(2.28.1)(00:48:23 10/25/17)(cxx nls -multitarget -static-libs -test -vanilla) Homepage: https://sourceware.org/binutils/ Description: Tools necessary to build programs 0:gentoo ~ # eix -e gcc [I] sys-devel/gcc Available versions: [...snip...] Installed versions: 5.4.0-r3(5.4.0)^s(18:56:01 09/26/17)(cilk cxx fortran gcj graphite hardened mpx multilib nls nptl openmp pgo vtv -altivec -awt -debug -doc -fixed-point -go -jit -libssp -nopie -nossp -objc -objc++ -objc-gc -regression-test -sanitize -vanilla) Homepage: https://gcc.gnu.org/ Description: The GNU Compiler Collection
(In reply to Tomáš Mózes from comment #27) > (In reply to Håkon Alstadheim from comment #26) > > I have started building Xen straight from source, and just now I tried > > rebuilding binutils WITHOUT USE="multitarget". > > > > Unpatched xen builds without a hitch WITH efi. > > Which version of xen did you build? I've tried with 4.8.2 and binutils with > USE=-multitarget and it failed :( FALSE alarm, sorry! Turns out xen.efi was not built when running the non-multitarget binutils. My home-grown build-scripts did not catch this. Sorry for the noise.
I just took a peek inside the debian build-scripts. Where gentoo does: --enable-targets=all --enable-64-bit-bfd in toolchain-binutils.eclass, Debian in their binutils-multiarch package does: multiarch_targets = \ aarch64-linux-gnu \ aarch64_be-linux-gnu \ alpha-linux-gnu \ arm-linux-gnueabi \ hppa-linux-gnu \ i686-linux-gnu \ ia64-linux-gnu \ m32r-linux-gnu \ m68k-linux-gnu \ m68k-rtems \ mips-linux-gnu \ mipsel-linux-gnu \ mips64-linux-gnuabin32 \ mips64el-linux-gnuabin32 \ mips64-linux-gnu \ mips64el-linux-gnu \ mipsisa32r6-linux-gnu \ mipsisa32r6el-linux-gnu \ mipsisa64r6-linux-gnuabin32 \ mipsisa64r6el-linux-gnuabin32 \ mipsisa64r6-linux-gnuabi64 \ mipsisa64r6el-linux-gnuabi64 \ powerpc-linux-gnu \ powerpc64-linux-gnu \ powerpc64le-linux-gnu \ s390-linux-gnu \ s390x-linux-gnu \ sh-linux-gnu \ sparc-linux-gnu \ sparc64-linux-gnu \ x86_64-linux-gnu \ x86_64-linux-gnux32 \ m32r-linux-gnu \ x86_64-pep
The issue is also in the version 4.9.1 I added the "-b coff-x86-64", like in the comment, in a vanilla version, and It works. So the patch "Xen-4.8.0" should also works with the 4.9.x version. You should add the patch in the main portage because we only have version 4.8.x and 4.9.x, when you try to upgrade xen (In my case I had version 4.7.3), I wasn't able to rebuild xen-tools-4.7.3, because emerge build first app-emulation/xen-tools and then app-emulation/xen. It should build first the app-emulation/xen and then app-emulation/xen-tools, like that we have no problems if there is a error build.
(In reply to John L. Poole from comment #1) > Created attachment 455552 [details] attached patch is actual for =app-emulation/xen-4.8.2-r2: recent stable ebuild fails to compile on my machine: $ emerge --info app-emulation/xen Portage 2.3.13 (python 2.7.14-final-0, default/linux/amd64/13.0, gcc-6.4.0, glibc-2.25-r9, 4.1.43-gentoo-r1-dom0 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-4.1.43-gentoo-r1-dom0-x86_64-Intel-R-_Core-TM-_i7-6700_CPU_@_3.40GHz-with-gentoo-2.4.1 KiB Mem: 309504 total, 19884 free KiB Swap: 8388604 total, 8388508 free Timestamp of repository gentoo: Fri, 24 Nov 2017 21:00:01 +0000 Head commit of repository gentoo: 81513fb1a097b70e5ff1d14b1cfb10dbd953f8ab sh bash 4.3_p48-r1 ld GNU ld (Gentoo 2.29.1 p3) 2.29.1 distcc 3.2rc1 x86_64-pc-linux-gnu [disabled] app-shells/bash: 4.3_p48-r1::gentoo dev-lang/perl: 5.24.3::gentoo dev-lang/python: 2.7.14::gentoo, 3.4.5::gentoo dev-util/cmake: 3.8.2::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.4.1-r2::gentoo sys-apps/openrc: 0.34.9::gentoo sys-apps/sandbox: 2.10-r4::gentoo sys-devel/autoconf: 2.69::gentoo sys-devel/automake: 1.15.1-r1::gentoo sys-devel/binutils: 2.29.1-r1::gentoo sys-devel/gcc: 6.4.0::gentoo sys-devel/gcc-config: 1.8-r1::gentoo sys-devel/libtool: 2.4.6-r3::gentoo sys-devel/make: 4.2.1::gentoo sys-kernel/linux-headers: 4.4::gentoo (virtual/os-headers) sys-libs/glibc: 2.25-r9::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://10.175.10.237/gentoo-portage priority: -1000 sync-rsync-extra-opts: home-overlay location: /usr/local/portage masters: gentoo priority: 0 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA Oracle-BCLA-JavaSE" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -g0 -march=corei7-avx -mtune=corei7-avx -msse4 -mcx16 -mpopcnt -msahf -maes -mavx -mpclmul --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -ftree-loop-distribution -ftree-loop-linear -fno-stack-protector -floop-interchange -floop-strip-mine -floop-block -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -g0 -march=corei7-avx -mtune=corei7-avx -msse4 -mcx16 -mpopcnt -msahf -maes -mavx -mpclmul --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -ftree-loop-distribution -ftree-loop-linear -fno-stack-protector -floop-interchange -floop-strip-mine -floop-block -pipe" DISTDIR="/mnt/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps=y" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://mirror.yandex.ru/gentoo-distfiles" LANG="en_US.UTF8" LC_ALL="en_US.UTF8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j 16" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="acl acpi amd64 berkdb bzip2 cli cracklib crypt custom-cflags cxx dri gdbm iconv modules multilib ncurses nptl openmp pam pcre python readline seccomp session ssl tcpd unicode xattr zlib" ABI_X86="64" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64 pc" INPUT_DEVICES="keyboard" KERNEL="linux" LCD_DEVICES="text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-0" POSTGRES_TARGETS="postgres9_5" PYTHON_SINGLE_TARGET="python3_4" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby22" USERLAND="GNU" VIDEO_CARDS="intel" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ================================================================= Package Settings ================================================================= app-emulation/xen-4.8.2-r2::gentoo was built with the following: USE="efi -custom-cflags -debug -flask" ABI_X86="(64)" CFLAGS="" LDFLAGS=""
*** Bug 646200 has been marked as a duplicate of this bug. ***
*** Bug 649048 has been marked as a duplicate of this bug. ***
I've created a patch for app-emulation/xen-4.9.1-r1 and placed it within Bug #649048. https://bugs.gentoo.org/attachment.cgi?id=521790 Warning: xen-4.9.1-r1_coff-x86-64.patch is meant for what I deem "User Patches" approach as opposed to the "Portage Overlay" approach.
Upstream finally created a patch in 4.11: https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff_plain;h=48a933ee590e2fdfa240484ebda4f76096277d7e I'll try to backport to 4.10.1.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8862ea34a1a01a87241fa52c725bb9cce2deb170 commit 8862ea34a1a01a87241fa52c725bb9cce2deb170 Author: Tomas Mozes <hydrapolic@gmail.com> AuthorDate: 2018-07-18 05:06:38 +0000 Commit: Yixun Lan <dlan@gentoo.org> CommitDate: 2018-08-14 01:20:24 +0000 app-emulation/xen: fix efi building Closes: https://bugs.gentoo.org/602052 Closes: https://github.com/gentoo/gentoo/pull/9269 Package-Manager: Portage-2.3.43, Repoman-2.3.10 Signed-off-by: Yixun Lan <dlan@gentoo.org> app-emulation/xen/Manifest | 1 + app-emulation/xen/xen-4.10.1-r1.ebuild | 172 +++++++++++++++++++++++++++++++++ 2 files changed, 173 insertions(+)
