Summary: | dev-util/valgrind-3.6.1-r1 on AMD64 multilib fails to build asm for secondary target x86 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Oliver Freyermuth <o.freyermuth> |
Component: | [OLD] Development | Assignee: | Anthony Basile <blueness> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | o.freyermuth |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Complete build log (gzipped) |
Description
Oliver Freyermuth
2012-01-11 03:16:22 UTC
Created attachment 298571 [details]
Complete build log (gzipped)
(In reply to comment #1) > Created attachment 298571 [details] > Complete build log (gzipped) Hi thanks for the report. You don't have to and should attach compressed files. I haven't been able to reproduce this but let me see if we can narrow this down a bit more: 1) You have three versions of gcc: 4.2.4-r1, 4.4.6-r1, 4.5.3-r2. Which did you use? Does it even matter? Just so we're on the same page. 2) Please do the following: a) unpack valgrind-3.6.1 b) edit coregrind/m_cpuid.S and just remove the one #include "pub_core_basics_asm.h" c) gcc -c coregrind/m_cpuid.S Post any error messages. (In reply to comment #2) > (In reply to comment #1) > > Created attachment 298571 [details] > > Complete build log (gzipped) > > Hi thanks for the report. You don't have to and should attach compressed > files. Thanks for your answer, will use a non-gzipped version next time :). > > I haven't been able to reproduce this but let me see if we can narrow this down > a bit more: > > 1) You have three versions of gcc: 4.2.4-r1, 4.4.6-r1, 4.5.3-r2. Which did you > use? Does it even matter? Just so we're on the same page. I used 4.5.3-r2, but also had it with 4.5.3-r1 on the same machine before I updated gcc and can also reproduce it in 4.4.6-r1. I did not try 4.2.4-r1 yet, but it appears not to be gcc-version dependent. > 2) Please do the following: > > a) unpack valgrind-3.6.1 > > b) edit coregrind/m_cpuid.S and just remove the one #include > "pub_core_basics_asm.h" > > c) gcc -c coregrind/m_cpuid.S > Post any error messages. Did that. Actually, it produced no output on the shell but generates the object file m_cpuid.o without any problems. It is ELF64, however. I then tried: gcc -c m_cpuid.S -m32 This also works fine. Just then, I realized the file will not really contain something after the preprocessor checked all the ifs / elifs. So I tried gcc -DVGA_x86=1 m_cpuid.S -m32 This 'works', only giving me the error messages: m_cpuid.S: Assembler messages: m_cpuid.S:37: Error: junk at end of line, first unrecognized character is `(' m_cpuid.S:38: Error: invalid character '(' in mnemonic m_cpuid.S:73: Error: junk at end of line, first unrecognized character is `(' m_cpuid.S:74: Error: invalid character '(' in mnemonic I guess this is because of the removed include? At least, it accepts the lines which errored out in my emerge. As expected: gcc -DVGA_amd64=1 m_cpuid.S -m32 throws a lot of 'bad register names' (I can post them if they help in any way) and gcc -DVGA_x86=1 m_cpuid.S gives 'similar' errors to my emerge: m_cpuid.S: Assembler messages: m_cpuid.S:37: Error: junk at end of line, first unrecognized character is `(' m_cpuid.S:38: Error: invalid character '(' in mnemonic m_cpuid.S:39: Error: invalid instruction suffix for `push' m_cpuid.S:41: Error: invalid instruction suffix for `push' m_cpuid.S:42: Error: invalid instruction suffix for `pushf' m_cpuid.S:43: Error: invalid instruction suffix for `pushf' m_cpuid.S:44: Error: invalid instruction suffix for `pop' m_cpuid.S:47: Error: invalid instruction suffix for `push' m_cpuid.S:48: Error: invalid instruction suffix for `popf' m_cpuid.S:49: Error: invalid instruction suffix for `pushf' m_cpuid.S:50: Error: invalid instruction suffix for `pop' m_cpuid.S:51: Error: invalid instruction suffix for `popf' m_cpuid.S:55: Error: invalid instruction suffix for `pop' m_cpuid.S:57: Error: invalid instruction suffix for `pop' m_cpuid.S:73: Error: junk at end of line, first unrecognized character is `(' m_cpuid.S:74: Error: invalid character '(' in mnemonic m_cpuid.S:75: Error: invalid instruction suffix for `push' m_cpuid.S:77: Error: invalid instruction suffix for `push' m_cpuid.S:78: Error: invalid instruction suffix for `push' m_cpuid.S:79: Error: invalid instruction suffix for `push' m_cpuid.S:80: Error: invalid instruction suffix for `push' m_cpuid.S:81: Error: invalid instruction suffix for `push' m_cpuid.S:104: Error: invalid instruction suffix for `pop' m_cpuid.S:105: Error: invalid instruction suffix for `pop' m_cpuid.S:106: Error: invalid instruction suffix for `pop' m_cpuid.S:107: Error: invalid instruction suffix for `pop' m_cpuid.S:108: Error: invalid instruction suffix for `pop' m_cpuid.S:110: Error: invalid instruction suffix for `pop' However, as you can see in the build log, gcc was called with "-DVGA_x86=1" (even passed twice?) and "-m32" in the failing step, so I am at a loss what's happening there. WOW. I just found the culprit, although I do not understand why it happens. I have been using icecream / icecc for ages, it is in my prerootpath in make.conf and never caused any problems. I even stopped the icecream-daemon before compiling valgrind, as I thought it might have tried to send the job to another machine (although it is normally intelligent enough not to do so, and although even that should work as it copies the complete toolchain over) and nothing changed. Just now, I removed the line: PREROOTPATH="/usr/lib/icecc/bin" from my make.conf, and valgrind, all versions of it, compile fine. This is very astonishing, as icecc should only be a wrapper for gcc in case it's daemon is not running... Furthermore, I also added "/usr/lib/icecc/bin" to the $PATH in /etc/profile, so it should also have affected the simplified tests you supposed and which worked. Maybe it hiccuped on something else in the parameters it was passed, but that 'should' not happen. What I totally do not get: I successfully emerged valgrind 3.7.0-r1 on one machine on 28.11.2011 with icecc active and in PATH. The latest icecc was emerged on 5.10.2011 on said machine. As of now, I can not compile valgrind 3.7.0-r1 on the said machine without taking icecc out of the prerootpath (similiar errors to the ones I had with the stable version). So icecream did not change, and according to the changelog of the valgrind-ebuilds, the last change to 3.7.0-r1 was on 23.11.2011. So both valgrind and icecream did not change, but emerging stopped working. This leaves me at a loss against which package the bug should be reported, but valgrind appears not to be responsible. I updated portage, has some behaviour concerning prerootpath / argument passing been changed here so icecc broke? I am at a loss on how to track this down. Should this one here be marked as Resolved, or rather as Invalid (at least against valgrind)? (In reply to comment #4) > Just now, I removed the line: > PREROOTPATH="/usr/lib/icecc/bin" > from my make.conf, and valgrind, all versions of it, compile fine. That was going to be my next suggestion, given the -DVGA_x86=1. Track down what's poluting your flags. You got it. > I updated portage, has some behaviour concerning prerootpath / argument passing > been changed here so icecc broke? I am at a loss on how to track this down. I can't help you there. > Should this one here be marked as Resolved, or rather as Invalid (at least > against valgrind)? Invalid because there is nothing to fix in valgrind. |