digikam 5.1.0 fails to build on i686, using GCC 6.1.1. Works fine on x86_64 [ 50%] Building CXX object core/libs/rawengine/CMakeFiles/rawengine_srcs.dir/drawdecoder.cpp.o In file included from /build/digikam/src/digikam-5.1.0/core/libs/rawengine/libraw/libraw/libraw_datastream.h:36:0, from /build/digikam/src/digikam-5.1.0/core/libs/rawengine/libraw/libraw/libraw.h:40, from /build/digikam/src/digikam-5.1.0/core/libs/rawengine/drawdecoder_p.h:46, from /build/digikam/src/digikam-5.1.0/core/libs/rawengine/drawdecoder.cpp:31: /build/digikam/src/digikam-5.1.0/core/libs/rawengine/libraw/libraw/libraw_types.h:630:2: error: #error Unable to figure out byte order. #error Unable to figure out byte order. ^~~~~ make[2]: *** [core/libs/rawengine/CMakeFiles/rawengine_srcs.dir/build.make:63: core/libs/rawengine/CMakeFiles/rawengine_srcs.dir/drawdecoder.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:5838: core/libs/rawengine/CMakeFiles/rawengine_srcs.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... Reproducible: Always
Right, i don't compile this libraw code in 32 bits Linux, only on Windows 32 with MinGw. I will install a 32 bits Tux VM and fix the problem. Gilles Caulier
confirmed
Which Linux distro did you use exactly ? Gilles Caulier
(In reply to caulier.gilles from comment #3) > Which Linux distro did you use exactly ? > > Gilles Caulier Arch
I verified the i686 FTBFS on fedora 25 (development branch)
It sound like the byte order test is changed with GCC : https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ __ORDER_BIG_ENDIAN__ __ORDER_PDP_ENDIAN__ __BYTE_ORDER__ is defined to one of the values __ORDER_LITTLE_ENDIAN__, __ORDER_BIG_ENDIAN__, or __ORDER_PDP_ENDIAN__ to reflect the layout of multi-byte and multi-word quantities in memory. If __BYTE_ORDER__ is equal to __ORDER_LITTLE_ENDIAN__ or __ORDER_BIG_ENDIAN__, then multi-byte and multi-word quantities are laid out identically: the byte (word) at the lowest address is the least significant or most significant byte (word) of the quantity, respectively. If __BYTE_ORDER__ is equal to __ORDER_PDP_ENDIAN__, then bytes in 16-bit words are laid out in a little-endian fashion, whereas the 16-bit subwords of a 32-bit quantity are laid out in big-endian fashion. You should use these macros for testing like this: /* Test for a little-endian machine */ #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ Something like this must be add in rules from libraw_type.h Gilles Caulier
Confirmed also here on Mageia6 (Cauldron): http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20160809103222.ennael.duvel.26316/log/digikam-5.1.0-1.mga6/build.0.20160809103357.log
Created attachment 100514 [details] quick-n-dirty fix here's a quick-n-dirty patch I used that fixes it for me
Yes the fix sound like correct for me and simple. In fact, this code come from Libraw. I CC Libraw team as feedback. The right fix will appear in offcial Libraw 0.18.0 that i will backport. Gilles Caulier
Git commit 067a88d8c84a5149469961d54b1d5c93df6a3167 by Gilles Caulier. Committed on 09/08/2016 at 18:41. Pushed by cgilles into branch 'master'. apply patch #100514 to fix broken compilation under 32 bits platform with GCC 6.1 FIXED-IN: 5.2.0 M +2 -1 NEWS M +9 -2 libs/rawengine/libraw/libraw/libraw_types.h http://commits.kde.org/digikam/067a88d8c84a5149469961d54b1d5c93df6a3167