[Pkg-phototools-devel] Bug#857147: darktable builds with -msse2 on i386

[Adrian Bunk]

On Wed, Mar 08, 2017 at 04:25:18PM +0300, Roman Lebedev wrote:
> On Wed, Mar 8, 2017 at 3:38 PM, Adrian Bunk <bunk at debian.org> wrote:
> > Source: darktable
> > Version: 2.2.1-2
> > Severity: serious
> >
> > https://buildd.debian.org/status/fetch.php?pkg=darktable&arch=i386&ver=2.2.1-2&stamp=1483383078&raw=0
> >
> > ...
> > -- Performing Test _MSSE2
> > -- Performing Test _MSSE2 - Success
> > -- Building SSE2-optimized codepaths: ON
> > ...
> > [  4%] Building C object src/external/LuaAutoC/CMakeFiles/lautoc.dir/lautoc.c.o
> > cd /«PKGBUILDDIR»/obj-i686-linux-gnu/src/external/LuaAutoC && /usr/bin/cc  -DGDK_DISABLE_DEPRECATED -DGDK_VERSION_MIN_REQUIRED=GDK_VERSION_3_14 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_MIN_REQUIRED -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DGTK_DISABLE_DEPRECATED -DGTK_DISABLE_SINGLE_INCLUDES -DHAVE_BUILTIN_CPU_SUPPORTS -DHAVE_CONFIG_H -DHAVE_GPHOTO2 -DHAVE_GPHOTO_25_OR_NEWER -DHAVE_GRAPHICSMAGICK -DHAVE_HTTP_SERVER -DHAVE_KWALLET -DHAVE_LENSFUN -DHAVE_LIBSECRET -DHAVE_OPENCL -DHAVE_OPENEXR -DHAVE_OPENJPEG -DUSE_LUA -D_RELEASE -D_XOPEN_SOURCE=700 -D__GDK_KEYSYMS_COMPAT_H__ -I/«PKGBUILDDIR»/src -I/«PKGBUILDDIR»/src/external -isystem /usr/include/glib-2.0 -isystem /usr/lib/i386-linux-gnu/glib-2.0/include -isystem /usr/include/gtk-3.0 -isystem /usr/include/at-spi2-atk/2.0 -isystem /usr/include/at-spi-2.0 -isystem /usr/include/dbus-1.0 -isystem /usr/lib/i386-linux-gnu/dbus-1.0/include -isystem /usr/include/gio-unix-2.0 -isystem /usr/include/cairo -isystem /usr/include/pango-1.0 -isystem /usr/include/harfbuzz -isystem /usr/include/atk-1.0 -isystem /usr/include/pixman-1 -isystem /usr/include/freetype2 -isystem /usr/include/libpng16 -isystem /usr/include/gdk-pixbuf-2.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/i386-linux-gnu -isystem /usr/include/json-glib-1.0 -isystem /usr/include/openjpeg-2.1 -isystem /usr/include/libsecret-1 -isystem /usr/include/GraphicsMagick -I/«PKGBUILDDIR»/obj-i686-linux-gnu/src -isystem /usr/include/lua5.2 -I/«PKGBUILDDIR»/src/external/LuaAutoC -I/«PKGBUILDDIR»/src/external/LuaAutoC/include  -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -fno-strict-aliasing -Wformat -Wformat-security -Wshadow -Wtype-limits -Wvla -Wold-style-declaration -Wno-error=varargs -Wframe-larger-than=32768 -Wstack-usage=32768 -Wlarger-than=524288 -std=c99 -fopenmp -pthread -mtune=generic -msse2 -g -mfpmath=sse -std=gnu99 -Wall -Wno-unused -O3 -g  -fPIC   -o CMakeFiles/lautoc.dir/lautoc.c.o   -c /«PKGBUILDDIR»/src/external/LuaAutoC/lautoc.c
> > ...
> >
> > These are not SSE2 codepaths with autodetection,
> > the package seems to be built in a way that it
> > won't run on hardware without SSE2.
> Hi.
> 
> Given that arm64 is now 'supported', it is certainly possible to build
> without SSE2.

What is actually the reason why arm64 is declared supported but
mips64el and ppc64el are not?

Even if the package works properly only on 64bit little endian,
all of them should work equally well.

> However, there is a run-time detection, and if there is no SSE2,
> darktable will (should?) nicely refuse to start.

It is just a warning.

And the file where the detection code is is itself built with
"-msse2 -mfpmath=sse"...

Upstream seems to have the bug of first implementing proper 
autodetection and (at least partially with ->funcsse) runtime
selection, and then building *everything* with -msse2.

> Given the nature of the program - computationally-intensive - it makes
> very little sense to run it on
> ancient hardware.

And it does not make sense to run i386 on non-ancient hardware.

Netbooks with older Intel Atoms or the OLPC XO are basically the most 
recent machines where amd64 cannot be used.

It is also dangerous to make the supported CPUs a per-package decision:
You would quickly end up with some packages requiring AVX, or using
features that are only present on recent Intel (and not AMD) CPUs.

> As of 2.0 release, non-64bit build is pretty much deprecated.
> It prints noisy GUI message, and frequently crashes.
>...
> So if this is so serous, I'd propose to just kill i386 build for dt.

Even ignoring the SSE2 question, aren't you basically saying that the 
i386 package is known broken - and upstream doesn't give a damn?

> Roman.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed