Cygwin build fails in configure stage

[Sören Andersen]

This report pertains to release 3.1.1 of libjpeg-turbo. I haven't (yet) tried out any older releases.

As you are no doubt aware, Cygwin provides a POSIX-like emulation layer as well as Gnu developer tools, on Microsoft Windows. I'm running Cygwin version 3.6.3-1.x86_64 on Windows 11.

When running cmake to create the build infrastructure, I hit this error:

CMake Error at CMakeLists.txt:107 (math):
math cannot parse the expression: " * 8": syntax error, unexpected
exp_TIMES (2).

The entire output is included below, for context. I am hoping someone can take a look at this and provide a fix that lets it configure on Cygwin. If that can't happen right away, I'd welcome just a reply from anyone who's built libjpeg-turbo on Cygwin in the past. BTW, I configured and built from exactly the same source kit on Debian Gnu/Linux, and as you'd expect, all went smoothly.

Thank you, Soren

---

cmake -G"Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/usr/local/libjpeg-turbo -DCMAKE_INSTALL_BINDIR=/usr/local/bin -DCMAKE_INSTALL_DOCDIR=/usr/local/share/doc /cygdrive/C/Users/somia/Downloads/libjpeg-turbo-3.1.1/
-- CMAKE_BUILD_TYPE = Release
-- VERSION = 3.1.1, BUILD = 20250719
CMake Error at CMakeLists.txt:107 (math):
math cannot parse the expression: " * 8": syntax error, unexpected
exp_TIMES (2).


-- ERROR-bit build (i386)
-- CMAKE_INSTALL_PREFIX = /usr/local/libjpeg-turbo
-- CMAKE_INSTALL_BINDIR = /usr/local/bin
-- CMAKE_INSTALL_DATAROOTDIR = share (/usr/local/libjpeg-turbo/share)
-- CMAKE_INSTALL_DOCDIR = /usr/local/share/doc
-- CMAKE_INSTALL_INCLUDEDIR = include (/usr/local/libjpeg-turbo/include)
-- CMAKE_INSTALL_LIBDIR = lib (/usr/local/libjpeg-turbo/lib)
-- CMAKE_INSTALL_MANDIR = share/man (/usr/local/libjpeg-turbo/share/man)
-- Shared libraries enabled (ENABLE_SHARED = 1)
-- Static libraries enabled (ENABLE_STATIC = 1)
-- Arithmetic decoding support enabled (WITH_ARITH_DEC = 1)
-- Arithmetic encoding support enabled (WITH_ARITH_ENC = 1)
-- TurboJPEG API library enabled (WITH_TURBOJPEG = 1)
-- TurboJPEG Java wrapper disabled (WITH_JAVA = 0)
-- Emulating libjpeg API/ABI v6.2 (WITH_JPEG7 = 0, WITH_JPEG8 = 0)
-- libjpeg API shared library version = 62.4.0
-- Compiler flags = -O3 -DNDEBUG
-- Linker flags = -Wl,--enable-auto-import
-- HIDDEN = __attribute__((visibility("hidden")))
-- INLINE = __inline__ __attribute__((always_inline)) (FORCE_INLINE = 1)
-- THREAD_LOCAL = __thread
-- Linker supports GNU-style version scripts
-- CMAKE_EXECUTABLE_SUFFIX = .exe
-- CMAKE_ASM_NASM_COMPILER = /usr/bin/nasm.exe
-- CMAKE_ASM_NASM_OBJECT_FORMAT = win32
-- CMAKE_ASM_NASM_FLAGS = -DWIN32 -DPIC
-- SIMD extensions: i386 (WITH_SIMD = 1)
-- FLOATTEST8 = sse
-- FLOATTEST12 =
-- Configuring incomplete, errors occurred!

[DRC]

