Compiling under mingw - error with zlib.h

[pvr...@btinternet.com]

I am trying to compile the latest from scratch under MSYS/MINGW64.

The mingw64 installation has system zlib. The compile fails as this has ZLIB_VERNUM = 0x12d0 wheras FLTK PNG requires 0x12b0.

I have tried to run Cmake with OPTION_USE_SYSTEM_OFF=OFF and it still fails.

I have moved the MINGSW zlib.h out of the way and it fails not being able to find zlib.h as if the include library is still looking in the mingw64 directory rather than in the fltk files.

In my MINGW window I gave run

git clone https://github.com/fltk/fltk.git

mkdir -p build/Debug

cd build/Debug

cmake -G "Unix Makefiles" -D 'CMAKE_BUILD_TYPE=Debug' -DCMAKE_SYSTEM_NAME="Windows" -DOPTION_USE_SYSTEM_ZLIB=OFF -DOPTION_USE_SYSTEM_LIBJPEG=OFF -DOPTION_USE_SYSTEM_LIBPNG=OFF ../..

make

and it fails in make. After compiling fltk_zlib and fltk_jpeg it fails on the first png file. I found the order of the defines to be sigificant - setting zLIB after the other two was ignored and the mingsw zlib found instead.

The fail (using make -d) was:-

[ 11%] Building C object png/CMakeFiles/fltk_png.dir/png.c.obj
Reaping winning child 0x800088250 PID 4159
Live child 0x800088250 (png/CMakeFiles/fltk_png.dir/png.c.obj) PID 4160
In file included from C:/users/pvros/dev/fltk/png/png.c:14:
C:/users/pvros/dev/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 \
      |    ^~~~~
Reaping losing child 0x800088250 PID 4160
make[2]: *** [png/CMakeFiles/fltk_png.dir/build.make:77: png/CMakeFiles/fltk_png.dir/png.c.obj] Error 1

Thanks Phil

[imm]

Huh! I don't know.

I'm on my phone just now, but over the weekend I was actually fiddling around with PNG on mingw32 and mingw64.

Both seem to work OK. I did try using the "system" zlib under mingw64 and that worked OK.

However my normal config is to use the built-in and that's always just worked too...

--
Ian
From my Fairphone FP3

[Albrecht Schlosser]

On 11/15/22 17:01 'pvr...@btinternet.com' via fltk.general wrote:

I am trying to compile the latest from scratch under MSYS/MINGW64.

Isn't this "MSYS2" ? Just to be clear that this is (not) a typo.

The mingw64 installation has system zlib. The compile fails as this has ZLIB_VERNUM = 0x12d0 wheras FLTK PNG requires 0x12b0.

I have tried to run Cmake with OPTION_USE_SYSTEM_OFF=OFF and it still fails.

I have moved the MINGSW zlib.h out of the way and it fails not being able to find zlib.h as if the include library is still looking in the mingw64 directory rather than in the fltk files.

In my MINGW window I gave run

git clone https://github.com/fltk/fltk.git

mkdir -p build/Debug

cd build/Debug

cmake -G "Unix Makefiles" -D 'CMAKE_BUILD_TYPE=Debug' -DCMAKE_SYSTEM_NAME="Windows" -DOPTION_USE_SYSTEM_ZLIB=OFF -DOPTION_USE_SYSTEM_LIBJPEG=OFF -DOPTION_USE_SYSTEM_LIBPNG=OFF ../..

make

and it fails in make. After compiling fltk_zlib and fltk_jpeg it fails on the first png file.

This *should* work if your build system is set up correctly. I just tried the slightly modified commands (the first command is one long line):

/mingw64/bin/cmake -G "Unix Makefiles" -D 'CMAKE_BUILD_TYPE=Debug' -DCMAKE_SYSTEM_NAME="Windows" -DOPTION_USE_SYSTEM_ZLIB=OFF -DOPTION_USE_SYSTEM_LIBJPEG=OFF -DOPTION_USE_SYSTEM_LIBPNG=OFF ../..

make -j3

... and this worked fine for me.

If this doesn't work for you then you can try to use -G "MinGW Makefiles" instead. This needs "mingw32-make" instead of simple "make" to run the build. Can you please try this and report if it makes a difference?

