| Summary: | app-emulation/xen-4.2.0-r1 - x86_64-pc-linux-gnu-ld: unrecognized option '--subsystem=10' | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jiří Moravec <qjim> |
| Component: | Current packages | Assignee: | Ian Delaney (RETIRED) <idella4> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | floppym, jaak, pageexec, xen |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=458974 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
workaround, when you linker has support for i386pep emulation |
||
|
Description
Jiří Moravec
2013-02-18 18:57:46 UTC
Created attachment 339284 [details]
build.log
emerge -pqv '=app-emulation/xen-4.2.0-r1' result: [ebuild U ] app-emulation/xen-4.2.0-r1 [4.1.2] USE="-custom-cflags -debug -flask -pae -xsm" PYTHON_SINGLE_TARGET="python2_7%* -python2_6%" PYTHON_TARGETS="python2_7%* -python2_6%" well this doesn't look good. x86_64-pc-linux-gnu-ld -O1 --as-needed --subsystem=10 --image-base=0xffff82c480000000 --stack=0,0 --heap=0,0 --strip-debug --section-alignment=0x200000 --file-alignment=0x20 --major-image-version=4 --minor-image-version=2 --major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 --minor-subsystem-version=0 -T efi.lds -N prelink-efi.o efi/relocs-dummy.o /var/tmp/portage/app-emulation/xen-4.2.0-r1/work/xen-4.2.0/xen/common/symbols-dummy.o -o /var/tmp/portage/app-emulation/xen-4.2.0-r1/work/xen-4.2.0/xen/.xen.efi.0xffff82c480000000.0 && x86_64-pc-linux-gnu-ld -O1 --as-needed --subsystem=10 --image-base=0xffff82c4c0000000 --stack=0,0 --heap=0,0 --strip-debug --section-alignment=0x200000 --file-alignment=0x20 --major-image-version=4 --minor-image-version=2 --major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 --minor-subsystem-version=0 -T efi.lds -N prelink-efi.o efi/relocs-dummy.o /var/tmp/portage/app-emulation/xen-4.2.0-r1/work/xen-4.2.0/xen/common/symbols-dummy.o -o /var/tmp/portage/app-emulation/xen-4.2.0-r1/work/xen-4.2.0/xen/.xen.efi.0xffff82c4c0000000.0 && : is your line at point of failure. Here is mine : x86_64-pc-linux-gnu-ld -O1 --as-needed --hash-style=gnu --subsystem=10 --image-base=0xffff82c480000000 --stack=0,0 --heap=0,0 --strip-debug --section-alignment=0x200000 --file-alignment=0x20 --major-image-version=4 --minor-image-version=2 --major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 --minor-subsystem-version=0 -T efi.lds -N prelink-efi.o efi/relocs-dummy.o /mnt/gen2/TmpDir/portage/app-emulation/xen-4.2.0-r1/work/xen-4.2.0/xen/common/symbols-dummy.o -o /mnt/gen2/TmpDir/portage/app-emulation/xen-4.2.0-r1/work/xen-4.2.0/xen/.xen.efi.0xffff82c480000000.0 && : x86_64-pc-linux-gnu-ld -O1 --as-needed --hash-style=gnu --subsystem=10 --image-base=0xffff82c4c0000000 --stack=0,0 --heap=0,0 --strip-debug --section-alignment=0x200000 --file-alignment=0x20 --major-image-version=4 --minor-image-version=2 --major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 --minor-subsystem-version=0 -T efi.lds -N prelink-efi.o efi/relocs-dummy.o /mnt/gen2/TmpDir/portage/app-emulation/xen-4.2.0-r1/work/xen-4.2.0/xen/common/symbols-dummy.o -o /mnt/gen2/TmpDir/portage/app-emulation/xen-4.2.0-r1/work/xen-4.2.0/xen/.xen.efi.0xffff82c4c0000000.0 && : unrecognized option '--subsystem=10' is cited as a gcc or ld error and it's the only point ist's cited. It doesn't appear in the linker line x86_64-pc-linux-gnu-ld ...... Point 1. Your build has the line beginning with x86_64-pc-linux-gnu-ld -O1 mine begins with a colon pre-pended, and no idea what this signifies. Point 2. --subsystem=10 may be a feature of your system, and if you find out what it is feel free to post it here. Point 3. My build completed just it has recently under the rigors of arch testing, for xen-4.2.0-r1. Could NOT replicate, and until you find a seconder, status limbo Maybe LDFLAGS should not include $CFLAGS in your make.conf... thx Jeroen (In reply to comment #4) > Maybe LDFLAGS should not include $CFLAGS in your make.conf... Nope. LDFLAGS="-Wl,-O1 -Wl,--as-needed" ... same result Eureka! Linker failed because there is missing argument in command line: -mi386pep ! Correct form is 'x86_64-pc-linux-gnu-ld -mi386pep --subsystem=10 ...' When I do manually: ebuild xen-4.2.1-r1.ebuild clean configure cd /var/tmp/xen/portage/app-emulation/xen make -j6 CC=x86_64-pc-linux-gnu-gcc LD=x86_64-pc-linux-gnu-ld -C xen everything is OK! But, if this is invoked by ebuild ... compile, make command is different: make -j6 CC=x86_64-pc-linux-gnu-gcc 'LDFLAGS=-O1 --as-needed' LD=x86_64-pc-linux-gnu-ld -C xen Apparently -mi386pep argument was eated and replaced with 'LDFLAGS=-O1 --as-needed'. And this is default LDFLAGS value, because I removed LDFLAGS from make.conf completely. hmm good news.
out of interest, mine is
LDFLAGS="${LDFLAGS} -Wl,--hash-style=gnu"
now do I close this invalid or use this to add an einfo note for funny LDFLAGS. Hmmm
However problem isn't solved, because I'm still unable build xen-4.2 package through ordinary emerge command. Ian, maybe I have explanation why you have no problem. I looked on Makefile and part of your build.log and I believe that your xen.efi compilation was actually disabled. Because otherwise you would be in same troubles as I'm. Please try 'ebuild xen-4.2.0-r1.ebuild compile' and look into xen-4.2.0-r1/work/xen-4.2.0/xen/arch/x86/efi directory, if there is some file 'disabled'. And in your build.log just after line 'if : false; then rm -f /mnt/gen2/TmpDir/portage/app-emulation/xen-4.2.0-r1/work/xen-4.2.0/xen/xen.efi; echo 'EFI support disabled'; fi' you have 'EFI support disabled'. Am I right? (In reply to comment #10) > Ian, maybe I have explanation why you have no problem. I looked on Makefile > and part of your build.log and I believe that your xen.efi compilation was > actually disabled. Because otherwise you would be in same troubles as I'm. > Firstly, do we want full efi support? Secondly, there are no options in the initial Config.mk file or its ilk that offer a selection of efi as a build option. > Please try 'ebuild xen-4.2.0-r1.ebuild compile' and look into > xen-4.2.0-r1/work/xen-4.2.0/xen/arch/x86/efi directory, if there is some > file 'disabled'. > Yes, it's there. testuser@archtester /mnt/gen2/TmpDir/portage/app-emulation/xen-4.2.0-r1/work/xen-4.2.0 $ ls -ld xen/arch/x86/efi/disabled -rw-r--r-- 1 testuser testuser 144 Feb 22 23:51 xen/arch/x86/efi/disabled $ cat xen/arch/x86/efi/disabled x86_64-pc-linux-gnu-ld: unrecognised emulation mode: i386pep Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 i386linux elf_l1om elf_k1om However, you either haven't noticed or neglected to point out it is there also from invoking the $ make -j6 CC=x86_64-pc-linux-gnu-gcc LD=x86_64-pc-linux-gnu-ld -C xen from the source. In this the ebuild and the manual build have equal scores. > And in your build.log just after line 'if : false; then rm -f > /mnt/gen2/TmpDir/portage/app-emulation/xen-4.2.0-r1/work/xen-4.2.0/xen/xen. > efi; echo 'EFI support disabled'; fi' you have 'EFI support disabled'. Am I > right? You are right about 'EFI support disabled' being present in the build log. Is this a wrong outcome seeing there's no actual path to turning it on? work/xen-4.2.0 $ grep "efi" ./xen/arch/x86/boot/* | grep "\.o" Binary file ./xen/arch/x86/boot/built_in.o matches Binary file ./xen/arch/x86/boot/head.o matches efi it seems isn't entirely out of the loop. Thirdly, have you yet actually tried an emerge using my LDFALGS which I posted above and which generally build most anything? NOTE: x86_64-pc-linux-gnu-ld: unrecognised emulation mode: i386pep In both approaches the build has basically declared -mi386 pep un unwelcomed drop in. That said, I don't know for certain how it was pulled in or even what it does, though I do have my gcc book to look it up if I must. At this point I have two uncertainties; 1. Do you simply want xen to build with emerge? 2 Do you want efi unequivocally incorporated into the ebuild including the -m i386pep linker command? 3. Are you getting pulled in to make something work that you neither wanted not understood? Afaict the common denominator or link in your failed attempts to emerge with the ebuild appears to be the option '--as-needed' in LDFLAGS. Feel free to post again. I'm as interested in the outcomes as you, but it would help if you do tests utilising the hints or suggested changes I have noted, rather than broadening the scene with more, the only problem with that I don't have a full comprehensive knowledge of half of these intricacies, resulting in I can't outright embrace or dismiss your findings, and have to move foreward and test logically accordingly. > Firstly, do we want full efi support? I don't. Yet. > Secondly, there are no options in the initial Config.mk file or its ilk that > offer a selection of efi as a build option. Yes, because it is handled in runtime - efi/Makefile contain test for it. My gcc/ld passed that test and therefore efi was enabled. $ ld --help | grep 'supported emulations:' ld: supported emulations: aix5ppc aix5rs6 aixppc aixrs6 alpha alphavms arcelf arm_epoc_pe arm_wince_pe armaoutb armaoutl armcoff armelf armelf_fbsd armelf_linux armelf_linux_eabi armelf_nacl armelf_nbsd armelf_vxworks armelfb armelfb_linux armelfb_linux_eabi armelfb_nacl armelfb_nbsd armnbsd armnto armpe armsymbian avr1 avr2 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega1 avrxmega2 avrxmega3 avrxmega4 avrxmega5 avrxmega6 avrxmega7 coff_i860 coff_sparc crisaout criself crislinux d10velf d30v_e d30v_o d30velf delta68 elf32_dlx elf32_i860 elf32_i960 elf32_sparc elf32_sparc_sol2 elf32_sparc_vxworks elf32_spu elf32_tic6x_be elf32_tic6x_le elf32_tic6x_linux_be elf32_tic6x_linux_le elf32_tic6x_elf_be elf32_tic6x_elf_le elf32am33lin elf32b4300 elf32bfin elf32bfinfd elf32bmip elf32bmipn32 elf32bsmip elf32btsmip elf32btsmip_fbsd elf32btsmipn32 elf32btsmipn32_fbsd elf32cr16 elf32cr16c elf32crx elf32ebmip elf32ebmipvxworks elf32elmip elf32elmipvxworks elf32epiphany elf32fr30 elf32frv elf32frvfd elf32i370 elf32ip2k elf32iq10 elf32iq2000 elf32l4300 elf32lm32 elf32lm32fd elf32lmip elf32lppc elf32lppcnto elf32lppcsim elf32lsmip elf32ltsmip elf32ltsmip_fbsd elf32ltsmipn32 elf32ltsmipn32_fbsd elf32m32c elf32mb_linux elf32mcore elf32mep elf32microblaze elf32mipswindiss elf32moxie elf32mt elf32openrisc elf32ppc elf32ppc_fbsd elf32ppclinux elf32ppcnto elf32ppcsim elf32ppcvxworks elf32ppcwindiss elf32rl78 elf32rx elf32tilegx elf32tilegx_be elf32tilepro elf32vax elf32xc16x elf32xc16xl elf32xc16xs elf32xstormy16 elf32xtensa elf_i386 elf_i386_be elf_i386_chaos elf_i386_fbsd elf_i386_ldso elf_i386_nacl elf_i386_sol2 elf_i386_vxworks elf_s390 960 960coff h8300 h8300elf h8300h h8300helf h8300hn h8300hnelf h8300s h8300self h8300sn h8300snelf h8300sx h8300sxelf h8300sxn h8300sxnelf h8500 h8500b h8500c h8500m h8500s hp300bsd hp3hpux hppaelf hppalinux hppanbsd hppaobsd i386aout i386beos i386bsd i386coff i386go32 i386linux i386lynx i386mach i386moss i386msdos i386nbsd i386nto i386nw i386pe i386pe_posix i386pep lnk960 m32relf m32relf_linux m32rlelf m32rlelf_linux m68hc11elf m68hc11elfb m68hc12elf m68hc12elfb m68k4knbsd m68kaout m68kaux m68kcoff m68kelf m68kelfnbsd m68klinux m68knbsd m68kpsos m88kbcs mcorepe mipsbig mipsbsd mipsidt mipsidtl mipslit mipslnews mipspe mn10200 mn10300 msp430x110 msp430x1101 msp430x1111 msp430x112 msp430x1121 msp430x1122 msp430x1132 msp430x122 msp430x1222 msp430x123 msp430x1232 msp430x133 msp430x1331 msp430x135 msp430x1351 msp430x147 msp430x148 msp430x149 msp430x155 msp430x156 msp430x157 msp430x1610 msp430x1611 msp430x1612 msp430x167 msp430x168 msp430x169 msp430x2101 msp430x2111 msp430x2121 msp430x2131 msp430x311 msp430x312 msp430x313 msp430x314 msp430x315 msp430x323 msp430x325 msp430x336 msp430x337 msp430x412 msp430x413 msp430x415 msp430x417 msp430x435 msp430x436 msp430x437 msp430x447 msp430x448 msp430x449 msp430xE423 msp430xE425 msp430xE427 msp430xG437 msp430xG438 msp430xG439 msp430xW423 msp430xW425 msp430xW427 news ns32knbsd or32 or32elf pc532macha pdp11 pjelf pjlelf ppclynx ppcmacos ppcnw ppcpe riscix score3_elf score7_elf sh shelf shelf32 shelf32_linux shelf32_nbsd shelf_fd shelf_linux shelf_nbsd shelf_nto shelf_uclinux shelf_vxworks shl shlelf shlelf32 shlelf32_linux shlelf32_nbsd shlelf_fd shlelf_linux shlelf_nbsd shlelf_nto shlelf_vxworks shlsymbian shpe sparcaout sparclinux sparcnbsd st2000 sun3 sun4 tic30aout tic30coff tic3xcoff tic3xcoff_onchip tic4xcoff tic54xcoff tic80coff v850 vanilla vax vaxnbsd vsta w65 xgateelf z80 z8001 z8002 aarch64elf aarch64elfb aarch64linux aarch64linuxb elf32_x86_64 elf32_x86_64_nacl elf64_aix elf64_ia64 elf64_ia64_fbsd elf64_ia64_vms elf64_s390 elf64_sparc elf64_sparc_fbsd elf64_sparc_sol2 elf64alpha elf64alpha_fbsd elf64alpha_nbsd elf64bmip elf64btsmip elf64btsmip_fbsd elf64hppa elf64lppc elf64ltsmip elf64ltsmip_fbsd elf64mmix elf64ppc elf64ppc_fbsd elf64tilegx elf64tilegx_be elf_l1om elf_l1om_fbsd elf_k1om elf_k1om_fbsd elf_x86_64 elf_x86_64_fbsd elf_x86_64_nacl elf_x86_64_sol2 hppa64linux mmo shelf64 shelf64_nbsd shlelf64 shlelf64_nbsd > $ cat xen/arch/x86/efi/disabled > x86_64-pc-linux-gnu-ld: unrecognised emulation mode: i386pep > Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 i386linux elf_l1om > elf_k1om Your linker apparently has no support for i386pep emulation and your efi compilation was therefore skipped. > However, you either haven't noticed or neglected to point out it is there > also from invoking the > > $ make -j6 CC=x86_64-pc-linux-gnu-gcc LD=x86_64-pc-linux-gnu-ld -C xen > > from the source. In this the ebuild and the manual build have equal scores. > Thirdly, have you yet actually tried an emerge using my LDFALGS which I > posted above and which generally build most anything? LDFLAGS="${LDFLAGS} -Wl,--hash-style=gnu" has no effect. Problem is actually with passing LDFLAGS through portage or something similar. When you do './configure; make CC=x86_64-pc-linux-gnu-gcc LD=x86_64-pc-linux-gnu-ld -C xen' in xen source tree, you will get lines like this: x86_64-pc-linux-gnu-ld -melf_x86_64 -r -o prelink-efi.o .... Without this -melf_x86_64 present in LDFLAGS, substitution in xen/arch/x86/Makefile: 'EFI_LDFLAGS = $(patsubst -m%,-mi386pep,$(LDFLAGS)) --subsystem=10' failed. This is source of this error! Of course if your linker can't handle i386pep, this error remains hidden. As a workaround, I changed this line to 'EFI_LDFLAGS = -mi386pep $(patsubst -m%,-mi386pep,$(LDFLAGS)) --subsystem=10' by patch. So right now, xen ebuild is broken if linker has support for i386pep emulation! > NOTE: x86_64-pc-linux-gnu-ld: unrecognised emulation mode: i386pep > In both approaches the build has basically declared -mi386 pep un unwelcomed > drop in. That said, I don't know for certain how it was pulled in or even > what it does, though I do have my gcc book to look it up if I must. > > At this point I have two uncertainties; > > 1. Do you simply want xen to build with emerge? Yes, I do. :-) > 2 Do you want efi unequivocally incorporated into the ebuild including the > -m i386pep linker command? Actually I did it, because otherwise I was unable emerge xen package. > 3. Are you getting pulled in to make something work that you neither wanted > not understood? > > Afaict the common denominator or link in your failed attempts to emerge with > the ebuild appears to be the option '--as-needed' in LDFLAGS. > No, I disagree. Maybe I'm wrong, but right now I'm really convinced that problem is in portage/ebuild LDFLAGS handling. Created attachment 339684 [details, diff]
workaround, when you linker has support for i386pep emulation
right, food for thought. Your linker apparently has no support for i386pep emulation and your efi compilation was therefore skipped. ok, So how do I attain the linker support to finally put us in equal playing fields? It appears only then I can figure what and how portage impacts. Alternatively do you simply want to have it disabled so as to emerge xen? (In reply to comment #14) > right, food for thought. > > Your linker apparently has no support for i386pep emulation and your efi > compilation was therefore skipped. > > ok, So how do I attain the linker support to finally put us in equal playing > fields? It appears only then I can figure what and how portage impacts. > Alternatively do you simply want to have it disabled so as to emerge xen? That's a good question. Maybe it's because I have installed sys-devel/crossdev, but I'm just guessing... To second question, I'm happy with my patch, because I'm able to build xen package even with efi and other people without i386pep support will have their efi compilation still disabled. I'd say it's because you've installed cross-dev, and no-one else is claiming can't build xen. (In reply to comment #16) > I'd say it's because you've installed cross-dev, and no-one else is claiming > can't build xen. I claim that I still can't build xen and I don't have any crossdev toolchains installed. I still get: x86_64-pc-linux-gnu-ld: unrecognized option '--subsystem=10' wow, you xen followers continue to amaze. x86_64-pc-linux-gnu-ld: unrecognized option '--subsystem=10' occurs if 1 binutils is built with IUSE multitarget 2. the linker option -melf_x86_64" is absent, at least for amd64 which has to build to both toolchains 3. you're just unlucky To spell it out, you add -melf_x86_64 to LDFLAGS in make.conf. You will have to tolerate the inconvenience of removing any other flags as the norm since their presence confuses the xen build, but xen builds have long been confused, and or re-add them at your pleasure post xen build. Try: 23 Feb 2013; Ian Delaney <idella4@gentoo.org> +files/xen-4-efi.patch, metadata.xml, xen-4.2.0-r1.ebuild, xen-4.2.1-r1.ebuild: local efi IUSE flag added, efi support to both 4.2.0 & 4.2.1, fixes Bug #458160 by Jiří Moravec Ian: What are you up to with xen-4-efi.patch? I can't see any reason to hard code EFI_MOUNTPOINT in the Makefile. The existing EFI_MOUNTPOINT ?= /boot is fine. I'm also not sure that installing EFI binaries in /boot/ when EFI_VENDOR is unset makes sense; at the very least, /boot/efi/ would make more sense. However, it would probably make *more* sense to set EFI_VENDOR to something like "Gentoo" in the ebuild and eliminate that patch hunk entirely. Also, the dependency on binutils is screwy. See bug 458926 comment 1. right; despite already closed, second attempt has things now working at least closer to how they were intended. (All good) points addressed; (In reply to comment #19) > I can't see any reason to hard code EFI_MOUNTPOINT in the Makefile. The > existing EFI_MOUNTPOINT ?= /boot is fine. > It needs either hardcoding or, as I have now discerned, exporting in the ebuild. > However, it would probably make *more* sense to set EFI_VENDOR to something > like "Gentoo" in the ebuild and eliminate that patch hunk entirely. > ditto EFI_VENDOR. The name is at minimum a misanomer, and I finally figured how to set it AND see the executable install. # NOTE in install phase. Having this in place now, that hunk has gone. > Also, the dependency on binutils is screwy. See bug 458926 comment 1. The 2nd line was an attempt to account for the exact circumstance(s) that saw the failed build of this bug, a noble but futile cause. It's scratched, leaving users for now to figure the cause is binutils[multitarget] minus -Wl,-melf_x86_64 or stumble their way to this bug. Always more TODO. On reflection, reverted -r1 to prior state and revbumped both versions to -r2, particularly 4.2.0-r1 being a stabled version, and it definitely requires a re-emerge. $ sudo USE=efi ebuild xen-4.2.1-r2.ebuild clean merge * Official Xen Guide and the unoffical wiki page: * http://www.gentoo.org/doc/en/xen-guide.xml * http://en.gentoo-wiki.com/wiki/Xen/ * The efi executable is installed in boot/efi/gentoo >>> app-emulation/xen-4.2.1-r2 merged. >>> Regenerating /etc/ld.so.cache... It is NOT uninstallable |
