latest git msys64 compilation error

[Mark Olesen]

/home/markj/opensource/fltk_git/src/drivers/WinAPI/Fl_WinAPI_System_Driver.cxx:39:10: fatal error: direct.h: No such file or directory
   39 | #include <direct.h>
      |          ^~~~~~~~~~

I think you need a conditional code block such as

#if defined(__CYGWIN__)

#include <dirent.h>
#else

#include <direct.h>

#endif

[Mark Olesen]

err...lots of errors compiling the win32 system driver (use of underscore for ISO naming conventions e.g.  _putenv vs putenv

[Albrecht Schlosser]

On 1/10/20 9:47 AM Mark Olesen wrote:
> /home/markj/opensource/fltk_git/src/drivers/WinAPI/Fl_WinAPI_System_Driver.cxx:39:10:
> fatal error: direct.h: No such file or directory
>    39 | #include <direct.h>
>       |          ^~~~~~~~~~

Hmm, I'm surprised by this report for four reasons:

(1) Although I didn't build FLTK on a native Windows box with MinGW or
'msys64' for a while, I built FLTK just now with my cross-compiler
(/usr/bin/x86_64-w64-mingw32-g++) under Linux w/o any issues.

> I think you need a conditional code block such as
>
> #if defined(__CYGWIN__)
> #include <dirent.h>
> #else
> #include <direct.h>
> #endif

(2) I don't know how this could help with 'msys64' compilation. Does
your 'msys64' toolchain define __CYGWIN__?

Please tell us which toolchain you mean exactly with 'msys64' (and
please ignore my ignorance). Where did you download/install it from?

(3) The line of code you're mentioning, i.e. '#include <direct.h>' in
src/drivers/WinAPI/Fl_WinAPI_System_Driver.cxx (line 39) has not been
changed since Git commit 927774af85 (Apr 10, 2016).

Maybe something's broken in your 'msys64' install? When did you build
FLTK successfully for the last time with this toolchain? And which FLTK
version (download file version, Git commit, snapshot version or date,
please).

(4) See my reply to your next post.

I'm really puzzled...

[Albrecht Schlosser]

On 1/10/20 9:56 AM Mark Olesen wrote:
> err...lots of errors compiling the win32 system driver (use of
> underscore for ISO naming conventions e.g.  _putenv vs putenv

These warnings (not errors) are known to be issued by MS Visual Studio
compilers but not by any MinGW/MSYS(2) compilers.

Are you sure you see them with your 'msys64' toolchain? (see my previous
post as well)

FWIW, we try to replace these calls with similar 'fl_putenv' functions
to avoid these warnings in the first place, but I just found that
fl_putenv() doesn't exist yet (still on my todo list).

Can you tell us which functions except putenv are concerned?

[Ian MacArthur]

Hi Mark,

I see Albrecht’s already responded, but it might help us (it’d certainly help me!) if you could could clarify a bit of what you are doing, to get these errors...

FWIW, I built fltk-1.4 “fresh” from git this afternoon with mingw64 and all was well.

In the subject line, you say “msys64” - I’m not clear what that is. I know and use Msys and Msys2 with mingw[32|64] but msys64 is a new one on me.

If it is related to the mingw toolchains, then I’d not expect Cygwin to be a part of that.

Generally, the mingw tools build “native” WinXX applications, whereas the cygwin tools build WinnXX apps via a posix emulation layer.

I tend, these days, to use the “native” approach for my WinXX builds (I’ve had too many weird issues from the cygwin posix layer in the past, and in my tests it seems a bit slow...)

Anyway, my experience with the “native” tools - mingw and mingw64 - has been that they don’t seem to be too bothered about the _putenv vs putenv issue, both seem to be accepted.

I can’t recall if cygwin only accepts the putenv form though.

FWIW, even the MS cl compiler can often be persuaded to do the Right Thing by use of the “oldnames” settings...

Anyway, enough ramble from me: can you clarify what it is you are seeing / doing / etc.?

Cheers,

[Mark Olesen]

[Mark Olesen]

Following the README.CMake.txt instructions, I get the following error:

[ 18%] Building CXX object src/CMakeFiles/fltk.dir/Fl.cxx.obj
In file included from C:/msys64/home/markj/opensource/fltk_git/src/Fl.cxx:26:
/home/markj/opensource/fltk_git/FL/platform.H:53:14: fatal error: X11/Xlib.h: No such file or directory
   53 | #    include <X11/Xlib.h>

# uname -a
MINGW64_NT-10.0-17763 LAPTOP-RUD57MQL 3.0.7-338.x86_64 2019-07-11 10:58 UTC x86_64 Msys

$ g++ --version
g++ (GCC) 9.1.0

+ For the previous mentioned errors

- Yes, the msys compilers predefine macro __CYGWIN__

- msys should be installed and updated correctly

- I just used mkdir buld; cd build; cmake ..; make

[Mark Olesen]

Native CMake and Visual Studio compiles fine. However, installing I get errors:

PS C:\msys64\home\markj\opensource\fltk_git\build> msbuild .\INSTALL.vcxproj

PostBuildEvent:
  setlocal
  "C:\Program Files\CMake\bin\cmake.exe" -DBUILD_TYPE=Debug -P cmake_install.cmake
  if %errorlevel% neq 0 goto :cmEnd
  :cmEnd
  endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
  :cmErrorLevel
  exit /b %1
  :cmDone
  if %errorlevel% neq 0 goto :VCEnd
  :VCEnd
  -- Install configuration: "Debug"
  CMake Error at cmake_install.cmake:36 (file):
    file INSTALL cannot make directory "C:/Program Files
    (x86)/FLTK/include/FL": No such file or directory.


  -- Installing: C:/Program Files (x86)/FLTK/include/FL
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: The command "setlocal [C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: "C:\Program Files\CMake\bin\cmake.exe" -DBUILD_TYPE=Debug -P cmake_install.cmake [C:\msys64\home\ma
rkj\opensource\fltk_git\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd [C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: :cmEnd [C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone [C:\msys64\home\markj\opensource\fltk_git
\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: :cmErrorLevel [C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: exit /b %1 [C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: :cmDone [C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd [C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: :VCEnd" exited with code 1. [C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj]
Done Building Project "C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj" (default targets) -- FAILED.


Build FAILED.

"C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj" (default target) (1) ->
(PostBuildEvent target) ->
  C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(1
48,5): error MSB3073: The command "setlocal [C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: "C:\Program Files\CMake\bin\cmake.exe" -DBUILD_TYPE=Debug -P cmake_install.cmake [C:\msys64\home\ma
rkj\opensource\fltk_git\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd [C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: :cmEnd [C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone [C:\msys64\home\markj\opensource\fltk_git
\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: :cmErrorLevel [C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: exit /b %1 [C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: :cmDone [C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd [C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(148
,5): error MSB3073: :VCEnd" exited with code 1. [C:\msys64\home\markj\opensource\fltk_git\build\INSTALL.vcxproj]

    0 Warning(s)
    1 Error(s)

[Greg Ercolano]

On 2020-01-10 08:48, Ian MacArthur wrote:
> In the subject line, you say “msys64” - I’m not clear what that is.
> I know and use Msys and Msys2 with mingw[32|64] but msys64 is a new one on me.

AFAIK there's no such thing as an "msys compiler"; if you just install MSYS,
'gcc' and 'g++' give 'command not found'. And quoting the MSYS docs:

"A common misunderstanding is MSYS is "UNIX on Windows",
MSYS by itself does not contain a compiler or a C library [..]
Users looking for such functionality should look to Cygwin or
Microsoft's Interix instead."

We need to know from the OP which compiler environment he installed,
i.e. from which website/package installer.

I'm guessing some kind of package that bundled MSYS with a compiler
(or vice versa).

For instance, I just ran the 'mingw' GUI installer from http://www.mingw.org/wiki/Getting_Started
and it includes MSYS as an option.

The OP responded so far with:
___________________

# uname -a
MINGW64_NT-10.0-17763 LAPTOP-RUD57MQL 3.0.7-338.x86_64 2019-07-11 10:58 UTC x86_64 Msys

$ g++ --version
g++ (GCC) 9.1.0

___________________

This doesn't tell us what compiler this is though (mingw? cygwin? etc).
I think we can rule out MingGW; see below.

The 'uname -a' response just tells us the MSYS environment was built with
MINGW64, so the executables in the MSYS environment are 64bit.
Doesn't tell us about the compiler environment.

The 'g++ --version' response is telling; looks like it's NOT mingw, as
after my recent mingw install, the "g++ --version" response is:
____

$ g++ --version
g++.exe (MinGW.org GCC-8.2.0-5) 8.2.0 <--
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
____

Sounds like the OP has some other, newer compiler (9.x vs mingw 8.x)

Maybe cygwin? I tried using the cygwin installer (I never use cygwin),
but it tries to install everything on the planet including X windows,
X windows desktops, TCL.. there was so much to deselect, I didn't bother.

OP needs to respond with how his compiler environment was installed,
i.e. from which website/package installer.

[Mark Olesen]

Thanks for the reply. I rarely use Windows. Visual Studio compiles fine. I will also try later to cross-compile under Linux since it is mentioned as success (I think that is how I did it last time too?)

I will check into seeing if there are differences between gcc compilers installed on mingw being invoked as mingw- or gcc.

It's been a few years since I recompiled KasoVerb with fltk. I am in the process of refactoring it. So, it may take awhile before I get it to work on windows.

[Albrecht Schlosser]

On 1/18/20 4:04 AM Mark Olesen wrote:
> Thanks for the reply. I rarely use Windows. Visual Studio compiles fine.
> I will also try later to cross-compile under Linux since it is mentioned
> as success (I think that is how I did it last time too?)

Yep, did it, worked for me (with some minor tweaks): both autotools and
CMake builds work but need some additional settings (and/or edits). You
may need to ajdust your toolchain install location. I included the
static Windows libs needed for "native" Windows programs in both builds.


(1) autotools (configure/make):

$ make clean # create a default configure script
$ LDFLAGS='-static-libgcc -static-libstdc++' ./configure
--host=x86_64-w64-mingw32

Edit test/Makefile:

# FLUID file rules
.fl.cxx .fl.h: ../fluid/fluid$(EXEEXT)
echo Generating $@ and header from $<...
: ../fluid/fluid$(EXEEXT) -c $< [1]
: wine ../fluid/fluid$(EXEEXT) -c $< [2]
fluid -c $< [3]

Notes: use one of the alternatives [2, 3]. Remove the leading ':' from
the one you use.

[1] Original, doesn't work with cross compilation (needs to be fixed)

[2] works if you have `wine' installed and working

[3] needs a native (Linux) `fluid' in your PATH

Finally, run `make'. That's it.


(2) CMake needs a toolchain file (as documented in our README.CMake.txt
file). I believe this may not be complete (I'll check later), hence I'm
attaching my mingw-w64_toolchain.cmake file here.

Run these commands (example) in your FLTK root:

$ mkdir build
$ cd build
$ cmake -DCMAKE_TOOLCHAIN_FILE=/pat/to/mingw-w64_toolchain.cmake ..
$ make

This definitely needs a native (Linux) `fluid' in your PATH and it does
NOT build a cross (Windows) fluid.exe whereas the autotools does.

The latter is on my todo list - I believe we need to build fluid for the
target system with CMake as well.

> I will check into seeing if there are differences between gcc compilers
> installed on mingw being invoked as mingw- or gcc.

Yep, that's why we were asking for the exact installation of your
'msys64' or MinGW or whatever toolchain. There are so many variants and
we can't help further if we don't know which one you installed.

For instance: if you installed 'MSYS2' or 'Cygwin' then there are
usually more compilers/toolchains you can select from.

In MSYS2 (which I guess you installed) you can install (IIRC!) the MSYS
gcc compiler which is used to build the MSYS tools, and I guess this one
defines the macro __CYGWIN__ (which you told us your compiler does).

The other gcc compiler package may be called mingw32-gcc or something
like that. This is the one you want to install to build "native" Windows
apps w/o the MSYS/Cygwin dependencies. This compiler does not define
__CYGWIN__ (again, IIRC).

In Cygwin the default gcc compiler suite also defines __CYGWIN__ and is
used to build programs for the Cygwin environment. You need to install
the mingw32 compilers (32-bit and/or 64-bit) and use "cross compilation"
(as above under Linux) to build native Windows programs, otherwise your
build will depend on cygwin1.dll and likely on X11 libs (and a running X
server).

And there are even more variants...

[Mark Olesen]

Thanks for the tool chain file and explanation.

This is what I changed in your tool chain file :

# which tools to use
set(CMAKE_C_COMPILER   /usr/bin/x86_64-pc-msys-gcc.exe)
set(CMAKE_CXX_COMPILER /usr/bin/x86_64-pc-msys-g++.exe)
set(CMAKE_RANLIB       /usr/bin/x86_64-pc-msys-gcc-ranlib.exe)
set(CMAKE_RC_COMPILER  /usr/bin/windres)

The following defines WIN32, not _WIN32

set(CMAKE_SYSTEM_NAME Windows)

So,

<FL/platform.H>

bombs.

I had to add

add_compile_definitions(_WIN32)

In file included from /home/markj/opensource/fltk_git/src/Fl_lock.cxx:29:
/home/markj/opensource/fltk_git/src/drivers/WinAPI/Fl_WinAPI_System_Driver.H: In member function ‘virtual int Fl_WinAPI_System_Driver::putenv(char*)’:
/home/markj/opensource/fltk_git/src/drivers/WinAPI/Fl_WinAPI_System_Driver.H:49:41: error: ‘_putenv’ was not declared in this scope; did you mean ‘putenv’?
   49 |   virtual int putenv(char *var) {return _putenv(var);} // *FIXME* needs string conversion

[Albrecht Schlosser]

On 2/8/20 1:54 AM Mark Olesen wrote:
> Thanks for the tool chain file and explanation.

Welcome.

> This is what I changed in your tool chain file :
>
> # which tools to use
> set(CMAKE_C_COMPILER   /usr/bin/x86_64-pc-msys-gcc.exe)
> set(CMAKE_CXX_COMPILER /usr/bin/x86_64-pc-msys-g++.exe)
> set(CMAKE_RANLIB       /usr/bin/x86_64-pc-msys-gcc-ranlib.exe)
> set(CMAKE_RC_COMPILER  /usr/bin/windres)

This is *most* likely not the compiler/toolchain you want. The part
'-msys-' means (if I'm not totally wrong) that this toolchain builds
programs that are intended to be executed in the MSYS environment. That
would be system tools like ls, compilers, etc. and not programs to be
executed in a native Windows environment.

You still didn't tell us where you downloaded your installation from and
how you installed it. Are you now cross-compiling under Linux or is this
a Windows MSYS(2) installation? Please be explicit, otherwise we can't
help you.

> The following defines WIN32, not _WIN32
>
> set(CMAKE_SYSTEM_NAME Windows)

Honestly, I have no idea why this is so. Perhaps because it's the wrong
toolchain?

> I had to add
>
> add_compile_definitions(_WIN32)

That would cure the symptoms, not the real cause.

> In file included from /home/markj/opensource/fltk_git/src/Fl_lock.cxx:29:
> /home/markj/opensource/fltk_git/src/drivers/WinAPI/Fl_WinAPI_System_Driver.H:
> In member function ‘virtual int Fl_WinAPI_System_Driver::putenv(char*)’:
> /home/markj/opensource/fltk_git/src/drivers/WinAPI/Fl_WinAPI_System_Driver.H:49:41:
> error: ‘_putenv’ was not declared in this scope; did you mean ‘putenv’?
>    49 |   virtual int putenv(char *var) {return _putenv(var);} //
> *FIXME* needs string conversion

Yep, this is a point on my todo list, but we never got reports that
_putenv wouldn't be declared in a Windows environment. Neither did it
happen in my cross compilation.

I'm going to fix this _putenv issue because it needs UTF-8 to wide char
conversion as the comment "*FIXME* ..." says.

[Mark Olesen]

I am running msys from msys2.org

pacman -S mingw-w64-x86_64-toolchain

cmake -DCMAKE_TOOLCHAIN_FILE=../../w64_toolchain.cmake -DCMAKE_BUILD_TYPE=Release ..

SET(CMAKE_SYSTEM_NAME        Windows)
SET(CMAKE_SYSTEM_PROCESSOR   x64)
SET(CMAKE_SHARED_LIBS        OFF)

SET(CMAKE_SYSTEM_VERSION 1)
SET(CMAKE_C_COMPILER     "/mingw64/bin/x86_64-w64-mingw32-gcc")
SET(CMAKE_CXX_COMPILER   "/mingw64/bin/x86_64-w64-mingw32-g++")
SET(CMAKE_RC_COMPILER    "/mingw64/bin/windres")
SET(CMAKE_RANLIB         "/mingw64/bin/x86_64-w64-mingw32-gcc-ranlib")
SET(CMAKE_AR             "/mingw64/bin/x86_64-w64-mingw32-gcc-ar.exe")
SET(CMAKE_LINKER         "/mingw64/bin/ld.exe")
SET(CMAKE_C_LINK_EXECUTABLE ${CMAKE_LINKER})
SET(CMAKE_CXX_LINK_EXECUTABLE ${CMAKE_LINKER})


SET(CMAKE_EXE_LINKER_FLAGS "-static-libgcc -static-libstdc++")

# Configure the behaviour of the find commands
SET(CMAKE_FIND_ROOT_PATH "/usr/x86_64-w64-mingw32")
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_INSTALL_PREFIX ${CMAKE_FIND_ROOT_PATH}/usr CACHE FILEPATH
   "install path prefix")

Now, the problem is config.h is not found. It is being built, however

[ 17%] Building CXX object src/CMakeFiles/fltk.dir/Fl.cxx.obj
cd /home/markj/opensource/fltk_git/build/src && /mingw64/bin/x86_64-w64-mingw32-g++  -DFL_LIBRARY -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE @CMakeFiles/fltk.dir/includes_CXX.rsp -O3 -DNDEBUG   -o CMakeFiles/fltk.dir/Fl.cxx.obj -c /home/markj/opensource/fltk_git/src/Fl.cxx
In file included from C:/msys64/home/markj/opensource/fltk_git/src/Fl.cxx:23:
C:/msys64/home/markj/opensource/fltk_git/src/config_lib.h:12:10: fatal error: config.h: No such file or directory
   12 | #include "config.h"
      |          ^~~~~~~~~~

I have tried adding include_directories to no avail.

It appears I am getting close to cross compiling on Windows using msys.

Thanks.

[Mark Olesen]

Scouring the internet and mixing things together, I came up with

# Required by cmake if `uname -s` is inadaquate
set(CMAKE_SYSTEM_NAME               Windows)
set(CMAKE_SYSTEM_VERSION            1)

# Mingw architecture default is 64-bit
# To override:
#   $ export MINGW_ARCH=32
if(DEFINED ENV{MINGW_ARCH})
        set(MINGW_ARCH              "$ENV{MINGW_ARCH}")
else()
        set(MINGW_ARCH              "64")
endif()

if(${MINGW_ARCH} STREQUAL "32")
        set(CMAKE_SYSTEM_PROCESSOR  "i686")
elseif(${MINGW_ARCH} STREQUAL "64")
        set(CMAKE_SYSTEM_PROCESSOR  "x86_64")
else()
        message(FATAL_ERROR         "Unknown system architecture specified")
endif()

# Path to mingw
set(MINGW_PREFIX                    "/opt/mingw${MINGW_ARCH}")
# Linux mingw requires explicitly defined tools to prevent clash with native system tools
set(MINGW_TOOL_PREFIX               ${MINGW_PREFIX}/bin/${CMAKE_SYSTEM_PROCESSOR}-w64-mingw32-)

# Windows msys mingw ships with a mostly suitable preconfigured environment
if(DEFINED ENV{MSYSCON})
        set(CMAKE_GENERATOR         "MSYS Makefiles" CACHE STRING "" FORCE)
        set(MINGW_PREFIX            "/mingw${MINGW_ARCH}")
        set(MINGW_TOOL_PREFIX       "${MINGW_PREFIX}/bin/")

        # Msys compiler does not support @CMakeFiles/Include syntax
        set(CMAKE_C_USE_RESPONSE_FILE_FOR_INCLUDES   OFF)
        set(CMAKE_CXX_USE_RESPONSE_FILE_FOR_INCLUDES OFF)
endif()

SET(CMAKE_SHARED_LIBS        OFF)
SET(CMAKE_EXE_LINKER_FLAGS "-static -static-libgcc -static-libstdc++")

# The target environment
set(CMAKE_FIND_ROOT_PATH            ${MINGW_PREFIX})
set(CMAKE_INSTALL_PREFIX            ${MINGW_PREFIX})

# which compilers to use for C and C++
set(CMAKE_C_COMPILER                ${MINGW_TOOL_PREFIX}gcc)
set(CMAKE_CXX_COMPILER              ${MINGW_TOOL_PREFIX}g++)
set(CMAKE_RC_COMPILER               ${MINGW_TOOL_PREFIX}windres)

# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

Now, FLTK library compiles but the tests do not:

/mingw64/bin/g++ -O3 -DNDEBUG  -static -static-libgcc -static-libstdc++ -Wl,-subsystem,windows -mwindows -Wl,--whole-archive CMakeFiles/cube.dir/objects.a -Wl,--no-whole-archive  -o ../bin/examples/cube.exe -Wl,--out-implib,../bin/examples/libcube.dll.a -Wl,--major-image-version,0,--minor-image-version,0 ../lib/libfltk.a ../lib/libfltk_gl.a -lopengl32 -lglu32 ../lib/libfltk.a -lcomctl32 -lws2_32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
make[2]: Leaving directory '/home/markj/opensource/fltk_git/build'
[ 56%] Built target cube
make -f test/CMakeFiles/CubeView.dir/build.make test/CMakeFiles/CubeView.dir/depend
make[2]: Entering directory '/home/markj/opensource/fltk_git/build'
[ 56%] Generating CubeViewUI.cxx, CubeViewUI.h
cd /home/markj/opensource/fltk_git/build/test && FLUID_PATH-NOTFOUND -c /home/markj/opensource/fltk_git/test/CubeViewUI.fl
/bin/sh: FLUID_PATH-NOTFOUND: command not found
make[2]: *** [test/CMakeFiles/CubeView.dir/build.make:63: test/CubeViewUI.cxx] Error 127
make[2]: Leaving directory '/home/markj/opensource/fltk_git/build'
make[1]: *** [CMakeFiles/Makefile2:559: test/CMakeFiles/CubeView.dir/all] Error 2
make[1]: Leaving directory '/home/markj/opensource/fltk_git/build'
make: *** [Makefile:130: all] Error 2

[Mark Olesen]

For reference, I tweaked:

https://github.com/andrewrk/libsoundio/wiki/Compiling-for-Windows

[Mark Olesen]

As a side note, when building fltk library and my application on WIndows using Visual Studo or MinGW/MSYS2 both in "Release" mode, I get a console window.

[gga]

On 8/2/20 14:34, Mark Olesen wrote:

As a side note, when building fltk library and my application on WIndows using Visual Studo or MinGW/MSYS2 both in "Release" mode, I get a console window.

I'm not sure about MinGW, but for Visual Studio, you need to:

You want to change the target subsystem from Console to Windows. Go to Project Properties - Linker - System and change the SubSystem drop down to Windows (/SUBSYSTEM:WINDOWS). Doing this should get rid of the annoying console window.

-- 
Gonzalo Garramuño

[gga]

On 8/2/20 14:34, Mark Olesen wrote:

As a side note, when building fltk library and my application on WIndows using Visual Studo or MinGW/MSYS2 both in "Release" mode, I get a console window.

For MinGW, you need to pass to the linker:

-Wl,-subsystem,windows

or, alternatively:

-mwindows

-- 
Gonzalo Garramuño

[imm]

On Sat, 8 Feb 2020 at 06:29, Mark Olesen wrote:
>
> I am running msys from msys2.org
>
> pacman -S mingw-w64-x86_64-toolchain
>
> cmake -DCMAKE_TOOLCHAIN_FILE=../../w64_toolchain.cmake -DCMAKE_BUILD_TYPE=Release ..

Hi Mark et al,

This post is just for clarity, and in case others stumble across this
thread, as I'm assuming most will know this, but it is worth noting
that when you install Msys2 it actually installs, 3 distinct
"personalities".

These are mingw32, mingw64 and msys. Each with its own shell.

The mingw32 config is intended for building "native" Win32
executables, in 32-bit mode. Mingw64 is "the same" but for 64-bit
builds.
The msys personality isn't really for building on Windows as such - it
is a cygwin-like posix emulation that the msys2 folks use for tools
porting and so on. I think you *can* use it to build stuff, but the
msys2 folks themselves suggest that if you want the posix layer, you
are better off using cygwin...

FWIW, I tried to build fltk under the msys personality, and that did
not go well...

The mingw32 and mingw64 versions both built the fltk-1.4 repo for me
just fine, configuring with cmake in the usual way. The resulting
binaries run fine on stock Windows boxes.

TBH, I don't use the msys2 toolchain much myself (I find it to be a
faff to install all the bits...) but I have been using the msys2
mingw32 tools a bit recently because it provides a much more recent
gcc (9.0.2 IIRC) than what my usual mingw toolchain provides...

As regards the compiler, you pretty much need to install the specific
version for the personality you are wanting to use.
I have gcc installed 3 times, in effect, in my msys2 config. I have no
idea if this is normal, it certainly doesn't seem very "efficient" to
me!

So I used pacman from the msys2 shell to install gcc,
Then from the mingw32 shell I used pacman to install mingw-w64-i686-gcc.
Finally from the mingw64 shell I installed mingw-w64-x86_64-gcc.

See what I mean about it being a faff to set everything up right...
There are a mess of other packages that you need to install "per
personality" too, AFAIK, and I do not recall what they all are. It's
not something I really relish revisiting...

Anyway; once I got the per-personality toolchains all up up running,
since then it has pretty much Just Worked, and pacman seems to do a
good job of keeping it all up to date and everything. It all seems to
work pretty well, once you get on top of the 3 different parallel
installations, as it were.

It's not what I generally use for my fltk-on-Windows work, but when I
have used it (typically the msys2-mingw32 mode) it has been absolutely
fine, so I'm not entirely sure what it is that Mark has hit.

An unrelated aside; the gcc-9 seems to build quite a bit slower than
the older gcc I use in my usual mingw32 setup, and it can be quite
"chatty" about what it finds in my code. I guess it is being a lot
more thorough. I can't tell if the resulting binary is any the better
for it however!

--
Ian

[Mark Olesen]

Yes! That flag prevented the console from show up. Thank you.

I can not figure out where debug info is being generated. There is no '-g' in the compile command. strip reduces the binary by at least 1/2 the size.

cd /home/markj/opensource/fltk_git/build/src && /mingw64/bin/g++  -DFL_LIBRARY -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I/home/markj/opensource/fltk_git/build -I/home/markj/opensource/fltk_git -I/mingw64/include/freetype2 -I/mingw64/include  -O3 -DNDEBUG   -o CMakeFiles/fltk.dir/Fl_Input_Choice.cxx.obj -c /home/markj/opensource/fltk_git/src/Fl_Input_Choice.cxx

[Mark Olesen]

It is a PITA to get this going (been crazy). Almost there though. Just need to figure out why FLTK test programs are not getting compiled and why the debug info is getting pushed for release.

Visual Studio is by far the quickest and easiest way to produce a binary.

I appreciate your feedback. Thank you.

[Mark Olesen]

I am not sure what the MSYS environment itself is? I am going to try and compile for 32-bit now.

Your article has some good info. The attachment shows my windows start menu with the 3 different shells you had described.

I have given up on fluid not being built for the moment and the release having debug info. I do not rely on fluid or the examples.

[Ian MacArthur]

Mark,

From the screenshot you attached to your last post (the one of the Win10 apps menu) you can see the options to start the shells for the 3 different “personalities” that MSYS2 provides.

The one you have highlighted in that screenshot (MSYS2 MSYS) is the one you *do not* want to be using. It’s more for Msys2 specific internal stuff.

The one you probably *do* want to use is the “MSYS2 MinGW 32-bit” one, as that builds binaries that will work on pretty much *all* WinXX versions.

If you are working in that “MSYS2 MinGW 32-bit” shell (and you have the compiler installed, "pacman -S mingw-w64-i686-gcc”, and other bits and pieces...) then:

Clone a clean checkout of the fltk-1.4 repo. to “someplace”

cd someplace
mkdir build-M2-32
cd build-M2-32
cmake -G “MSYS Makefiles” ..
make

And that really is all there is to it. Just did this on my setup, and it worked OOTB, no problems.

> On 8 Feb 2020, at 23:31, Mark Olesen wrote:
>
> I am not sure what the MSYS environment itself is?

I’m not sure - are you asking what the "MSYS2 MSYS” environment is?

If so, it is a cygwin-like “posix-on-Win32” environment that the MSYS2 folks use for tool porting, to make it simpler to port tools from *nix to Win32.
In very crude terms it provides emulations of fork() and pthreads and dlopen, and a few other bits and pieces, to make it (notionally) easier to cross-compile code onto Win32 (Win32 has no fork, it uses a spawn / exec model instead, and the Windows native threads differ from pthreads in some key ways.)

But AFAIK the "MSYS2 MSYS" layer is “incomplete”, it provides just enough to get them up and running - they recommend the if you need a full posix-on-win32 emulation that you look at cygwin instead.

Note that both cygwin and the MSYS2 MSYS environment need a couple of non-standard DLL’s to allow the posix emulation to work, so that means that any code you build in this environment probably will not run on a “stock” WinXX host

(Aside, rant mode: over the years, I have spent *a lot* of time struggling with WinXX code that was built with one or other cygwin variant that crashed horribly on other hosts, there have been some “issues” with incompatible cygwin DLL’s in the wild over the years; though it *may* be less bad now... Anyway, the upshot is that I try to avoid the cygwin approach when porting code to WinXX and use the “native” API’s instead. So, use mingw basically.)

> I am going to try and compile for 32-bit now.

Should Just Work - see my note above for what I did.

>
> Your article has some good info. The attachment shows my windows start menu with the 3 different shells you had described.
>
> I have given up on fluid not being built for the moment and the release having debug info. I do not rely on fluid or the examples.

Fluid and all the bits were built OK for me, and worked nicely.

[Greg Ercolano]

On 2020-02-09 09:07, Ian MacArthur wrote:
> Anyway, the upshot is that I try to avoid the cygwin approach when porting code to WinXX
> and use the “native” API’s instead. So, use mingw basically.)

I agree, though I went with Microsoft's compiler instead, not because
I'm a fan of them, it's just they wrote the OS, so their compiler should
be pretty good.

On windows I compile my apps against FLTK using the command line, pulling
the C++/Linker flags from FLTK's build log for one of the test programs (e.g. 'hello')
and using those in my Makefile to ensure I use the same build/link flags the FLTK
library did. And I use gnu make (named gmake.exe in my builds) for the Makefiles
(instead of Microsoft's 'nmake') because with that I can write Makefile's that work
across all platforms, or at least use consistent techniques, such as running external
programs to probe the OS for compiler versions/hostnames/versioning info, etc.

[Albrecht Schlosser]

On 2/8/20 10:50 PM Mark Olesen wrote:
> It is a PITA to get this going (been crazy). Almost there though. Just
> need to figure out why FLTK test programs are not getting compiled and
> why the debug info is getting pushed for release.

There are two points in this paragraph. Ian described much better than I
could ever have done what you need to do to use the *right* toolchain.
This should get you going pretty straightforward.

The second point is why FLTK test programs are not getting compiled.
There's a simple reason which is also caused by the wrong toolchain. You
are trying to *cross-compile* with the MSYS toolchain running the MinGW
(32-bit or 64-bit) compiler. Please use Ian's advice to use the correct
"personality" of the MSYS2 shell (with the correct compiler) and
everything should be fine. Forget everything about CMake toolchain files
- these are only used for cross-compiling, but you don't need to
cross-compile if you're using one of the MinGW 32-bit or 64-bit
"personalities" (shells).

The reason why the FLTK test programs are not getting compiled is pretty
simple: when you're cross-compiling (with CMake) fluid is NOT being
built. It is assumed that you have a *native* fluid on your *build host*
that can be used to generate the .cxx and .h file from fluid (.fl)
files. This is a (your) catch-22 problem. You need to build a native
FLTK library to build a native fluid to be able to cross-compile for
*another* host. In your current approach you're using a MSYS host system
to cross-compile for a MinGW target system. This is not going to work.

I'm sorry to say: this would have been much easier if you had told us
earlier which toolchain you were using (and how you installed it). I'm
glad that you gave us the info and Ian could explain what the problem
was. Try to follow his advice (use one of the 'other' MSYS2
personalities/shells) and don't use a toolchain file) and your build
should succeed.

BTW: if you're using the right ("native") GCC for your environment
(MinGW 32/62-bit shell) you should also be able to just run `make' in
the root of the FLTK distribution to build the entire library including
test programs. Running `make' will run ./configure with default settings
for you.