error ZLIB_VERNUM != PNG_ZLIB_VERNUM

[Mark Olesen]

Running under Windows 10 msys64

using builtin zlib, jpeg, png

getting build error on png

Seems like something with the include path? I tried to add include_target_directories to  on avail

ZLIB_VERNUM in zlib does match PNG_ZLIB_VERSION in png

no clue

thanks for the help

Cloning into 'fltk'...

remote: Enumerating objects: 78198, done.
remote: Counting objects: 100% (1779/1779), done.
remote: Compressing objects: 100% (1086/1086), done.
remote: Total 78198 (delta 1111), reused 1265 (delta 685), pack-reused 76419
Receiving objects: 100% (78198/78198), 29.80 MiB | 11.41 MiB/s, done.
Resolving deltas: 100% (63921/63921), done.
Updating files: 100% (1366/1366), done.
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /mingw64/bin/x86_64-w64-mingw32-gcc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /mingw64/bin/x86_64-w64-mingw32-g++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of short
-- Check size of short - done
-- Check size of int
-- Check size of int - done
-- Check size of long
-- Check size of long - done
-- Check size of long long
-- Check size of long long - done
-- Found PkgConfig: /mingw64/bin/pkg-config.exe (found version "1.8.0")
-- Looking for POSIX compatible scandir
-- POSIX compatible scandir - not found
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
-- cannot find system zlib library - using built-in

-- Could NOT find JPEG (missing: JPEG_LIBRARY JPEG_INCLUDE_DIR)
-- cannot find system jpeg library - using built-in

-- Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.11")
-- Could NOT find PNG (missing: PNG_LIBRARY PNG_PNG_INCLUDE_DIR)
-- cannot find system png library - using built-in


-- Configuration Summary for FLTK 1.4.0 generated by CMake 3.22.1 --

-- The following OPTIONAL packages have not been found:

 * Doxygen
 * JPEG
 * ZLIB
 * PNG

-- Static libraries will be built in /home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/build/lib
-- Shared libraries will not be built (set OPTION_BUILD_SHARED_LIBS=ON to build)
-- Example programs will not be built (set FLTK_BUILD_EXAMPLES=ON to build)
-- Image Libraries: JPEG = Builtin
--                  PNG  = Builtin
--                  ZLIB = Builtin
-- Cairo support:   No

-- End of Configuration Summary --