That error usually means that compiler detection has failed somehow.  I have seen it happen sometimes if I try to configure a build after a previous attempt to configure the build failed.  Generally I can get rid of the error by removing ${CMAKE_BINARY_DIR}/CMakeCache.txt and ${CMAKE_BINARY_DIR}/CMakeFiles/ and trying to configure the build again.  I have also seen the error occur if CMake is unable to write to the build directory.  The root cause of the error is that CMAKE_SIZEOF_VOID_P is undefined.  That variable should be defined during compiler detection, and in newer CMake versions, it is cached in ${CMAKE_BINARY_DIR}/CMakeFiles/${CMAKE_VERSION}/CMakeCCompiler.cmake.  However, if compiler detection failed previously (for instance, due to an improperly specified compiler), then ${CMAKE_BINARY_DIR}/CMakeFiles/${CMAKE_VERSION}/CMakeCCompiler.cmake may exist but may also contain bogus information.  That would prevent compiler detection from running but also prevent CMAKE_SIZEOF_VOID_P from being defined when the build is configured again.

In your output below, compiler detection doesn't appear to occur, which supports my hypothesis.

--
You received this message because you are subscribed to the Google Groups "libjpeg-turbo User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libjpeg-turbo-u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/libjpeg-turbo-users/5150e30f-a010-45f5-92d7-8c132fb91c59n%40googlegroups.com.

[Sören Andersen]

On Monday, July 21, 2025 at 11:11:19 AM UTC-4 DRC wrote:

That error usually means that compiler detection has failed somehow.  I have seen it happen sometimes if I try to configure a build after a previous attempt to configure the build failed.  Generally I can get rid of the error by removing ${CMAKE_BINARY_DIR}/CMakeCache.txt and ${CMAKE_BINARY_DIR}/CMakeFiles/ and trying to configure the build again.

... 

In your output below, compiler detection doesn't appear to occur, which supports my hypothesis.

That's very odd, and my fault for somehow pasting incomplete information from the configure run. Here is what happens when I clean out the entirety of my build dir as recommended  (I am building o-o-s, "out-of-source [tree]" which is always my personal preference when the design of the source kit supports it, which libjpeg-turbo admirably does).

-- The C compiler identification is GNU 12.5.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /bin/gcc.exe
-- Check for working C compiler: /bin/gcc.exe - works
-- Detecting C compile features

-- Detecting C compile features - done

-- CMAKE_BUILD_TYPE = Release
-- VERSION = 3.1.1, BUILD = 20250721

CMake Error at CMakeLists.txt:107 (math):
math cannot parse the expression: " * 8": syntax error, unexpected
exp_TIMES (2).
-- ERROR-bit build (i386)

Etc. It seems that my compiler is being detected and works.

Thank you for your reply - Soren

[DRC]

