| Summary: | Build failure on i686 | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Antonio Rojas <arojas> |
| Component: | Portability-Compilation | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, geiger.david68210, lexa, rdieter |
| Priority: | NOR | ||
| Version: | 5.1.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/digikam/067a88d8c84a5149469961d54b1d5c93df6a3167 | Version Fixed In: | 5.2.0 |
| Sentry Crash Report: | |||
| Attachments: | quick-n-dirty fix | ||
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 |
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