ImageMagick-6.9.0.10-1 fails to built & run some x64 archs, e.g. Intel(R) Pentium(R) CPU G850 @ 2.90GHz error message lt-zoom[3511] trap invalid opcode ip:7f9aef63706e sp:7fffad087630 error:0 in libMagickCore-6.Q16.so.2.0.0[7f9aef483000+245000] The reason - ImageMagick guesses (by trying various gcc option) intel core-i7 and uses corresponding -march=. This creates a non-working build. The fix is to add to configure in imagemagick spec this option --with-gcc-arch=x86-64 with this option ImageMagick passes all the tests and working fine. Similar problem existed in archlinux https://bugs.archlinux.org/task/37596
I ran into the same issue and pushed http://pkgs.fedoraproject.org/cgit/ImageMagick.git/commit/?id=225d561423c0cf86eda306880af88b742c5f5987 which should hopefully fix this up.
*** Bug 1217741 has been marked as a duplicate of this bug. ***
*** Bug 1214344 has been marked as a duplicate of this bug. ***
Kalev, but it is not fix, just workaround! How you find it? What is real reason?
A number of packages use 'convert' during build time to convert images from one format to other. 'convert' was crashing and blocking all their builds in koji.
It is known. I ask about workaround and gcc optimisation.
No answer from Kalev why --without-gcc-arch flag should help. Possible just rebuild helps as it helps now. It seams GCC in rawhide fixed. I have tried it after mass rebuilds. ImageMagick built fine, and mediainfo (#1214344) also on rawhide-test machine where that problem was reproducible in the past. Made there workarounds reverted, new build follow.
Please revert this. You must pass --without-gcc-arch to official Fedora ImageMagick builds. If you don't do that, ImageMagick gets optimized for whatever CPU the build host happens to have and crashes on older CPUs.
As I see now it is not case now. Could you still reproduce it?
As I kindly request early description why you think it is required - you don't do that. According to http://www.gnu.org/software/autoconf-archive/ax_gcc_archflag.html it disable arch detection, so do not honor Fedora build flags as by guidelines. If we so doing such it require justification comments.
Mediainfo scratch build successful http://koji.fedoraproject.org/koji/taskinfo?taskID=9767106
Reopening as the fix got reverted in rawhide. (In reply to Pavel Alexeev (aka Pahan-Hubbitus) from comment #10) > According to http://www.gnu.org/software/autoconf-archive/ax_gcc_archflag.html it disable arch detection, so do not honor Fedora build flags as by guidelines. If we so doing such it require justification comments. No, it is the other way around. You must pass --without-gcc-arch to honour Fedora's build flags; if you don't do that it overrides --march which is not allowed in Fedora. See the build logs: https://kojipkgs.fedoraproject.org//packages/ImageMagick/6.9.1.2/3.fc23/data/logs/x86_64/build.log CFLAGS = -I/usr/include/freetype2 -I/usr/include/libpng16 -fopenmp -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -march=corei7 -fexceptions -pthread -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -march=corei7 comes from the ax_gcc_archflag macro and must not be used in generic Fedora builds.
gcc manual page explains the -march flag as follows: -march=cpu-type Generate instructions for the machine type cpu-type. In contrast to -mtune=cpu-type, which merely tunes the generated code for the specified cpu-type, -march=cpu-type allows GCC to generate code that may not run at all on processors other than the one indicated. Specifying -march=cpu-type implies -mtune=cpu-type. If you use -march=corei7, gcc generates code which is only guaranteed to run on corei7 and is likely to crash with invalid opcode errors on older CPUs.
>You must pass --without-gcc-arch to honour Fedora's build flags; if you don't do that it overrides --march which is not allowed in Fedora From what document do you conclude them? If I right understand --without-gcc-arch is generic flag of GNU autotools and it is not present in %configure, so not required or default.
Furthermore, ImageMagick (and many other I think) built without it for ages is not?
(In reply to Pavel Alexeev (aka Pahan-Hubbitus) from comment #15) > Furthermore, ImageMagick (and many other I think) built without it for ages > is not? No, it's a regression in the latest version of ImageMagick that's in rawhide. In that new version in rawhide, it has started using the AX_GCC_ARCHFLAG macro that adds the --with/without-gcc-arch flags. It's apparently enabled by default and needs turning off for generic builds. Fedora is a generic distro that supports a wide variety of CPUs, not just corei7. Thus, you cannot use flags that make it only work on corei7 and crash on other CPUs.
(In reply to Kalev Lember from comment #16) > In that new version in rawhide, it has started using the AX_GCC_ARCHFLAG > macro that adds the --with/without-gcc-arch flags. It's apparently enabled > by default and needs turning off for generic builds. Hm, it interesting. Where you find it or think so? Kalev in any case thank you very much for your time and contribution.
I've ask upstream about changes there.
And please, do not change bug meaning completely. Build fail in rawhide fixed. If you think something should be changed also - please fill new bug.
I have escalated this to FESCo. https://fedorahosted.org/fesco/ticket/1443
Please restore the --without-gcc-arch. Without it the compiler uses -march=corei7 [1] while building which is not what we want in Fedora. -march=corei7 means that the code might not run on x86_64 CPUs that are not corei7. [1] https://kojipkgs.fedoraproject.org//packages/ImageMagick/6.9.1.2/3.fc23/data/logs/x86_64/build.log
Changed the summary to make the purpose of this bug clearer. The initial comment is a bit misleading and/or confusing. It says: "ImageMagick-6.9.0.10-1 fails to built & run some x64 archs, e.g. Intel(R) Pentium(R) CPU G850 @ 2.90GHz". I am not sure why ImageMagick itself would have failed to build. I don't see it calling convert(1) during its own build. I could be missing something. In any case I think the summary can be improved to better reflect the issue that we are dealing with.