Strange.  Our build system relies upon CMAKE_SIZEOF_VOID_P in order to determine whether the build is 32-bit or 64-bit.  CMAKE_SIZEOF_VOID_P is set by CMake from CMAKE_C_SIZEOF_DATA_PTR.  Generally that happens when CMake detects the C compiler ABI, which occurs in the body of the project() directive.  The fact that C compiler ABI detection is failing is probably related (although I've seen ABI detection fail without causing any further issues in the build.)

This thread seems to describe a similar issue, which was ultimately caused by a mismatch between MinGW and non-MinGW build tools in the PATH.

https://cmake.org/pipermail/cmake/2016-March/063077.html

I would suggest the same diagnostic steps described in that thread:

1. Look at ${CMAKE_BINARY_DIR}/CMakeFiles/${CMAKE_VERSION}/CMakeCCompiler.cmake, and verify that CMAKE_C_SIZEOF_DATA_PTR and/or CMAKE_C_ABI_COMPILER are incorrectly set.

2. Examine the CMake error log to determine why C compiler ABI detection failed.

3. Try to reproduce the failure with a simple CMake test.

4. Make sure that you aren't accidentally using non-Cygwin versions of GNU Make or CMake.

--
You received this message because you are subscribed to the Google Groups "libjpeg-turbo User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libjpeg-turbo-u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/libjpeg-turbo-users/c63238b6-cfb7-4c0f-b1e1-e980c220f67dn%40googlegroups.com.

[Soren]

On Mon, Jul 21, 2025 at 3:12 PM 'DRC' via libjpeg-turbo User Discussion/Support  wrote:

Strange.  Our build system relies upon CMAKE_SIZEOF_VOID_P in order to determine whether the build is 32-bit or 64-bit.  CMAKE_SIZEOF_VOID_P is set by CMake from CMAKE_C_SIZEOF_DATA_PTR.  Generally that happens when CMake detects the C compiler ABI, which occurs in the body of the project() directive.  The fact that C compiler ABI detection is failing is probably related (although I've seen ABI detection fail without causing any further issues in the build.)

Ok, I understand that well enough. 

This thread seems to describe a similar issue, which was ultimately caused by a mismatch between MinGW and non-MinGW build tools in the PATH.

https://cmake.org/pipermail/cmake/2016-March/063077.html

I would suggest the same diagnostic steps described in that thread:

1. Look at ${CMAKE_BINARY_DIR}/CMakeFiles/${CMAKE_VERSION}/CMakeCCompiler.cmake, and verify that CMAKE_C_SIZEOF_DATA_PTR and/or CMAKE_C_ABI_COMPILER are incorrectly set.

Starting at line 44 in that file, I see the following:

# Save compiler ABI information.

set(CMAKE_C_SIZEOF_DATA_PTR "")
set(CMAKE_C_COMPILER_ABI "")

I did not see CMAKE_C_ABI_COMPILER anywhere in that file, but the diagnosis is clear enough: SIZEOF_DATA_PTR is not set.

2. Examine the CMake error log to determine why C compiler ABI detection failed.

3. Try to reproduce the failure with a simple CMake test.

4. Make sure that you aren't accidentally using non-Cygwin versions of GNU Make or CMake.

I'm also looking at CMakeConfigureLog.yaml and starting at line 54 I see:

        Run Build Command(s): /usr/bin/cmake.exe -E env VERBOSE=1 /cygdrive/c/perl/c/bin/gmake.exe -f Makefile cmTC_46c61/fast
        C:/perl/c/bin/gmake  -f CMakeFiles/cmTC_46c61.dir/build.make CMakeFiles/cmTC_46c61.dir/build
        gmake[1]: Entering directory 'C:/Users/somia/build/libjpeg-turbo/CMakeFiles/CMakeScratch/TryCompile-S4sTaD'
        gmake[1]: *** No rule to make target '/usr/share/cmake-3.28.3/Modules/CMakeCCompilerABI.c', needed by 'CMakeFiles/cmTC_46c61.dir/CMakeCCompilerABI.c.o'.  Stop.
        gmake[1]: Leaving directory 'C:/Users/somia/build/libjpeg-turbo/CMakeFiles/CMakeScratch/TryCompile-S4sTaD'
        gmake: *** [Makefile:127: cmTC_46c61/fast] Error 2
   
      exitCode: 2

Somehow CMake was picking up the gmake under a mingw path late in my $PATH environment, which makes me wonder if CMake preferentially chooses a make named "gmake" over a simple "make". I know that's a wild guess. I am embarrassed (and grateful) and am going to really clean up my env ($PATH) and rerun from scratch; what I see then I will continue writing down results in this message ... ok (a little later) YOU KNOW WHAT, it is fixed. YEAH! Your suggested steps for locating  the cause of the failure were spot-on. Thank you very much! I now see:

At line 44 in CMakeCCompiler.cmake:

# Save compiler ABI information.

set(CMAKE_C_SIZEOF_DATA_PTR "8")

set(CMAKE_C_COMPILER_ABI "")

I'm happy to report that libjpeg-turbo builds completely on Cygwin once such mistakes are unmade. I've learned quite a lesson with this problem.

Best regards,

    Soren

[DRC]

It's all good.  I had never seen this specific cause for that error before, so this exercise will help me diagnose it if I encounter it in the future.

--
You received this message because you are subscribed to the Google Groups "libjpeg-turbo User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libjpeg-turbo-u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/libjpeg-turbo-users/CAGB_HuTM9NBkuLPiNLfJww0YtBDd4RWNG-LX3LyZ%2B-LqpSyA0g%40mail.gmail.com.