I found the order of the defines to be sigificant - setting zLIB after the other two was ignored and the mingsw zlib found instead.

If you mean the CMake options then the order should NOT be significant. Please check your syntax again. I see several typos (like "OPTION_USE_SYSTEM_OFF=OFF" in your post, so maybe there was one in your commands as well ? (just guessing)

[pvrose]

On 15 November 2022, at 17:44, Albrecht Schlosser <Albrech...@online.de> wrote:

>
>
>On 11/15/22 17:01 'pvr...@btinternet.com' via fltk.general wrote:
>
>I am trying to compile the latest from scratch under MSYS/MINGW64.
>
>Isn't this "MSYS2" ? Just to be clear that this is (not) a typo.

A typo.

>
>The mingw64 installation has system zlib. The compile fails as this has ZLIB_VERNUM = 0x12d0 wheras FLTK PNG requires 0x12b0.
>
>I have tried to run Cmake with OPTION_USE_SYSTEM_OFF=OFF and it still fails.
>
>I have moved the MINGSW zlib.h out of the way and it fails not being able to find zlib.h as if the include library is still looking in the mingw64 directory rather than in the fltk files.
>
>In my MINGW window I gave run
>
>git clone https://github.com/fltk/fltk.git
>
>mkdir -p build/Debug
>
>cd build/Debug
>
>cmake -G "Unix Makefiles" -D 'CMAKE_BUILD_TYPE=Debug' -DCMAKE_SYSTEM_NAME="Windows" -DOPTION_USE_SYSTEM_ZLIB=OFF -DOPTION_USE_SYSTEM_LIBJPEG=OFF -DOPTION_USE_SYSTEM_LIBPNG=OFF ../..
>
>make
>
>and it fails in make. After compiling fltk_zlib and fltk_jpeg it fails on the first png file.
>
>This *should* work if your build system is set up correctly. I just tried the slightly modified commands (the first command is one long line):
>/mingw64/bin/cmake -G "Unix Makefiles" -D 'CMAKE_BUILD_TYPE=Debug' -DCMAKE_SYSTEM_NAME="Windows" -DOPTION_USE_SYSTEM_ZLIB=OFF -DOPTION_USE_SYSTEM_LIBJPEG=OFF -DOPTION_USE_SYSTEM_LIBPNG=OFF ../..
>make -j3
>... and this worked fine for me.

This has actually shown up I have a bigger problem. It can't find <FL/Fl.H>.

>If this doesn't work for you then you can try to use -G "MinGW Makefiles" instead. This needs "mingw32-make" instead of simple "make" to run the build. Can you please try this and report if it makes a difference?
>

No difference. Given the above problem, I'll reinstall msys2 tomorrow.

>I found the order of the defines to be sigificant - setting zLIB after the other two was ignored and the mingsw zlib found instead.
>
>If you mean the CMake options then the order should NOT be significant. Please check your syntax again. I see several typos (like "OPTION_USE_SYSTEM_OFF=OFF" in your post, so maybe there was one in your commands as well ? (just guessing)

I triple checked it at the time.
>
>--

Phil.
>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/7aa1dfba-e514-3d4f-8e43-3d192b6294e1%40online.de.

[pvrose]

On 15 November 2022, at 21:41, "'pvrose' via fltk.general" <fltkg...@googlegroups.com> wrote:

>
>
>On 15 November 2022, at 17:44, Albrecht Schlosser <Albrech...@online.de> wrote:
>
>>
>>
>>On 11/15/22 17:01 'pvr...@btinternet.com' via fltk.general wrote:
>>
>>I am trying to compile the latest from scratch under MSYS/MINGW64.
>>
>>Isn't this "MSYS2" ? Just to be clear that this is (not) a typo.
>
>A typo.
>>
>>The mingw64 installation has system zlib. The compile fails as this has ZLIB_VERNUM = 0x12d0 wheras FLTK PNG requires 0x12b0.
>>
>>I have tried to run Cmake with OPTION_USE_SYSTEM_OFF=OFF and it still fails.
>>
>>I have moved the MINGSW zlib.h out of the way and it fails not being able to find zlib.h as if the include library is still looking in the mingw64 directory rather than in the fltk files.
>>
>>In my MINGW window I gave run
>>
>>git clone https://github.com/fltk/fltk.git
>>
>>mkdir -p build/Debug
>>
>>cd build/Debug
>>
>>cmake -G "Unix Makefiles" -D 'CMAKE_BUILD_TYPE=Debug' -DCMAKE_SYSTEM_NAME="Windows" -DOPTION_USE_SYSTEM_ZLIB=OFF -DOPTION_USE_SYSTEM_LIBJPEG=OFF -DOPTION_USE_SYSTEM_LIBPNG=OFF ../..
>>
>>make
>>
>>and it fails in make. After compiling fltk_zlib and fltk_jpeg it fails on the first png file.
>>
>>This *should* work if your build system is set up correctly. I just tried the slightly modified commands (the first command is one long line):
>>/mingw64/bin/cmake -G "Unix Makefiles" -D 'CMAKE_BUILD_TYPE=Debug' -DCMAKE_SYSTEM_NAME="Windows" -DOPTION_USE_SYSTEM_ZLIB=OFF -DOPTION_USE_SYSTEM_LIBJPEG=OFF -DOPTION_USE_SYSTEM_LIBPNG=OFF ../..
>>make -j3
>>... and this worked fine for me.
>
>This has actually shown up I have a bigger problem. It can't find <FL/Fl.H>.
>>If this doesn't work for you then you can try to use -G "MinGW Makefiles" instead. This needs "mingw32-make" instead of simple "make" to run the build. Can you please try this and report if it makes a difference?
>>
>
>

Sorry it said "MinGW Makefiles" wasn't available.

>>I found the order of the defines to be sigificant - setting zLIB after the other two was ignored and the mingsw zlib found instead.
>>
>>If you mean the CMake options then the order should NOT be significant. Please check your syntax again. I see several typos (like "OPTION_USE_SYSTEM_OFF=OFF" in your post, so maybe there was one in your commands as well ? (just guessing)
>
>I triple checked it at the time.
>>
>>--
>
>Phil.
>>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/7aa1dfba-e514-3d4f-8e43-3d192b6294e1%40online.de.
>

>--

>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/usya8vlhleku611o4wle8dfn.1668548465836%40email.android.com.

[imm]

So, as "luck" would have it, I was spinning up fltk on a Win11 box for
some tests... So I used MSYS2/mingw64, here's some results and
notes...

On Tue, 15 Nov 2022 at 21:44, 'pvrose' via fltk.general wrote:
>
> I am trying to compile the latest from scratch under MSYS/MINGW64.

> >>If this doesn't work for you then you can try to use -G "MinGW Makefiles" instead. This needs "mingw32-make" instead of simple "make" to run the build. Can you please try this and report if it makes a difference?
> >
> Sorry it said "MinGW Makefiles" wasn't available.

Uh - that's unexpected... What list do you get if you do a "cmake -G"
with no option set? It *should* print a long list (well, about 60
lines on my set-up) of all the generators it knows about.

The "interesting" ones for Msys use are:

MSYS Makefiles = Generates MSYS makefiles.
MinGW Makefiles = Generates a make file for use with
Unix Makefiles = Generates standard UNIX makefiles.

All of which I have tried, at one time or another, and as best I can
tell they work "about the same" for my configurations.

This time around I opted for MSYS Makefiles; here's the foot of my
history buffer after the build, so all can see what was done:


git clone https://github.com/fltk/fltk.git fltk-1.4
cd fltk-1.4/
mkdir build-64
cmake -G
cd build-64/
cmake -G "MSYS Makefiles" -D 'CMAKE_BUILD_TYPE=Release'

-DCMAKE_SYSTEM_NAME="Windows" -DOPTION_USE_SYSTEM_ZLIB=OFF
-DOPTION_USE_SYSTEM_LIBJPEG=OFF -DOPTION_USE_SYSTEM_LIBPNG=OFF ..

make -j2

And that Just Worked.

As is traditional now, at the end of the build I remembered I had
forgotten (once again) to enable GLEW and the building of the
examples, so I fired up cmake-gui and turned on GLEW and the examples,
regenerated, and rebuilt. Still OK.

[pvr...@btinternet.com]

On Tuesday, November 15, 2022 at 4:01:15 PM UTC pvr...@btinternet.com wrote:

I am trying to compile the latest from scratch under MSYS/MINGW64.

It appears I had installed an incompatible version of cmake.

I have reinstalled MYSYS2 and using MINGW64 terminal:

  pacman -S mingw-w64-x86_64-gcc
 pacman -S mingw-w64-x86_64-cmake
 pacman -S mingw-w64-x86_64-gdb
 pacman -S git
 cd /c/users/pvros/
 cd dev
 git clone https://github.com/fltk/fltk.git
 cd fltk

 mkdir -p build/Debug
 cd build/Debug

 cmake -DCMAKE_BUILD_TYPE=Debug -DOPTION_USE_SYSTEM_ZLIB=OFF ../..
 ninja

Now gets me a bit further.

cmake -G offered me many more targets, but when I tried "MinGW Makefiles" got:

$ cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Debug ../..
CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CME_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
See also "C:/Users/pvros/dev/fltk/build/Debug/CMakeFiles/CMakeOutput.log".

So I went with the default: Ninja

I now fail at:

$ ninja
[556/582] Generating fast_slow.cxx, fast_slow.h
FAILED: test/fast_slow.cxx test/fast_slow.h C:/Users/pvros/dev/fltk/build/Debug/test/fast_slow.cxx C:/Users/pvros/dev/fltk/build/Debug/test/fast_slow.h
cmd.exe /C "cd /D C:\Users\pvros\dev\fltk\build\Debug\test && C:\Users\pvros\dev\fltk\build\Debug\bin\fluid-cmd.exe -c C:/Users/pvros/dev/fltk/test/fast_slow.fl"
[560/582] Linking CXX executable bin\test\radio.exe

Where it appears to have stopped.

I shall persevere. Phil.

[Albrecht Schlosser]

On 11/16/22 15:29 'pvr...@btinternet.com' via fltk.general wrote:

I have reinstalled MYSYS2 and using MINGW64 terminal:

  pacman -S mingw-w64-x86_64-gcc
 pacman -S mingw-w64-x86_64-cmake
 pacman -S mingw-w64-x86_64-gdb
 pacman -S git
 cd /c/users/pvros/
 cd dev
 git clone https://github.com/fltk/fltk.git
 cd fltk
 mkdir -p build/Debug
 cd build/Debug
 cmake -DCMAKE_BUILD_TYPE=Debug -DOPTION_USE_SYSTEM_ZLIB=OFF ../..
 ninja

Now gets me a bit further.

cmake -G offered me many more targets, but when I tried "MinGW Makefiles" got:

$ cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Debug ../..
CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CME_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
See also "C:/Users/pvros/dev/fltk/build/Debug/CMakeFiles/CMakeOutput.log".

You seem to miss `mingw32-make`. Please try this command (output from my system):

$ mingw32-make --version
GNU Make 4.3
Built for Windows32
...

If it issues "command not found" then that's probably the cause. I believe you can install it with:

$ pacman -S mingw64/mingw-w64-x86_64-make

which installs the 64-bit version of `mingw32-make`. Or maybe you need another package, I'm not sure. It's definitely one of the packages I have installed.

Hint: you can search for a particular tool/package name, e.g. 'make' with:

$ pacman -Ss make | grep x86_64

There are a lot of different packages with similar names (for different build scenarios) which makes it so hard to find the correct packages for your MSYS2 installation. :-(

So I went with the default: Ninja

I now fail at:

$ ninja
[556/582] Generating fast_slow.cxx, fast_slow.h
FAILED: test/fast_slow.cxx test/fast_slow.h C:/Users/pvros/dev/fltk/build/Debug/test/fast_slow.cxx C:/Users/pvros/dev/fltk/build/Debug/test/fast_slow.h
cmd.exe /C "cd /D C:\Users\pvros\dev\fltk\build\Debug\test && C:\Users\pvros\dev\fltk\build\Debug\bin\fluid-cmd.exe -c C:/Users/pvros/dev/fltk/test/fast_slow.fl"
[560/582] Linking CXX executable bin\test\radio.exe

Where it appears to have stopped.

FWIW, I just tried Ninja on my system:

$ /mingw64/bin/cmake -G Ninja ../.. -DOPTION_USE_SYSTEM_LIBJPEG:BOOL=OFF -D OPTION_USE_SYSTEM_LIBPNG:BOOL=OFF -D OPTION_USE_SYSTEM_ZLIB:BOOL=OFF -D CMAKE_EXE_LINKER_FLAGS="-static-libgcc -static-libstdc++"

... and it worked for me, building "native" Windows applications with one exception (see notes).

Notes:

1. "/mingw64/bin/cmake": I had to use the explicit path (I have both the MSYS2 and a Windows CMake installed and for an obscure reason pure `cmake` starts the Windows version).

2. All system image libs (jpeg, png, zlib) are disabled.

3. CMAKE_EXE_LINKER_FLAGS="-static-libgcc -static-libstdc++": make sure you don't need these DLL's

4. Remaining issue: unfortunately the build (still) depends on `libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll` as output by `ldd`

Point 4 is something I need to investigate because it makes the executables depend on this DLL. You can either run the programs from your MSYS shell or copy the DLL to the binary directory side by side with the executables if you want to run these programs under pure Windows.

I shall persevere. Phil.

Yes, I think you're on a good way. Maybe the only thing is to install the remaining package (see above).

[Ian MacArthur]

On Wednesday, 16 November 2022 at 14:29:28 UTC Phil wrote:

It appears I had installed an incompatible version of cmake.

I have reinstalled MYSYS2 and using MINGW64 terminal:

  pacman -S mingw-w64-x86_64-gcc
 pacman -S mingw-w64-x86_64-cmake
 pacman -S mingw-w64-x86_64-gdb
 pacman -S git

I can never remember what packages to install.

The MSYS2 stuff is confusing to me...

I can never remember what packages I need to add to Ubuntu either, for that matter!

 

 

cmake -G offered me many more targets, but when I tried "MinGW Makefiles" got:

$ cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Debug ../..
CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles".  CME_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
See also "C:/Users/pvros/dev/fltk/build/Debug/CMakeFiles/CMakeOutput.log".

So I went with the default: Ninja

TBH, I'd try "MSYS Makefiles" first, that Just Works for me in Msys2 builds...

 

I now fail at:

$ ninja
[556/582] Generating fast_slow.cxx, fast_slow.h
FAILED: test/fast_slow.cxx test/fast_slow.h C:/Users/pvros/dev/fltk/build/Debug/test/fast_slow.cxx C:/Users/pvros/dev/fltk/build/Debug/test/fast_slow.h
cmd.exe /C "cd /D C:\Users\pvros\dev\fltk\build\Debug\test && C:\Users\pvros\dev\fltk\build\Debug\bin\fluid-cmd.exe -c C:/Users/pvros/dev/fltk/test/fast_slow.fl"
[560/582] Linking CXX executable bin\test\radio.exe

Where it appears to have stopped.

No idea...

[Ian MacArthur]

On Wednesday, 16 November 2022 at 15:36:19 UTC Albrecht Schlosser wrote:

You seem to miss `mingw32-make`. Please try this command (output from my system):

$ mingw32-make --version
GNU Make 4.3
Built for Windows32
...

I've generally found "MSYS Makefiles" to be fine with MSYS2/mingw64, so worth trying that first...

 

3. CMAKE_EXE_LINKER_FLAGS="-static-libgcc -static-libstdc++": make sure you don't need these DLL's

My mingw64 builds DO NOT need these set.

My mingw32 builds DO need these set.

I have no idea what is "normal". Probably does no harm to have these settings enabled though?

 

4. Remaining issue: unfortunately the build (still) depends on `libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll` as output by `ldd`

Point 4 is something I need to investigate because it makes the executables depend on this DLL. You can either run the programs from your MSYS shell or copy the DLL to the binary directory side by side with the executables if you want to run these programs under pure Windows.

That's linked against winpthread rather than using Win32 native threads?

That's.... unexpected... and not what we would want.

Is it a mis-setting in the config? Or the wrong version of the mingw64 tools?

Weird...

[Philip Rose]

I’ve manage to compile and run the demo – thanks – further comments in-line.

 

Phil

 

Sent from Mail for Windows

 

From: Albrecht Schlosser
Sent: 16 November 2022 15:36
To: fltkg...@googlegroups.com
Subject: Re: [fltk.general] Re: Compiling under mingw - error with zlib.h

 

You seem to miss `mingw32-make`. Please try this command (output from my system):

$ mingw32-make --version

GNU Make 4.3

Built for Windows32

...

If it issues "command not found" then that's probably the cause. I believe you can install it with:

$ pacman -S mingw64/mingw-w64-x86_64-make

which installs the 64-bit version of `mingw32-make`. Or maybe you need another package, I'm not sure. It's definitely one of the packages I have installed.

 

<PVR> I missed an important step which was to update MSYS2 after installing it – run:

pacman -Suy

I managed to get ‘-G “MinGW Makefiles”’ to work, ‘-G “MSYS Makefiles”’ still doesn’t find the generator.

</PVR>

 

[Albrecht Schlosser]

On 11/16/22 16:52 Ian MacArthur wrote:

On Wednesday, 16 November 2022 at 15:36:19 UTC Albrecht Schlosser wrote:

You seem to miss `mingw32-make`. Please try this command (output from my system):

$ mingw32-make --version
GNU Make 4.3
Built for Windows32
...

I've generally found "MSYS Makefiles" to be fine with MSYS2/mingw64, so worth trying that first...

Yes, that's another option. But recently I found "MinGW Makefiles" to work more reliably (with MSYS2 on my installation) and I used that for a while. Now I tried one of the other generators (including Ninja) and it worked fine - surprisingly.

MSYS2 setup is still a mystery for me. But once you got it working ... never touch a running (ehm, working) system. ;-)

3. CMAKE_EXE_LINKER_FLAGS="-static-libgcc -static-libstdc++": make sure you don't need these DLL's

My mingw64 builds DO NOT need these set.

Does "mingw64" mean MSYS2/mingw64? If yes I'd be interested to know how to setup this so we can document it for other users.

My mingw32 builds DO need these set.

I assume this means classic "MinGW" where I made this experience as well.

I have no idea what is "normal".

Neither do I. Did I already say that it's a mystery? ;-)

Probably does no harm to have these settings enabled though?

Yes, I think so. It should be safe even if it's not needed. Unless you are working with a very old system that doesn't have these options.

 

4. Remaining issue: unfortunately the build (still) depends on `libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll` as output by `ldd`

Point 4 is something I need to investigate because it makes the executables depend on this DLL. You can either run the programs from your MSYS shell or copy the DLL to the binary directory side by side with the executables if you want to run these programs under pure Windows.

That's linked against winpthread rather than using Win32 native threads?

That's.... unexpected... and not what we would want.

Is it a mis-setting in the config? Or the wrong version of the mingw64 tools?

Weird...

That's exactly what I would like to know. I always get these dependencies when I use MSYS2/mingw64. Maybe I did something wrong when I installed it, maybe too many packages where one of those makes the build depend on that DLL? I dunno.

However, after a quick web search I found out how I can avoid the DLL dependency by adding "-static" to the build. Since I want to link statically anyway it doesn't matter and it doesn't seem to affect the output. The resulting programs work fine when I run them from an explorer window and I can't see any dependencies on non-Windows DLL's with `ldd`.

Whether this uses the "wrong" threading library/features I can't tell. I think we're still using Windows threading in FLTK and that should make it work correctly. Why the dependency is created in the first place when linking with MSYS2 on my system ... is still a mystery.

Anyway, here is what I found to work w/o dependencies on non-Windows (i.e. MSYS2) dll's:

$ cmake -G Ninja -D CMAKE_BUILD_TYPE=Debug \
  -D OPTION_USE_SYSTEM_LIBJPEG:BOOL=OFF -D OPTION_USE_SYSTEM_LIBPNG:BOOL=OFF \
  -D OPTION_USE_SYSTEM_ZLIB:BOOL=OFF \
  -D CMAKE_EXE_LINKER_FLAGS='-static-libgcc -static-libstdc++ -static' \
  ../..

Note the added "-static" flag to CMAKE_EXE_LINKER_FLAGS . That's all I needed to change.

As far as I can tell the build is not affected except for removing the unwanted dependency. However it would be another problem if you wanted to link with the shared FLTK libs (dll's) but that's off-topic for now.

[Albrecht Schlosser]

On 11/16/22 17:31 'Philip Rose' via fltk.general wrote:

I’ve manage to compile and run the demo – thanks – further comments in-line.

Great, thanks for the feedback.

 <PVR> I missed an important step which was to update MSYS2 after installing it – run:

pacman -Suy

Oh, yes, this is something one needs to remember (or look it up) every time one installs or updates the MSYS2/mingw64 installation.

I managed to get ‘-G “MinGW Makefiles”’ to work, ‘-G “MSYS Makefiles”’ still doesn’t find the generator.

I'd say this is OK. They work mostly the same but AFAICT "MSYS Makefiles" are *intended* to be used for building programs that are used for MSYS itself (or the MSYS DLL etc.) whereas "MinGW Makefiles" should be used for building "Windows executables". I'm not sure what flavor of build tools "Unix Makefiles" uses by default in an MSYS2 environment.

Thus, I'd say that it's OK if you have "MinGW Makefiles" working. Hint: you can always use `cmake --build` to execute the build command configured by CMake so you don't need to remember whether you need to run `make` or `mingw32-make` or whatever.

Further things to do:

The built executables should always run when started from the MSYS shell but may not work on a stock Windows system w/o MSYS2. If that's what you need, please look at my previous post regarding "CMAKE_EXE_LINKER_FLAGS" which should give you hints how to avoid MSYS2 dependencies *if needed*.

To find out whether you have non-Windows (MSYS2) dependencies use e.g. `ldd bin/test/hello.exe | grep -v Windows` or open a Windows explorer window and double-click on some .exe files. If it fails you'll get a message that one or more DLL's are missing. If it works you should be able to deploy such executables on other Windows systems w/o MSYS2 as well.

[Ian MacArthur]

On Wednesday, 16 November 2022 at 16:50:36 UTC Albrecht Schlosser wrote:

On 11/16/22 17:31 'Philip Rose' via fltk.general wrote:

I managed to get ‘-G “MinGW Makefiles”’ to work, ‘-G “MSYS Makefiles”’ still doesn’t find the generator.

OK - that's weird...

Is there a "make" in your default Msys2 path? (Not  mingw32-make or gmake, actually something that is just "make"...?)

 

I'd say this is OK. They work mostly the same but AFAICT "MSYS Makefiles" are *intended* to be used for building programs that are used for MSYS itself (or the MSYS DLL etc.) whereas "MinGW Makefiles" should be used for building "Windows executables". I'm not sure what flavor of build tools "Unix Makefiles" uses by default in an MSYS2 environment.

My "understanding" (I'm using that word loosely here...)  is that the 3 different generators "MSYS", "MinGW" and "Unix" all should work about the same for us here.

The difference is that the "MSYS" case creates Makefiles with a syntax that expects to be run from an Msys (or other sh-compatible) shell and uses "make" as the tool.

The "MinGW"  option uses  "mingw32-make" as the tool, and creates a syntax that should be compatible with cmd.exe as the shell.

The "Unix"  option  is like the MSYS case in that it uses "make" and "sh", so should be about the same as the "MSYS" option in this case.

I think! See also: https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html 

[Ian MacArthur]

On Wednesday, 16 November 2022 at 16:36:05 UTC Albrecht Schlosser wrote:

3. CMAKE_EXE_LINKER_FLAGS="-static-libgcc -static-libstdc++": make sure you don't need these DLL's

My mingw64 builds DO NOT need these set.

Does "mingw64" mean MSYS2/mingw64? If yes I'd be interested to know how to setup this so we can document it for other users.

My mingw32 builds DO need these set.

I assume this means classic "MinGW" where I made this experience as well.

 So... up until around the gcc-3 to gcc-4 transition in mingw32 (which must be getting on for 20 years ago now?) I never needed "-static-libgcc -static-libstdc++" at all.

With gcc-4 and later and mingw32, I do need to add "-static-libgcc -static-libstdc++".

But... at some point, I started doing more 64-bit Windows builds, initially using the TDM-gcc-5.1 compiler (which I often still use, FWIW, even though it is getting pretty old now!) and with that I have never needed to add the "-static-libgcc -static-libstdc++" options.

Later again, I started using Msys2 and their mingw64-gcc options. With that I find some set-ups need the "-static-libgcc -static-libstdc++" flags, others do not. I have *no clue* what I am doing different when setting up these installs... I assume it is some difference in my config but... This is, frankly, because I never pay any attention when setting these things up, and can never remember what packages are needed anyway, so they all end up with some weirdly different set as I randomly add packages until it works...