-- Configuring done
-- Generating done
-- Build files have been written to: /home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/build
[  0%] Building C object zlib/CMakeFiles/fltk_z.dir/adler32.c.obj
[  0%] Building C object zlib/CMakeFiles/fltk_z.dir/compress.c.obj
[  1%] Building C object zlib/CMakeFiles/fltk_z.dir/crc32.c.obj
[  1%] Building C object zlib/CMakeFiles/fltk_z.dir/deflate.c.obj
[  1%] Building C object zlib/CMakeFiles/fltk_z.dir/gzclose.c.obj
[  2%] Building C object zlib/CMakeFiles/fltk_z.dir/gzlib.c.obj
[  2%] Building C object zlib/CMakeFiles/fltk_z.dir/gzread.c.obj
[  2%] Building C object zlib/CMakeFiles/fltk_z.dir/gzwrite.c.obj
[  3%] Building C object zlib/CMakeFiles/fltk_z.dir/inflate.c.obj
[  3%] Building C object zlib/CMakeFiles/fltk_z.dir/infback.c.obj
[  3%] Building C object zlib/CMakeFiles/fltk_z.dir/inftrees.c.obj
[  4%] Building C object zlib/CMakeFiles/fltk_z.dir/inffast.c.obj
[  4%] Building C object zlib/CMakeFiles/fltk_z.dir/trees.c.obj
[  4%] Building C object zlib/CMakeFiles/fltk_z.dir/uncompr.c.obj
[  5%] Building C object zlib/CMakeFiles/fltk_z.dir/zutil.c.obj
[  5%] Linking C static library ../lib/libfltk_z.a
[  5%] Built target fltk_z
[  5%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jmemnobs.c.obj
[  6%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jaricom.c.obj
[  6%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jcomapi.c.obj
[  6%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jutils.c.obj
[  7%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jerror.c.obj
[  7%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jmemmgr.c.obj
[  7%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jcapimin.c.obj
[  8%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jcapistd.c.obj
[  8%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jcarith.c.obj
[  8%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jctrans.c.obj
[  9%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jcparam.c.obj
[  9%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jdatadst.c.obj
[  9%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jcinit.c.obj
[ 10%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jcmaster.c.obj
[ 10%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jcmarker.c.obj
[ 10%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jcmainct.c.obj
[ 11%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jcprepct.c.obj
[ 11%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jccoefct.c.obj
[ 11%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jccolor.c.obj
[ 12%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jcsample.c.obj
[ 12%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jchuff.c.obj
[ 12%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jcdctmgr.c.obj
[ 13%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jfdctfst.c.obj
[ 13%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jfdctflt.c.obj
[ 13%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jfdctint.c.obj
[ 14%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jdapimin.c.obj
[ 14%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jdapistd.c.obj
[ 14%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jdarith.c.obj
[ 15%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jdtrans.c.obj
[ 15%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jdatasrc.c.obj
[ 15%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jdmaster.c.obj
[ 16%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jdinput.c.obj
[ 16%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jdmarker.c.obj
[ 16%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jdhuff.c.obj
[ 17%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jdmainct.c.obj
[ 17%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jdcoefct.c.obj
[ 17%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jdpostct.c.obj
[ 18%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jddctmgr.c.obj
[ 18%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jidctfst.c.obj
[ 18%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jidctflt.c.obj
[ 19%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jidctint.c.obj
[ 19%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jdsample.c.obj
[ 19%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jdcolor.c.obj
[ 20%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jquant1.c.obj
[ 20%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jquant2.c.obj
[ 20%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jdmerge.c.obj
[ 21%] Linking C static library ../lib/libfltk_jpeg.a
[ 21%] Built target fltk_jpeg
[ 21%] Building C object png/CMakeFiles/fltk_png.dir/png.c.obj
In file included from C:/msys64/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/png/png.c:14:
C:/msys64/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/png/pngpriv.h:920:4: error: #error ZLIB_VERNUM != PNG_ZLIB_VERNUM "-I (include path) error: see the notes in pngpriv.h"
  920 | #  error ZLIB_VERNUM != PNG_ZLIB_VERNUM \
      |    ^~~~~
make[2]: *** [png/CMakeFiles/fltk_png.dir/build.make:77: png/CMakeFiles/fltk_png.dir/png.c.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:253: png/CMakeFiles/fltk_png.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

[Mark Olesen]

attached is the tool chain file used

   mkdir build &&  cd build && git clone https://github.com/fltk/fltk.git
    mkdir fltk/build && cd fltk/build
    cmake \
        -G "Unix Makefiles" \
        -D CMAKE_TOOLCHAIN_FILE=../../toolchain.cmake \
        -D CMAKE_BUILD_TYPE=Release \
        -D OPTION_USE_GL=OFF \
        -D FLTK_BUILD_TEST=OFF \
        -D FLTK_BUILD_EXAMPLES=OFF \
        ..

[Ian MacArthur]

OK, I don't; see that in my builds so... comments below...

On Friday, 1 April 2022 at 04:14:54 UTC+1 mark wrote:

attached is the tool chain file used

   mkdir build &&  cd build && git clone https://github.com/fltk/fltk.git
    mkdir fltk/build && cd fltk/build
    cmake \
        -G "Unix Makefiles" \

FWIW, in my Msys builds I usually use "MSYS Makefiles" rather than "Unix Makefiles" though I'm not sure it makes much difference. AFAIK both *should* work for this case.

 

        -D CMAKE_TOOLCHAIN_FILE=../../toolchain.cmake \

        -D CMAKE_BUILD_TYPE=Release \
        -D OPTION_USE_GL=OFF \

Just curious - why turn of GL support? It's effectively "free" and works well, and does not bulk out the binary of you do not use it,  so...?

        -D FLTK_BUILD_TEST=OFF \
        -D FLTK_BUILD_EXAMPLES=OFF \
        ..

Running under Windows 10 msys64

using builtin zlib, jpeg, png

If you want to explicitly use the built-ins, it might be a good idea to set  OPTION_USE_SYSTEM_LIBJPEG=OFF,  OPTION_USE_SYSTEM_LIBPNG=OFF,  OPTION_USE_SYSTEM_ZLIB=OFF  to dissuade the cmake scan from even looking for zlib et al - this because at least one of my msys toolchains (I have 4 - and a bodged up half, actually! - on this PC, for example) has an rather old and suspect zlib DLL and static lib in its libs folder, which occasionally pollutes things I am trying to build!

The symptoms look different, but it may well be related.

getting build error on png

Seems like something with the include path? I tried to add include_target_directories to  on avail

ZLIB_VERNUM in zlib does match PNG_ZLIB_VERSION in png

OK - well if it is not a duff system zlib being accidentally pulled into your build (see OPTION_USE_SYSTEM_ZLIB=OFF above) then I have to suspect there's something hooky in your toolchain file.

What does a cmake run with no toolchain file passed do?

I typically run:

cmake -DCMAKE_BUILD_TYPE=RELEASE -DCMAKE_CXX_FLAGS="-O3" -DCMAKE_C_FLAGS="-O3" -DCMAKE_EXE_LINKER_FLAGS=" -static-libgcc -static-libstdc++ " -DFLTK_BUILD_EXAMPLES=ON -DOPTION_USE_SYSTEM_ZLIB=OFF -DOPTION_USE_SYSTEM_LIBPNG=OFF -DOPTION_USE_SYSTEM_LIBJPEG=OFF -G "MSYS Makefiles" ..

And that pretty much Just Works, every time.

The only "outlier" in this, AFAIK, is the  -DCMAKE_EXE_LINKER_FLAGS=" -static-libgcc -static-libstdc++ " option, which *some* mingw toolchains (but not all) now need to persuade gcc to build static application binaries that can run fully free of the mingw environment. For example, AFAIK, the mingw and mingw64 toolchains *do* need this, the TDM one is built slightly differently and so does not need this addition. YMMV.

[Albrecht Schlosser]

On 4/1/22 05:14 Mark Olesen wrote:

attached is the tool chain file used

   mkdir build &&  cd build && git clone https://github.com/fltk/fltk.git
    mkdir fltk/build && cd fltk/build
    cmake \
        -G "Unix Makefiles" \
        -D CMAKE_TOOLCHAIN_FILE=../../toolchain.cmake \
        -D CMAKE_BUILD_TYPE=Release \
        -D OPTION_USE_GL=OFF \
        -D FLTK_BUILD_TEST=OFF \
        -D FLTK_BUILD_EXAMPLES=OFF \
        ..

I can't reproduce your issue. Your log (below) shows that your build should be using the bundled libs (as expected) and should NOT have this conflict.

Unfortunately the lines posted above are not the toolchain file but they are helpful nevertheless. This points out that you *ARE* using a toolchain file (../../toolchain.cmake) and we need this toolchain file as well to see what your commands are doing.

OTOH under MinGW/MSYS2/Mingw64 you would normally not need a toolchain file, and as Ian suggested, I recommend to use "MinGW Makefiles" rather than "Unix Makefiles" as the CMake generator under MSYS2/mingw-w64 if this is what you're using to build, but see below for a caveat.

Hence I suggest to change your CMake commands to:

    cmake \
        -G "MinGW Makefiles" \

        -D CMAKE_BUILD_TYPE=Release \
        -D OPTION_USE_GL=OFF \
        -D FLTK_BUILD_TEST=OFF \
        -D FLTK_BUILD_EXAMPLES=OFF \
        ..

Caveat: If you do this you may not be able to build with 'make' which (depending on your MSYS(2) installation) requires "Unix Makefiles". You would need to use 'mingw32-make' instead to build or you can leave this up to CMake and use its generic

  cmake --build <build-dir>

command which will select the correct 'make' tool for you.

The reason why I suggest to switch to "MinGW Makefiles" is because I found this much easier to get working under MSYS2. This build environment is pretty complicated to set up and use because it allows to build "Cygwin like" tools with their own 'make' command.

At least you should try this and report if it changes anything.

If this doesn't help and/or if you have reasons to use a toolchain file then please tell us why you need it and post it here.


Final note: if you still get build errors, please try the following:

(1) run '[mingw32-]make' (w/o -j option or with -j 1) until it chokes
(2) then run 'make VERBOSE=ON' so the build will output the build commandline

Please post the last part of the build log from (2) that shows the entire commandline of the last build command that issues the error message.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/cb130dc7-411e-42ff-843a-15b7561929b5n%40googlegroups.com.

[Mark Olesen]

cmake -DCMAKE_BUILD_TYPE=RELEASE -DCMAKE_CXX_FLAGS="-O3" -DCMAKE_C_FLAGS="-O3" -DCMAKE_EXE_LINKER_FLAGS=" -static-libgcc -static-libstdc++ " -DFLTK_BUILD_EXAMPLES=ON -DOPTION_USE_SYSTEM_ZLIB=OFF -DOPTION_USE_SYSTEM_LIBPNG=OFF -DOPTION_USE_SYSTEM_LIBJPEG=OFF ..

good news, no ping error

bad news, following

[ 52%] Building CXX object fluid/CMakeFiles/fluid.dir/ExternalCodeEditor_UNIX.cxx.obj
cd "/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/build/fluid" && /mingw64/bin/CC.exe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I"/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/build" -I"/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk" -I"/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/zlib" -I"/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/jpeg" -I"/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/png" -O3 -O3 -DNDEBUG   -D_THREAD_SAFE -D_REENTRANT -MD -MT fluid/CMakeFiles/fluid.dir/ExternalCodeEditor_UNIX.cxx.obj -MF CMakeFiles/fluid.dir/ExternalCodeEditor_UNIX.cxx.obj.d -o CMakeFiles/fluid.dir/ExternalCodeEditor_UNIX.cxx.obj -c "/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/fluid/ExternalCodeEditor_UNIX.cxx"
C:/msys64/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/fluid/ExternalCodeEditor_UNIX.cxx:18:10: fatal error: sys/wait.h: No such file or directory
   18 | #include <sys/wait.h>   /* waitpid().. */
      |          ^~~~~~~~~~~~
compilation terminated.
make[2]: *** [fluid/CMakeFiles/fluid.dir/build.make:412: fluid/CMakeFiles/fluid.dir/ExternalCodeEditor_UNIX.cxx.obj] Error 1
make[2]: Leaving directory '/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/build'
make[1]: *** [CMakeFiles/Makefile2:638: fluid/CMakeFiles/fluid.dir/all] Error 2
make[1]: Leaving directory '/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/build'

make: *** [Makefile:136: all] Error 2

not sure why it is picking up as UNIX?

[Mark Olesen]

set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_HOST_WIN32 True)
set(CMAKE_CROSS_COMPILING True)
set(CMAKE_SYSTEM_PROCESSOR  "x86_64")
set(CMAKE_SHARED_LIBS OFF)
set(CMAKE_EXE_LINKER_FLAGS "-mwindows -static -static-libgcc -static-libstdc++")
set(CMAKE_FIND_ROOT_PATH /usr/bin)
set(CMAKE_C_COMPILER x86_64-w64-mingw32-gcc)
set(CMAKE_CXX_COMPILER x86_64-w64-mingw32-g++)
set(CMAKE_RC_COMPILER  x86_64-w64-mingw32-windres)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
link_directories(BEFORE /mingw64/lib)
include_directories(/mingw64/include/)

Generators

The following generators are available on this platform (* marks default):
* Unix Makefiles               = Generates standard UNIX makefiles.
  Ninja                        = Generates build.ninja files.
  Ninja Multi-Config           = Generates build-<Config>.ninja files.
  CodeBlocks - Ninja           = Generates CodeBlocks project files.
  CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
  CodeLite - Ninja             = Generates CodeLite project files.
  CodeLite - Unix Makefiles    = Generates CodeLite project files.
  Eclipse CDT4 - Ninja         = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.
  Kate - Ninja                 = Generates Kate project files.
  Kate - Unix Makefiles        = Generates Kate project files.
  Sublime Text 2 - Ninja       = Generates Sublime Text 2 project files.
  Sublime Text 2 - Unix Makefiles
                               = Generates Sublime Text 2 project files.

[Ian MacArthur]

Days notwithstanding... 

On 1 Apr 2022, at 23:31, Mark Olesen wrote:

cmake -DCMAKE_BUILD_TYPE=RELEASE -DCMAKE_CXX_FLAGS="-O3" -DCMAKE_C_FLAGS="-O3" -DCMAKE_EXE_LINKER_FLAGS=" -static-libgcc -static-libstdc++ " -DFLTK_BUILD_EXAMPLES=ON -DOPTION_USE_SYSTEM_ZLIB=OFF -DOPTION_USE_SYSTEM_LIBPNG=OFF -DOPTION_USE_SYSTEM_LIBJPEG=OFF ..

good news, no ping error

bad news, following

[ 52%] Building CXX object fluid/CMakeFiles/fluid.dir/ExternalCodeEditor_UNIX.cxx.obj
cd "/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/build/fluid" && /mingw64/bin/CC.exe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I"/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/build" -I"/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk" -I"/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/zlib" -I"/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/jpeg" -I"/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/png" -O3 -O3 -DNDEBUG   -D_THREAD_SAFE -D_REENTRANT -MD -MT fluid/CMakeFiles/fluid.dir/ExternalCodeEditor_UNIX.cxx.obj -MF CMakeFiles/fluid.dir/ExternalCodeEditor_UNIX.cxx.obj.d -o CMakeFiles/fluid.dir/ExternalCodeEditor_UNIX.cxx.obj -c "/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/fluid/ExternalCodeEditor_UNIX.cxx"
C:/msys64/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/fluid/ExternalCodeEditor_UNIX.cxx:18:10: fatal error: sys/wait.h: No such file or directory
   18 | #include <sys/wait.h>   /* waitpid().. */
      |          ^~~~~~~~~~~~
compilation terminated.
make[2]: *** [fluid/CMakeFiles/fluid.dir/build.make:412: fluid/CMakeFiles/fluid.dir/ExternalCodeEditor_UNIX.cxx.obj] Error 1
make[2]: Leaving directory '/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/build'
make[1]: *** [CMakeFiles/Makefile2:638: fluid/CMakeFiles/fluid.dir/all] Error 2
make[1]: Leaving directory '/home/Mark J Olesen/devel/kasoverb/kasoverb/build/fltk/build'
make: *** [Makefile:136: all] Error 2

not sure why it is picking up as UNIX?

No idea - this works for me, with a variety of mingw/Msys toolchains from the various forks, so...

Which mingw/Msts toolchain are you using?

What platform are you running on - is this some weird cross-compilation related issue, for example? (Though cross-compilation should work, and I think Albrecht uses it often.) 

Are you actually on a Windows host?

[Ian MacArthur]

On 1 Apr 2022, at 23:36, Mark Olesen wrote:
> Generators
>
> The following generators are available on this platform (* marks default):
> * Unix Makefiles = Generates standard UNIX makefiles.
> Ninja = Generates build.ninja files.
> Ninja Multi-Config = Generates build-<Config>.ninja files.
> CodeBlocks - Ninja = Generates CodeBlocks project files.
> CodeBlocks - Unix Makefiles = Generates CodeBlocks project files.
> CodeLite - Ninja = Generates CodeLite project files.
> CodeLite - Unix Makefiles = Generates CodeLite project files.
> Eclipse CDT4 - Ninja = Generates Eclipse CDT 4.0 project files.
> Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.
> Kate - Ninja = Generates Kate project files.
> Kate - Unix Makefiles = Generates Kate project files.
> Sublime Text 2 - Ninja = Generates Sublime Text 2 project files.
> Sublime Text 2 - Unix Makefiles
> = Generates Sublime Text 2 project files.
>

Huh - that’s not the list I get: where is “MSYS Makefiles” in this list? I have that in my cmake, and it’s what I usually use...

[Albrecht Schlosser]

I'm not sure why you would want to cross-compile if you are on a Windows host.

I believe you didn't install the required "mingw-w64" support files and therefore your build host is only configured to build "MSYS" executables. This would explain why you have the "Unix Makefiles" generator and neither the "MSYS Makefiles" nor the "MinGW Makefiles" generators.

Please answer Ian's questions what kind of installation you have, otherwise we can't help you further.

Assuming your MinGW installation is from msys2 ( https://www.msys2.org/ ) I suggest to follow the instructions on this website, particularly:



7. Now MSYS2 is ready for you. You will probably want to install some tools and the mingw-w64 GCC to start compiling:

  $ pacman -S --needed base-devel mingw-w64-x86_64-toolchain

This and the rest of the instructions on this page should hopefully provide you with a usable system to build FLTK and then native Windows applications.

[Mark Olesen]

No idea - this works for me, with a variety of mingw/Msys toolchains from the various forks, so...

> I think I will remove msys2 and reinstall. Something in the environment is probably hosed.

Which mingw/Msts toolchain are you using?

> msys2 mingw64 shell and tools

What platform are you running on - is this some weird cross-compilation related issue, for example? (Though cross-compilation should work, and I think Albrecht uses it often.)

> I initially started on Linux cross compiling, which also failed. So, I switched to Windows 10

 

Are you actually on a Windows host?

> Yes

[imm]

On Sun, 3 Apr 2022, 01:40 Mark Olesen wrote:

No idea - this works for me, with a variety of mingw/Msys toolchains from the various forks, so...

> I think I will remove msys2 and reinstall. Something in the environment is probably hosed.

Hmm, possibly.

Are you certain you installed all the necessary parts?

I haven't installed from "bare metal" in a while, but I have a vague recollection with the Msys2/mingw64 install of getting caught out by not installing the Win32 API headers... or something like that, anyway.

I think it wasn't immediately obvious what I should have installed, though it was a while ago.

That might account for why cmake thought you were on a Unix host though. 
--
Ian
From my Fairphone FP3
 

[Albrecht Schlosser]

On 4/3/22 13:02 imm wrote:

I haven't installed from "bare metal" in a while, but I have a vague recollection with the Msys2/mingw64 install of getting caught out by not installing the Win32 API headers... or something like that, anyway.

I think it wasn't immediately obvious what I should have installed, though it was a while ago.

Yes, it was AFAICT a big mess and you had to install many individual packages to get it up. This was even (and is still somewhat) more complicated since the MSYS toolchains can be used to compile for three different target environments ((a) the MSYS tools, (b) MinGW with Unix environment, like Cygwin, and (c) "native" Windows). The latter (c) can be done for 32-bit and 64-bit. This made it really hard to install "the right thing" to be able to build FLTK and one's own native Windows programs.

Current instructions on the msys2.org site make this *much* easier (see my recent post). I think the key is this:

  $ pacman -S --needed base-devel mingw-w64-x86_64-toolchain

but I would have to test this myself in a new install to be sure and this is not something I'm going to do soon.

That might account for why cmake thought you were on a Unix host though.

I'm pretty sure that's it. The "MSYS target" has Unix (Cygwin) support and that's all the OP seemed to have according to his CMake generator list.

[Albrecht Schlosser]

On 4/3/22 02:40 Mark Olesen wrote:

Which mingw/Msts toolchain are you using?

> msys2 mingw64 shell and tools

What platform are you running on - is this some weird cross-compilation related issue, for example? (Though cross-compilation should work, and I think Albrecht uses it often.)

> I initially started on Linux cross compiling, which also failed. So, I switched to Windows 10

Yes, as Ian said, I am regularly and successfully cross-compiling on Linux for a Windows target and I can execute the FLTK Windows executables (a) on Linux with `wine` and I can copy them to a Windows host and they are working fine (which is why they are cross-compiled on Linux in the first place).

I believe you need to install only package "mingw-w64" on Debian derived systems (Ubuntu etc.):

$ apt list --installed | grep mingw

binutils-mingw-w64-i686/focal,now 2.34-5ubuntu1+8.8 amd64 [installed,automatic]
binutils-mingw-w64-x86-64/focal,now 2.34-5ubuntu1+8.8 amd64 [installed,automatic]
g++-mingw-w64-i686/focal,now 9.3.0-7ubuntu1+22~exp1ubuntu4 amd64 [installed,automatic]
g++-mingw-w64-x86-64/focal,now 9.3.0-7ubuntu1+22~exp1ubuntu4 amd64 [installed,automatic]
g++-mingw-w64/focal,focal,now 9.3.0-7ubuntu1+22~exp1ubuntu4 all [installed,automatic]
gcc-mingw-w64-base/focal,now 9.3.0-7ubuntu1+22~exp1ubuntu4 amd64 [installed,automatic]
gcc-mingw-w64-i686/focal,now 9.3.0-7ubuntu1+22~exp1ubuntu4 amd64 [installed,automatic]
gcc-mingw-w64-x86-64/focal,now 9.3.0-7ubuntu1+22~exp1ubuntu4 amd64 [installed,automatic]
gcc-mingw-w64/focal,focal,now 9.3.0-7ubuntu1+22~exp1ubuntu4 all [installed,automatic]
mingw-w64-common/focal,focal,now 7.0.0-2 all [installed,automatic]
mingw-w64-i686-dev/focal,focal,now 7.0.0-2 all [installed,automatic]
mingw-w64-x86-64-dev/focal,focal,now 7.0.0-2 all [installed,automatic]
mingw-w64/focal,focal,now 7.0.0-2 all [installed]


Note that all but the last have the attribute "automatic".

My toolchain file:

# CMake Toolchain File for MinGW-w64 (64-bit) Cross Compilation

# the name of the target operating system
set(CMAKE_SYSTEM_NAME Windows)

# which tools to use
set(CMAKE_C_COMPILER   /usr/bin/x86_64-w64-mingw32-gcc)
set(CMAKE_CXX_COMPILER /usr/bin/x86_64-w64-mingw32-g++)
set(CMAKE_RC_COMPILER  /usr/bin/x86_64-w64-mingw32-windres)

# where the target environment is located
set(CMAKE_FIND_ROOT_PATH  /usr/x86_64-w64-mingw32)

# adjust the default behavior of the FIND_XXX() commands:

# search programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)

# search headers and libraries in the target environment
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

set(CMAKE_INSTALL_PREFIX ${CMAKE_FIND_ROOT_PATH}/usr CACHE FILEPATH
   "install path prefix")

# initialize required linker flags
set(CMAKE_EXE_LINKER_FLAGS_INIT "-static-libgcc -static-libstdc++")

# end of toolchain file

This is the same as you can find in README.CMake.txt except for a comment change. This is not surprising because I (re)wrote that part of the README file.

BTW, this builds 64-bit executables but if you change 'x86_64' to 'i686' you can make a toolchain file to build 32-bit Windows executables. I built both versions (on Linux) for demonstration:

$ file mingw-64/bin/fluid.exe mingw-32/bin/fluid.exe 
mingw-64/bin/fluid.exe: PE32+ executable (GUI) x86-64, for MS Windows
mingw-32/bin/fluid.exe: PE32 executable (GUI) Intel 80386, for MS Windows

[Mark Olesen]

Cross compiling on Fedora 35 Linux (under bhyve)   using your toolchain file I am having a problem linking executables because it is looking for pthread library. I tried searching to figure out the issue but was unable too. The good news is the libraries are compiling. However, executables are getting linker errors because of pthread.

This is a brand new install of Fedora 35 on a bhyve VM host FreeBSD 12.3.

Just so you know, everything compiles fine  and runs under OpenBSD 7.0 and FreeBSD 12.3

[ 91%] Linking CXX executable ../bin/fluid.exe

/usr/lib/gcc/x86_64-w64-mingw32/11.2.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lpthread
collect2: error: ld returned 1 exit status
make[2]: *** [fluid/CMakeFiles/fluid.dir/build.make:514: bin/fluid.exe] Error 1
make[1]: *** [CMakeFiles/Makefile2:437: fluid/CMakeFiles/fluid.dir/all] Error 2

make: *** [Makefile:136: all] Error 2

[Mark Olesen]

Yes, This is a minimal system. I actually just removed the msys directory and reinstalled from scratch going through the exact steps outlined. Same issues.

[Ian MacArthur]

On Monday, 4 April 2022 at 01:48:47 UTC+1Mark wrote:

Cross compiling on Fedora 35 Linux (under bhyve)   using your toolchain file I am having a problem linking executables because it is looking for pthread library. I tried searching to figure out the issue but was unable too. The good news is the libraries are compiling. However, executables are getting linker errors because of pthread.

Umm.... What target are you compiling for, with the mingw toolchain?

It (mingw64) can be set up to target either the "native" WIN32 target (which does not depend on pthreads, or at least it never has for me!) or the "cygwin" WIN32 target, which does emulate pthreads, but pulls in dependencies on the cygwin DLLs to make that work.

Over the years, I have had a world of pain with the cygwin portability layers (there are disparate - and more or less incompatible - DLLs of it floating around, many *nix tools ported to WinXX have used it and each imports it's own version of the DLL - that way lies madness...) 

As a result, I never go near cygwin if I can possibly avoid it and always aim to compile to "native" Win32, so pthreads should not be in play here.

So, you know, make sure you are *not* targeting cygwin is what I'd say.

Other than that, I have no idea why this doesn't work for you; I just ran a clean checkout and build with my mingw64 setup and it all went fine... There's still something odd going on with your setup, but I confess I have no clue what that is.

 

This is a brand new install of Fedora 35 on a bhyve VM host FreeBSD 12.3.

As an aside: The idea of cross-compiling for WIN32 on a Linux VM running on a BSD host is twisting my head. That is what you said you are doing???

Just so you know, everything compiles fine  and runs under OpenBSD 7.0 and FreeBSD 12.3

Which is nice - those are two targets I actually do not have, so it's reassuring to know they work...

 

[ 91%] Linking CXX executable ../bin/fluid.exe

/usr/lib/gcc/x86_64-w64-mingw32/11.2.1/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lpthread
collect2: error: ld returned 1 exit status

We might need to see some of the configure status, or some indication of why it thinks it needs pthreads here, as that's not right...

 

[Albrecht Schlosser]

On 4/4/22 02:58 Mark Olesen wrote:
> Yes, This is a minimal system. I actually just removed the msys
> directory and reinstalled from scratch going through the exact steps
> outlined. Same issues.

Mark, your statement above is a little terse about which "exact steps".

So if this means that you did what was described on the msys2 page, how
did you setup your FLTK build? Do you now have the "MinGW Makefiles"
generator available? If yes, did you use it?

That said, as the way of least resistance, I suggest to use the "MinGW
Makefiles" generator w/o toolchain file (!) and with all default
settings and then execute `cmake --build' which should execute the
correct `make' and hopefully build FLTK successfully. Setting other
options could be done if this succeeds.

$ mkdir build
$ cd build
$ cmake -G "MinGW Makefiles"
$ cmake --build .

That *should* do it.

[Albrecht Schlosser]

> $ cmake -G "MinGW Makefiles" # see below, add '..'

> $ cmake --build .
>
> That *should* do it.

Note: untested. Minor correction (missing '..'): use

$ cmake -G "MinGW Makefiles" ..

[Mark Olesen]

I removed Win32 CMake and cmake and then reinstalled using

https://www.msys2.org/docs/cmake/

make sure to install the MinGW version of CMake, i.e. installing e.g. mingw-w64-x86_64-cmake

issue resolved --- had wrong cmake version installed

That explains why I never had the MinGW generator listed

Thanks for the patience and feedback. Very appreciated. Doesn't go unnoticed.