Description of problem: Building darktable does not honor RPM_OPT_FLAGS/%optflags. Version-Release number of selected component (if applicable): darktable-1.6.9 How reproducible: Always. Steps to Reproduce: 1. build the package in mock 2. check build.log Expected results: The package to honor RPM_OPT_FLAGS. Additional info: Packages, which do not honor RPM_OPT_FLAGS need to be considered to be miscompiled and should be removed from Fedora. Actually, I am wonder why darktable currently doesn't FTBS, because cases like these, these days normally trigger an FTBFS.
darktable-1.6.9-1.fc21 build seems to use them ok, an example: cd /builddir/build/BUILD/darktable-1.6.9/i686-redhat-linux-gnu/src/dtview && /usr/bin/cc -DGDK_DISABLE_DEPRECATED -DGSEAL_ENABLE -DGTK_DISABLE_DEPRECATED -DGTK_DISABLE_SINGLE_INCLUDES -DHAVE_CONFIG_H -DHAVE_GPHOTO2 -DHAVE_GPHOTO_25_OR_NEWER -DHAVE_GRAPHICSMAGICK -DHAVE_HTTP_SERVER -DHAVE_KWALLET -DHAVE_LENSFUN -DHAVE_LIBSECRET -DHAVE_MAP -DHAVE_OPENCL -DHAVE_OPENEXR -DHAVE_OPENJPEG -DHAVE_OPENJPEG_ICC -DHAVE_RAWSPEED -DUSE_COLORDGTK -DUSE_GETTEXT -D_XOPEN_SOURCE=700 -D__GDK_KEYSYMS_COMPAT_H__ -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -std=c99 -fopenmp -Wall -fno-strict-aliasing -pthread -mtune=generic -msse3 -g -mfpmath=sse -D_RELEASE -DNDEBUG -O3 -ffast-math -fno-finite-math-only -fexpensive-optimizations -I/builddir/build/BUILD/darktable-1.6.9/src -I/builddir/build/BUILD/darktable-1.6.9/src/external -I/builddir/build/BUILD/darktable-1.6.9/src/external/LibRaw -isystem /usr/include/glib-2.0 -isystem /usr/lib/glib-2.0/include -isystem /usr/include/gtk-2.0 -isystem /usr/lib/gtk-2.0/include -isystem /usr/include/cairo -isystem /usr/include/pango-1.0 -isystem /usr/include/atk-1.0 -isystem /usr/include/libxml2 -isystem /usr/include/libsoup-2.4 -isystem /usr/include/OpenEXR -isystem /usr/include/lensfun -isystem /usr/include/librsvg-2.0 -isystem /usr/include/gdk-pixbuf-2.0 -isystem /usr/include/json-glib-1.0 -isystem /usr/include/openjpeg-1.5 -isystem /usr/include/libsecret-1 -isystem /usr/include/GraphicsMagick -I/builddir/build/BUILD/darktable-1.6.9/i686-redhat-linux-gnu/src -I/builddir/build/BUILD/darktable-1.6.9/src/external/osm-gps-map/src -isystem /usr/include/colord-1 -I/builddir/build/BUILD/darktable-1.6.9/src/external/colord-gtk/src -isystem /usr/include/SDL -I/builddir/build/BUILD/darktable-1.6.9/src/dtview/.. -I/builddir/build/BUILD/darktable-1.6.9/i686-redhat-linux-gnu/src/dtview/.. -Werror=implicit-function-declaration -o CMakeFiles/darktable-viewer.dir/main.c.o -c /builddir/build/BUILD/darktable-1.6.9/src/dtview/main.c
Reopening. Have a closer look into your log: ... -O3 -ffast-math -fno-finite-math-only -fexpensive-optimizations ... Putting aside the silly -msse* stuff, that's all overriding RPM_OPT_FLAGS == broken.
OK, thanks. You should have included that detail in the original report. I'd argue that those are probably mostly safe though, upstream *probabably* wouldn't have added them if they didn't know what they were doing, right? :)
Created attachment 1090133 [details] Comment out overriding CFLAGS etc. This attachment comments out most places which override CFLAGS etc. from src/CMakeLists.txt to let darktable better honor RPM_OPT_FLAGS. I am aware this is more a brute-force hack but a real solution, but I am not sufficiently familiar with cmake to provide a better solution.
upstream has a better cmake flag supposedly
http://redmine.darktable.org/issues/10696#note-2 -DCUSTOM_CFLAGS=ON
Created attachment 1090183 [details] Apply -DCUSTOM_CFLAGS=ON Thx for the hint, Rex. Next attempt.
That adds -msse3 , isn't that dangerous? (particularly on non x86_64 archs?)
One of upstream developer says: [16:47] <LebedevRI> e.g. after line 83 http://pkgs.fedoraproject.org/cgit/darktable.git/tree/darktable.spec#n83 [16:48] <LebedevRI> add line -DCUSTOM_CFLAGS=ON \ (In reply to Rex Dieter from comment #8) > That adds -msse3 , isn't that dangerous? (particularly on non x86_64 archs?) Darktable needs SSE3 instruction set. Tonight I will apply the changes
except, fedora's i686 arch support explicitly excludes that, doesn't it?
(In reply to Rex Dieter from comment #10) > except, fedora's i686 arch support explicitly excludes that, doesn't it? i686 should not exclude SSE3 support...
As far as I know, not even sse2 is supported (only cmov): https://fedoraproject.org/wiki/Features/F12X86Support which should still be true
(In reply to Rex Dieter from comment #8) > That adds -msse3 , isn't that dangerous? (particularly on non x86_64 archs?) Yes. That's what I previously called the "-msse* stuff", darktable internally depends on -msse3, unconditionally adds it to its CFLAGS (on all archs) when not using -DCUSTOM_FLAGS and fails to build without it. It's just that -DCUSTOM_CFLAGS makes this design flaw and non-portability explicit. (In reply to Germano Massullo from comment #11) > (In reply to Rex Dieter from comment #10) > > except, fedora's i686 arch support explicitly excludes that, doesn't it? > > i686 should not exclude SSE3 support... Fedora packages are not supposed to use -msse3! This package will fail at runtime on certain processors, because it violates these processors' instruction sets. I *deliberately* ignored this aspect in my patches. Pedantically speaking, we would have to insist on the dependency on -msse3 to be removed or this package be removed from Fedora. (In reply to Rex Dieter from comment #12) > As far as I know, not even sse2 is supported (only cmov): This matches with my memory.
Further additions: - Darktable's implicit addition of -msse3 is visible in comment #1: ... -fno-strict-aliasing -pthread -mtune=generic -msse3 -g -mfpmath=sse -D_RELEASE ... - This happens when running darktable on a CPU without sse3: $ darktable [dt_init] unfortunately we depend on SSE3 instructions at this time. [dt_init] please contribute a backport patch (or buy a newer processor).
(In reply to Germano Massullo from comment #9) > Darktable needs SSE3 instruction set.
(In reply to Germano Massullo from comment #15) > (In reply to Germano Massullo from comment #9) > > Darktable needs SSE3 instruction set. Your view - My view: Darktable needs to be fixed. It's a non-portable mess.
Germano, why did you close this bug? This BZ is not about -msse3, this BZ is about this package doing crazy things to CFLAGS.
packaging guidelines only say: "Overriding these flags for performance optimizations (for instance, -O3 instead of -O2) is generally discouraged." 1. RPM_OPT_FLAGS are generally being used here 2. are being overridden or added-to in some essential ways (-fsse3 is required, for example). So, unless you can identify any concrete/real harm, I'd tend to side with upstream and the downstream maintainer opinion here.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening - I think this BZ was not reacted appropriately and am inclined to feel the current maintainers are overwhelmed by the package.
it was handled appropriately, feel free to ask fesco to intervene (and override maintainer discretion) if you feel otherwise.