Summary: | dev-libs/boost-1.51.0-r1 32bit building fails on amd64: errors in libs/context/src/asm/fcontext_i386_sysv_elf_gas.S | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Thomas Sachau <tommy> |
Component: | [OLD] Library | Assignee: | Thomas Sachau <tommy> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | andreasoehler, cpp+disabled, crabbedhaloablution, flameeyes |
Priority: | Normal | ||
Version: | autobuilds | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Thomas Sachau
2012-11-03 15:39:45 UTC
Created attachment 328222 [details]
build.log
libs/context/src/asm/fcontext_i386_sysv_elf_gas.S: Assembler messages: libs/context/src/asm/fcontext_i386_sysv_elf_gas.S:71: Error: operand type mismatch for `jmp' libs/context/src/asm/fcontext_i386_sysv_elf_gas.S:85: Error: invalid instruction suffix for `push' libs/context/src/asm/fcontext_i386_sysv_elf_gas.S:86: Error: invalid instruction suffix for `push' libs/context/src/asm/fcontext_i386_sysv_elf_gas.S:87: Error: invalid instruction suffix for `push' libs/context/src/asm/fcontext_i386_sysv_elf_gas.S:89: Error: invalid instruction suffix for `pop' libs/context/src/asm/fcontext_i386_sysv_elf_gas.S:93: Error: invalid instruction suffix for `pop' libs/context/src/asm/fcontext_i386_sysv_elf_gas.S:94: Error: invalid instruction suffix for `pop' libs/context/src/asm/fcontext_i386_sysv_elf_gas.S:95: Error: invalid instruction suffix for `pop' libs/context/src/asm/fcontext_i386_sysv_elf_gas.S:104: Error: invalid instruction suffix for `pop' libs/context/src/asm/fcontext_i386_sysv_elf_gas.S:115: Error: invalid instruction suffix for `pop' libs/context/src/asm/fcontext_i386_sysv_elf_gas.S:119: Error: invalid instruction suffix for `push' Any chance this points to binutils 2.23 ? No it's because the bloody piece of junk now ships with assembly files that are compiled with GCC+GAS but don't get ASFLAGS passed down, it seems. FFS. But Thomas you'll have to find the way to fix it, I'd say — this can only present itself with your multilib portage, and I'm not really looking forward to testrun it. (In reply to comment #3) > No it's because the bloody piece of junk now ships with assembly files that > are compiled with GCC+GAS but don't get ASFLAGS passed down, it seems. > > FFS. So if you see the issue, why dont you fix it or at least provide a patch to test your suggested fix? (In reply to comment #4) > But Thomas you'll have to find the way to fix it, I'd say — this can only > present itself with your multilib portage, and I'm not really looking > forward to testrun it. You volunteered to maintain this package, so you should find a way to fix it. You are free to request additional infos and i can test any patch you provide, so lets do it the same way as with any other package and maintainer: -i report the issue. -you request the needed details to find the reason -you provide a fix -i test the fix and confirm it works -you commit the fix Exactly I _volunteered_ so I owe you nothing. I debugged the issue, I found the problem, I have no freaking way to test it, and it only presents itself with a non-default package manager configuration. I'm basically doing the same for HPPA since I don't have such a box. Now you either take the help I provided you (the diagnosis) and find a way around it, or if you re-reassign this again I'm going to close it as RESO WONTFIX "Use a standard package manager", does it feel better? Actually, scratch that, this will likely be bundled with bug #443012 — I'll just disable context until somebody _really_ needs it. And we might hope that upstream will make it a tad more reliable next time. |