Summary: | dev-lang/nasm: built with <sys-devel/gcc-4.6 produces code that cannot be compiled on AMD E-350 CPU (eg. media-libs/libjpeg-turbo-1.1.1) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Anders Kreinøe <anders> |
Component: | Current packages | Assignee: | Mr. Bones. (RETIRED) <mr_bones_> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | anarchy, gentoo, kipplasterjoe, ssuominen, toolchain |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
environment |
Description
Anders Kreinøe
2011-12-02 05:15:43 UTC
Created attachment 294477 [details]
build.log
Created attachment 294479 [details]
environment
(In reply to comment #0) > Portage 2.3.2 (default/linux/amd64/2008.0, gcc-4.4.5, glibc-2.11.3-r0, > 2.6.32-042stab037.1 x86_64) > Linux-2.6.32-042stab037.1-x86_64-AMD_E-350_Processor-with-gentoo-2.1.8 > Timestamp of tree: Thu, 01 Dec 2011 06:30:01 +0000 http://forums.gentoo.org/viewtopic-t-876475-start-0-postdays-0-postorder-asc-highlight-.html I believe you are using too old gcc for the CPU. Propably needs gcc-4.6.x. Try ~arch version of media-libs/jpeg-turbo. It also has support for yasm, so you could "emerge -C nasm" and "emerge -1 yasm" for another try. If nothing else helps, you can always use media-libs/jpeg for now. @toolchain: what do you think? I had come to the same conclusion. I have tried the ~arch version, but it also fails. I am currently updating gcc to gcc-4.6.2 to se if that fixes the problem, i will report back when im done. The gcc-upgrade alone did not help, but emerge yasm made it build i wouldn't mind making yasm a requirement where possible over nasm (In reply to comment #5) > The gcc-upgrade alone did not help, but emerge yasm made it build let me get clarification. did you try re-emerging nasm with gcc-4.6.2? (In reply to comment #6) > i wouldn't mind making yasm a requirement where possible over nasm yasm support is only in 1.1.90, and it was just added... not mature enough to be used as default in libjpeg-turbo yet The gcc-upgrade alone did not help, but emerge yasm made it build (In reply to comment #7) > (In reply to comment #5) > > The gcc-upgrade alone did not help, but emerge yasm made it build > > let me get clarification. did you try re-emerging nasm with gcc-4.6.2? ahh, actually i did. I removed nasm and emerged yasm before trying to re-emerge libjpeg-turbe, but that pulled ind nasm as a dependency, and it was thereby rebuild with gcc-4.6.2. Thats properly why it works now. you lost me. why is this a gcc problem and not nasm ? (In reply to comment #11) > you lost me. why is this a gcc problem and not nasm ? Because everything dependent on nasm fails to build on the AMD-E-350 CPU if nasn is build by <GCC-4.6. Whether that is nasm og gcc fault is beyond my knowledge, but it could indicate that <GCC-4.6 compiles a defect nasm somehow. Anyway, upgrading to GCC-4.6 and rebuilding nasm solves to problem, so this bug will be solved when GCC-4.6 is stabilized. (In reply to comment #12) this description says to me it's a bug in nasm, not gcc As a temporary fix, could it be possibly to make virtual/jpeg depend on media-libs/jpeg in the case of <gcc-4.6 and a AMD E-350 CPU, and media-libs/libjpeg-turbo in other cases? It would solve the specific case I had trouble with, so other users would not run into the same problem. yeah, i don't think that really works (In reply to comment #0) I'm surprised your system works at all. -march=k8 turns on 3dnow vectorization etc. which the E-350 doesn't support. Use the generic -march=x86-64 as native support for that proc was only added with gcc 4.6 (In reply to comment #16) > (In reply to comment #0) > > I'm surprised your system works at all. -march=k8 turns on 3dnow vectorization > etc. which the E-350 doesn't support. Use the generic -march=x86-64 as native > support for that proc was only added with gcc 4.6 uh, good point For the records: I ran into the same issue on a new install using the 11.2 live DVD as follows System is a core i5, I'm running 32bit guest on 64 bit host. -> Boot liveDVD-32bit -> install from i686 stage3 -> nasm shipped with the stage does not work -> nasm compiled with -march=native does not work I solved the problem by recompiling nasm with -march=prescott Then everything worked with the stable versions of nasm, gcc, and libjpeg-turbo oog. what does `echo "" | gcc -march=native -v -E - 2>&1 | grep cc1` output? -march=native only works with gcc 4.6 and later for the E-350. Earlier gccs will unwittingly turn on 3dnow by way of -march=native. Folks should just use -march=i686 or -march=x86-64 (works great here.) Could there be implemented a feature in portage, detecting these known broken configurations, and warn the users? It would save a lot of trouble for people if they got a warning like "The combination of cpu=x, gcc-version=y and the use of march=native is invalid, use march=z instead" when trying to use emerge. (In reply to comment #18) > For the records: I ran into the same issue on a new install using the 11.2 live > DVD as follows > > System is a core i5, I'm running 32bit guest on 64 bit host. > > -> Boot liveDVD-32bit > -> install from i686 stage3 > -> nasm shipped with the stage does not work what? stage3 ships nasm? i really doubt it (In reply to comment #21) > Could there be implemented a feature in portage, detecting these known broken > configurations, and warn the users? It would save a lot of trouble for people > if they got a warning like "The combination of cpu=x, gcc-version=y and the use > of march=native is invalid, use march=z instead" when trying to use emerge. overkill nothing really left to do here: use only native if you are sure the gcc supports it for your cpu checking for invalid combinations gets very ugly very quickly and outstrips the original goal due to false positives: to make the life better for the user. *** Bug 413741 has been marked as a duplicate of this bug. *** |