libwebp uses wrong WORDS_BIGENDIAN value when configuring for big-endian via CMake

[C. Neidahl]

Hi!

I am here to notify you of an issue with your code when configuring for
a big-endian target via CMake, and have attached a possible fix based on
surrounding code and examples from CMake.

I am unwilling to register a Google account just to open an issue on
your bug tracker, sign the CLA attached to said account, and/or submit a
patch to your Gerrit instance. Sorry! If possible, please consider any
attached code to have whatever permissions you require for inclusion -
it is too basic for me to care, and mostly based on example code from
CMake's documentation[1] anyway. If that's not possible, feel free to
re-implement it based on the following issue description:

`/cmake/config.h.in` seems to be based on a real config that was
generated by a `configure` call at some point, with most of the settings
in it turned CMake-substitutable. But it is lacking correct handling for
`WORDS_BIGENDIAN`, which is currently hardcoded to the little-endian
behaviour of `
#undef WORDS_BIGENDIAN`[2] (which is presumably what the
system that this config was initially generated for was using). For a
big-endian target, the config file generated by `configure` instead has
`#define WORDS_BIGENDIAN 1` on this line. So `/cmake/config.h.in` needs
to have this line get filled in by CMake, instead of the current
hardcoding, and CMake needs to change the contents of this line based on
the target platform's endianness.

Included below is the `git format-patch` output for a basic change that
should address this in the following way:

1. The offending line in `/cmake/config.h.in` is adjusted to have its
contents get populated by CMake, just like the defines in the rest of
the file.
2. `/CMakeLists.txt` is adjusted to set the `WORDS_BIGENDIAN` variable
to the correct value, based on `CMAKE_C_BYTE_ORDER`.

The only difference on little-endian should be that instead of a
pointless `#undef WORDS_BIGENDIAN` in an `#ifndef WORDS_BIGENDIAN`
blo
ck, it instead produces `/* #undef WORDS_BIGENDIAN */`.

Kind regards

Cosima Neidahl

[1]:
https://cmake.org/cmake/help/git-master/variable/CMAKE_LANG_BYTE_ORDER.html#example-checking-endianness
[2]:
https://chromium.googlesource.com/webm/libwebp/+/74f6afd3e6ea8ff5b231ad2248b52bdcd1666c70/cmake/config.h.in#117

---

From eaccc97b9897cda336f4fc4137c9cab2602c2966 Mon Sep 17 00:00:00 2001
From: OPNA2608 <opna...@protonmail.com>
Date: Sun, 28 Sep 2025 23:24:34 +0200
Subject: [PATCH] cmake/config.h.in: Fix handling of WORDS_BIGENDIAN

---
CMakeLists.txt | 10 ++++++++++
cmake/config.h.in | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8e5bf75b..bc95fda5 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -55,6 +55,16 @@ set_property(CACHE WEBP_BITTRACE PROPERTY STRINGS 0 1 2)
option(WEBP_ENABLE_WUNUSED_RESULT "Add [[nodiscard]] to some functions. \
CMake must be at least 3.21 to
force C23" OFF)

+# Compatibility with autoconf configure script's way of setting this
+if(CMAKE_C_BYTE_ORDER STREQUAL "BIG_ENDIAN")
+ set(WORDS_BIGENDIAN TRUE)
+elseif(CMAKE_C_BYTE_ORDER STREQUAL "LITTLE_ENDIAN")
+ set(WORDS_BIGENDIAN FALSE)
+else()
+ set(WORDS_BIGENDIAN FALSE)
+ message(WARNING "Endianness could not be determined.")
+endif()
+
if(WEBP_LINK_STATIC)
if(WIN32)
set(CMAKE_FIND_LIBRARY_SUFFIXES .lib .a
${CMAKE_FIND_LIBRARY_SUFFIXES})
diff --git a/cmake/config.h.in b/cmake/config.h.in
index e73484b8..ef61da3f 100644
--- a/cmake/config.h.in
+++ b/cmake/config.h.in
@@ -114,6 +114,6 @@
# endif
#else
# ifndef WORDS_BIGENDIAN
-# undef WORDS_BIGENDIAN
+# cmakedefine WORDS_BIGENDIAN 1
# endif
#endif
--
2.51.0

[Vincent Rabaud]

Thank you very much for the patch, we indeed never tested that scenario.

https://chromium-review.googlesource.com/c/webm/libwebp/+/6994305 should fix it. Please comment over there if you have any issue.

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To view this discussion visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/fea6e73d-414a-41cb-b2a4-efdebed97e9e%40protonmail.com.