MSYS64 Step by Step Build Instructions?

[Oliver Bailey]

I hope this is the right place for this message.

I have been attempting to build fltk using MSYS2-Mingw64 console.  I've also attempted to use the UCRT, and CLang consoles with no success.  Building on MSYS seems to have different pieces of information in various README files in fltk.  Some generic instructions are in README.CMake.txt.  There are also instructions in README.Windows.txt. and it isn't clear if these instructions are for version 1.4.5 or is it 1.5.0 depending on where you look.  Plain and simple, are there any sequentially written instructions on how to configure, build, and use fltk using UCRT on MSYS2 or MSYS64, which is somewhat unclear as well. I have everything working in Visual Studio Community Edition 2022, but it needs to build without a Microsoft compiler or library of any kind.  I've been trying to work on this for several weeks and as good as FLTK documentation is, it is mirrored by no set instructions on how to build this open source toolkit on Windows without MIcrosoft Visual Studio.  And many of the videos are misleading in how they install Windows components.

I have tried installing using UCRT console and it chokes on the Windows Pen libraries, which I cannot turn off using the -D parameter which shows correctly in chosen options.  It seems to ignore the switches for turning off open GL as well. This is becoming a rabbit hole that I'm about to recommend the client simply use a different cross platform toolkit.  If anyone has successfully built the current 1.4.5 release in MYSYS64 without requiring the Microsoft Runtime or static library, maybe you could share the steps with me.

Thank you,

Oliver Bailey

[Manolo]

I hope this is the right place for this message.

I have been attempting to build fltk using MSYS2-Mingw64 console. ……

I'm building FLTK under Windows11 and the arm64 architecture using MSYS2 and the clang compiler

without any problem. I don't think that using the x86_64 architecture would make things more difficult.

Here are the step by step instructions I followed:

========================

To build and run WIN32-arm64 native FLTK apps :

- install CMake (arm64 or x86_64) from its web site
- install MSYS2 (x86_64) from www.msys2.org
- install the native ARM mingw C/C++ compiler:
    Add this in /etc/pacman.conf file :
       [clangarm64]
       Include = /etc/pacman.d/mirrorlist.mingw
    Run these commands in the msys2 terminal
       pacman -Sy
       pacman -S --needed mingw-w64-clang-aarch64-toolchain
       pacman -S  mingw-w64-clang-aarch64-glew
       pacman -S git
       pacman -S make

At this point, it's possible to git clone the fltk source tree.

The clang arm compiler by default creates executables that need
2 dll's in the same directory: libc++.dll and libunwind.dll
This is fixed adding in the definition of MSYS2_PATH present in file /c/msys64/etc/profile
this component: /c/msys64/clangarm64/bin

Using the system settings application, add to the system environment variable path: C:\msys64\usr\bin\
and C:\msys64\clangarm64\bin

logout / login   (so changed PATH becomes effective)

At that point, it's possible to use cmake-gui for "MSYS Makefiles" and for
default native compilers or for custom compilers
C:/msys64/clangarm64/bin/cc.exe and c++.exe
and build a native windows/arm64 version of FLTK by
  make
in the msys2 terminal.

It's also possible to use cmake in command line mode as follows:
 '/c/Program Files/CMake/bin/cmake.exe' -G "MSYS Makefiles" -S xxxxx -B xxxxx

Fluid, all  test apps, and OpenGL apps run very well.

========================

[Oliver Bailey]

Ahh.  I have been using the fltk makefiles. I'll give this a try and update the post accordingly.  

Thank you very much.

Oliver

--
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 visit https://groups.google.com/d/msgid/fltkgeneral/9743eb15-a550-462f-acc6-c508eb0df3f7n%40googlegroups.com.

[Oliver Bailey]

Thanks Manolo,

Unfortunately there are a number of differences in how x86_64 fltk is built. The current version of Cmake does not have an option for using -G "MSYS Makefiles". for this version 1.5.  I've built this before without issues but the documentation is not well written and seems incomplete. 

Thanks anyway,

Oliver

On Wed, Aug 5, 2026, 8:02 AM Manolo <manol...@gmail.com> wrote:

[Oliver Bailey]

Hi Manolo,

I have made some progress with using the Windows cmake instead of the Mingw cmake (The current instructions state to use the cmake from Mingw).. I have the MSVC development version in my home folder.  When I installed MSYS2, I fetched a new git version of fltk.  I used the Mingw64 console and ran the following from the /home/fltk/build-mingw64 folder:

$ /c/"Program FIles"/CMake/bin/cmake.exe -G "MSYS Makefiles" ..
CMake Error: The current CMakeCache.txt directory C:/msys64/home/olive/fltk/build-mingw64/CMakeCache.txt is different than the directory /home/olive/fltk/build-mingw64 where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt
CMake Error: The source "C:/msys64/home/olive/fltk/CMakeLists.txt" does not match the source "/home/olive/fltk/CMakeLists.txt" used to generate cache.  Re-run cmake with a different source directory.

This error is because the two CMakeCache.txt files are different, which they should be.  However, the Visual Studio build works perfectly, so I am trying ti understand if:

I am running the build correctly by being in the home/olive/fltk/build-mingw64 folder, which is what the current documentation readme states or if something else is wrong.  The only way I could qualify the proper cmake.exe was by using --help.  On the cmake program in the Windows Program Files\Cmake\bin executable offer the MSYS Makefiles option.  Both version of Cmake were at 4.4.2.

Or, am I running from the wrong console?

I deleted the prior MSYS2 install and installed it again prior to attempting this compile.  It does look like some progress has been made.

Any ideas or suggestions would be welcome.

Thank you,

Oliver

[Manolo]

Le jeudi 6 août 2026 à 22:38:49 UTC+2, oliver.h....@gmail.com a écrit :

Hi Manolo,

I have made some progress with using the Windows cmake instead of the Mingw cmake (The current instructions state to use the cmake from Mingw)..

I don't understand what you mean here because I'm not aware it exists a Windows cmake distinct from a Mingw cmake. You should use only THE cmake program downloaded from https://cmake.org/download/ and then installed on your computer, by default at "C:/Program Files/CMake/". In subdirectory "bin" of this directory you'll find "cmake.exe" you can use for the command line interface to CMake and "cmake-gui.exe" you should use to pilot CMake via a GUI.

 

I have the MSVC development version in my home folder.  When I installed MSYS2, I fetched a new git version of fltk.  I used the Mingw64 console and ran the following from the /home/fltk/build-mingw64 folder:

$ /c/"Program FIles"/CMake/bin/cmake.exe -G "MSYS Makefiles" ..
CMake Error: The current CMakeCache.txt directory C:/msys64/home/olive/fltk/build-mingw64/CMakeCache.txt is different than the directory /home/olive/fltk/build-mingw64 where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt
CMake Error: The source "C:/msys64/home/olive/fltk/CMakeLists.txt" does not match the source "/home/olive/fltk/CMakeLists.txt" used to generate cache.  Re-run cmake with a different source directory.

That suggests some mix up in how MSYS-related user home directories in your computer are set.
What you should get is that "C:/msys64/home/olive" and "/home/olive" are two synonym names for exactly the same directory. The former is used by Windows, the latter by MSYS which mimics the Unix way to name files.

To make sure what exactly is behind "/home", run in the MSYS2 terminal command "df -h". You should get this:

   # df -h
   Filesystem      Size  Used Avail Use% Mounted on
   C:/msys64        64G   38G   26G  60% /
which confims that "/" is a synonym used by MSYS for  what Windows calls "C:/msys64".

Once you are in this position, and assuming you have correctly installed the MINGW64 C and C++ compilers and the MSYS2 terminal program, you can git clone fltk into, for example "/home/olive/fltk", create subdirectory 

"/home/olive/fltk/build", place yourself in that subdirectory and type in the MSYS2 console window

   /c/"Program FIles"/CMake/bin/cmake.exe -G "MSYS Makefiles" ..

and after this, type

   make

This should build successfully FLTK for you without any extra Windows library besides those available on any Windows system.

  

[Manolo]

Once FLTK has been built, here is how you can build your program as a client of the FLTK library.

Assuming the build directory used when you built FLTK is "/home/olive/fltk/build",  type this command in the MSYS terminal window

    /home/olive/fltk/build/fltk-config --compile prog.cxx auxfile1.cxx auxfile2.cxx …… -static-libstdc++

where you put the list of all source files of your program and finish the command line with "-static-libstdc++".

This will produce "prog.exe".

Alternatively, use CMake to build your program following instructions given in section 3.4 of the README.CMake.txt of the fltk source tree.

[Greg Ercolano]

On 8/6/26 23:40, Manolo wrote:

Le jeudi 6 août 2026 à 22:38:49 UTC+2, oliver.h....@gmail.com a écrit :

Hi Manolo,

I have made some progress with using the Windows cmake instead of the Mingw cmake (The current instructions state to use the cmake from Mingw)..

I don't understand what you mean here because I'm not aware it exists a Windows cmake distinct from a Mingw cmake.

    I ran into this recently; there's one cmake with msys2,
    and another that comes with mingw64.

    The separate 'pacman' package names being:

        - cmake                      (MSYS2 package)
        - mingw-w64-x86_64-cmake     (mingw package)

    I've only had luck with the latter, where 'cmake -G "MSYS Makefiles" ..'
    works to build FLTK with regular 'make'.

    At one point it was a big deal to rip out the msys2 cmake and replace it with the mingw cmake,
    as there were conflicting interleaving libraries and such.. very messy to fix.

 You should use only THE cmake program downloaded from https://cmake.org/download/ and then installed on your computer, by default at "C:/Program Files/CMake/". In subdirectory "bin" of this directory you'll find "cmake.exe" you can use for the command line interface to CMake and "cmake-gui.exe" you should use to pilot CMake via a GUI.

    I recall needing to use cmake from cmake.org as a separate package a year or three ago,
    but not needing it recently when setting up a new machine, as the above 'pacman' installed
    mingw cmake worked OK.

[Greg Ercolano]

On 8/7/26 01:49, Greg Ercolano wrote:

    The separate 'pacman' package names being:

        - cmake                      (MSYS2 package)
        - mingw-w64-x86_64-cmake     (mingw package)

    I've only had luck with the latter, where 'cmake -G "MSYS Makefiles" ..'
    works to build FLTK with regular 'make'.

    FWIW I just did a 'git pull' for fltk current on that Windows machine and rebuilt,
    and was able to replicate the "tablet related errors" the OP reported.

    The problems kick in about 41% into the 'make' build, which is when it hits the Fl_WinAPI_Pen_Driver.cxx file:

[..snip..]
[ 40%] Building CXX object src/CMakeFiles/fltk.dir/Fl_get_key_win32.cxx.obj
[ 41%] Building CXX object src/CMakeFiles/fltk.dir/drivers/WinAPI/fl_WinAPI_platform_init.cxx.obj
[ 41%] Building CXX object src/CMakeFiles/fltk.dir/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx.obj
C:/temp/fltk-1.5.x.git/src/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx:309:37: error: 'POINTER_INFO' doe
s not name a type; did you mean 'PRINTER_INFO_9'?
  309 |                               const POINTER_INFO &pointer_info) {
      |                                     ^~~~~~~~~~~~
      |                                     PRINTER_INFO_9
C:/temp/fltk-1.5.x.git/src/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx: In function 'void update_position(PenDevice*,
HWND, const int&)':
C:/temp/fltk-1.5.x.git/src/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx:313:27: error: request for member 'ptPixelLocat
ion' in 'pointer_info', which is of non-class type 'const int'
  313 |   POINT pt = pointer_info.ptPixelLocation;
      |                           ^~~~~~~~~~~~~~~
C:/temp/fltk-1.5.x.git/src/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx: At global scope:
C:/temp/fltk-1.5.x.git/src/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx:343:38: error: 'POINTER_PEN_INFO' does not name
 a type; did you mean 'POINTER_64_INT'?
  343 | static State compute_pen_state(const POINTER_PEN_INFO &pi) {
      |                                      ^~~~~~~~~~~~~~~~
      |                                      POINTER_64_INT
[..many errors snipped..]

    I took your advice (Manolo) and installed cmake.org's cmake, and used that to build fltk using e.g.

        $ /c/Program\ Files/CMake/bin/cmake.exe -G "MSYS Makefiles" ..
        [..snip..]

        $ make
        [..]

    ..but it blew out with the same errors.

    I don't really need help with this, please focus on Oliver, I'm just reporting I can replicate.
    I don't use the msys2/mingw stuff (other than when people ask about it),
    as for work I always prefer cmake.org+Visual Studio+nmake, IIRC because in my mind
    VS is the "native" compiler on Windows.

[imm]

On Thu, 6 Aug 2026 at 18:38, Oliver Bailey wrote:
>
> Thanks Manolo,
> Unfortunately there are a number of differences in how x86_64 fltk is built. The current version of Cmake does not have an option for using -G "MSYS Makefiles". for this version 1.5. I've built this before without issues but the documentation is not well written and seems incomplete.
>

This really puzzled me - enough that I went and did a clean build just
to see what happened.
Also, I note that "later" Greg posted about subtle differences between
the Msys2 cmake and the mingw64 cmake, but I _believe_ I only have the
Msys2 cmake on this host, and it works. viz:

+++++++++++++++++++++
$ mkdir build_test_M64

$ cd build_test_M64/

$ cmake -G "MSYS Makefiles" ..
-- The C compiler identification is GNU 16.1.0
-- The CXX compiler identification is GNU 16.1.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler:
D:/Programs/Msys2_64/mingw64/bin/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:
D:/Programs/Msys2_64/mingw64/bin/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
-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
-- Found Doxygen: D:/Programs/doxygen/bin/doxygen.exe (found version
"1.9.4 (5d15657a55555e6181a7830a5c723af75e7577e2)") found components:
doxygen missing components: dot
-- Could NOT find LATEX (missing: LATEX_COMPILER)
-- Found OpenGL: opengl32
-- Looking for glXGetProcAddressARB
-- Looking for glXGetProcAddressARB - not found

-- Configuration Summary for FLTK 1.4.5 generated by CMake 3.23.2 --

-- The following OPTIONAL packages have been found:

* Doxygen
* OpenGL

-- The following OPTIONAL packages have not been found:

* LATEX

-- Static libraries will be built in:
D:/Tools/Ian/fltk-1.4/build_test_M64/lib
-- Shared libraries will not be built (set
FLTK_BUILD_SHARED_LIBS=ON to build)
-- The forms library will be built in:
D:/Tools/Ian/fltk-1.4/build_test_M64/lib
-- The OpenGL library will be built in:
D:/Tools/Ian/fltk-1.4/build_test_M64/lib
-- fluid will be built in:
D:/Tools/Ian/fltk-1.4/build_test_M64/bin
-- fltk-options will be built in:
D:/Tools/Ian/fltk-1.4/build_test_M64/bin
-- Test programs will be built in:
D:/Tools/Ian/fltk-1.4/build_test_M64/bin/test
-- Example programs will not be built (set FLTK_BUILD_EXAMPLES=ON to build)
--
-- Build configuration <unspecified>
-- Installation prefix C:/Program Files (x86)/FLTK

-- Bundled Libraries JPEG = Bundled
-- PNG = Bundled
-- ZLIB = Bundled

-- Fl_Cairo_Window support No
-- Use std:: No

-- End of Configuration Summary --

-- Configuring done
-- Generating done
-- Build files have been written to: D:/Tools/Ian/fltk-1.4/build_test_M64

++++++++++++++++++

Elsewhere, something was said about a "Windows cmake" - does that mean
the cmake that's built into VS?
I find that works well _for VS_, but it's done weird things to me
(probably bad paths I assume) when mixing it with the mingw tools, so
I always use the Msys2 cmake.

As an aside, under Msys shell, the cmake "Unix Makefiles" target
actually works OK - the shell is just enough like Unix to get away
with that in general!

As an aside, as regards "mingw64-alike" tools I've always rather
favoured the TDM-gcc compiler: it works a lot like the mingw63
compiler, but automatically static-links a few of the gcc/g++
dependencies, which makes it simper to use in practice (albeit it does
tend to generate slightly larger binaries...)
The downsides to this are:
- It's just the compiler and related tools, so you still need the
Msys2 stuff anyway to get a full shell going.
- It appears to have dropped out of maintenance. Which is unfortunate.
I'm still using it though!

Also - I'd caution against installing the fltk libs - just use 'em
from the build dir. It's "cleaner" and avoids cluttering up the
system...

[Albrecht Schlosser]

On 8/7/26 10:49 Greg Ercolano wrote:

On 8/6/26 23:40, Manolo wrote:

Le jeudi 6 août 2026 à 22:38:49 UTC+2, oliver.h....@gmail.com a écrit :

Hi Manolo,

I have made some progress with using the Windows cmake instead of the Mingw cmake (The current instructions state to use the cmake from Mingw)..

I don't understand what you mean here because I'm not aware it exists a Windows cmake distinct from a Mingw cmake.

    I ran into this recently; there's one cmake with msys2,
    and another that comes with mingw64.

    The separate 'pacman' package names being:

        - cmake                      (MSYS2 package)
        - mingw-w64-x86_64-cmake     (mingw package)

    I've only had luck with the latter, where 'cmake -G "MSYS Makefiles" ..'
    works to build FLTK with regular 'make'.

    At one point it was a big deal to rip out the msys2 cmake and replace it with the mingw cmake,
    as there were conflicting interleaving libraries and such.. very messy to fix.

Yes, there are indeed multiple CMake versions for Windows that can be installed from the official CMake download site (this is the "native Windows" one), and others that come with the different flavors (called "environments") of MSYS2. It's essential to install the correct one, and one solution for MSYS2 builds is as Greg wrote above. If you install the correct one with MSYS2, then that `cmake` command will be in the PATH of the respective environment.

Warning (to all readers): do not attempt to add MSYS2 paths to the Windows system PATH variable - which is suggested by some installation instructions. This can lead to using the wrong versions of tools, depending on the current environment. For instance, if you run a Windows shell to build using Visual Studio you might find yourself using the MSYS CMake version, and vice versa.

That said, the CMake GUI version installed from CMake **may** be missing the MSYS2 CMake generators (-G "MSYS Makefiles") and the MSYS2 cmake will likely not have the Visual Studio generators.

 You should use only THE cmake program downloaded from https://cmake.org/download/ and then installed on your computer, by default at "C:/Program Files/CMake/". In subdirectory "bin" of this directory you'll find "cmake.exe" you can use for the command line interface to CMake and "cmake-gui.exe" you should use to pilot CMake via a GUI.

    I recall needing to use cmake from cmake.org as a separate package a year or three ago,
    but not needing it recently when setting up a new machine, as the above 'pacman' installed
    mingw cmake worked OK.

Yep, I'm currently using different CMake programs - i.e. those installed with the respective tool: Windows vs. MinGW vs, MSYS2. It's even more complicated because of the different MSYS2 "environments".

And yes, unfortunately our README files are outdated. They don't cover MSYS2 explicitly, but since MSYS2 uses a POSIX shell, the easiest way is to use the Unix (Linux) instructions.

[Albrecht Schlosser]

On 8/7/26 11:15 Greg Ercolano wrote:

On 8/7/26 01:49, Greg Ercolano wrote:

    The separate 'pacman' package names being:

        - cmake                      (MSYS2 package)
        - mingw-w64-x86_64-cmake     (mingw package)

    I've only had luck with the latter, where 'cmake -G "MSYS Makefiles" ..'
    works to build FLTK with regular 'make'.

    FWIW I just did a 'git pull' for fltk current on that Windows machine and rebuilt,
    and was able to replicate the "tablet related errors" the OP reported.

    The problems kick in about 41% into the 'make' build, which is when it hits the Fl_WinAPI_Pen_Driver.cxx file:

[..snip..]
[ 40%] Building CXX object src/CMakeFiles/fltk.dir/Fl_get_key_win32.cxx.obj
[ 41%] Building CXX object src/CMakeFiles/fltk.dir/drivers/WinAPI/fl_WinAPI_platform_init.cxx.obj
[ 41%] Building CXX object src/CMakeFiles/fltk.dir/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx.obj
C:/temp/fltk-1.5.x.git/src/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx:309:37: error: 'POINTER_INFO' doe
s not name a type; did you mean 'PRINTER_INFO_9'?
  309 |                               const POINTER_INFO &pointer_info) {
      |                                     ^~~~~~~~~~~~
      |                                     PRINTER_INFO_9

This is a known issue I'm just working on. For some configurations we don't raise the required Windows version macros correctly, hence the required Pen driver related symbols are not defined. I think that I can push an update later today.

For now it should be possible to use cmake with `-D FLTK_OPTION_PEN_SUPPORT=OFF` to work around this issue, but I'm not sure if it really works (it used to work, but recent changes may have introduced this issue again). Anybody having these PEN related issues should give it a try - or wait until I can push the update.

[Ian MacArthur]

On Friday, 7 August 2026 at 10:32:32 UTC+1 Albrecht-S wrote:

    The problems kick in about 41% into the 'make' build, which is when it hits the Fl_WinAPI_Pen_Driver.cxx file:

[..snip..]
[ 40%] Building CXX object src/CMakeFiles/fltk.dir/Fl_get_key_win32.cxx.obj
[ 41%] Building CXX object src/CMakeFiles/fltk.dir/drivers/WinAPI/fl_WinAPI_platform_init.cxx.obj
[ 41%] Building CXX object src/CMakeFiles/fltk.dir/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx.obj
C:/temp/fltk-1.5.x.git/src/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx:309:37: error: 'POINTER_INFO' doe
s not name a type; did you mean 'PRINTER_INFO_9'?
  309 |                               const POINTER_INFO &pointer_info) {
      |                                     ^~~~~~~~~~~~
      |                                     PRINTER_INFO_9

This is a known issue I'm just working on. For some configurations we don't raise the required Windows version macros correctly, hence the required Pen driver related symbols are not defined. I think that I can push an update later today.

As Albrecht says, not all mingw-related toolchains are "good" at setting a "high enough" "WINVER" and "_WIN32_WINNT" macro value.

You can poke around this by setting "-DWINVER=0x0602  -D_WIN32_WINNT=0x0602" and it ought to work thereafter.  

(Though maybe still fail with the really old Msys/mingw(32) stuff, since it's headers literally do not have the pen stuff at all!)

FWIW, with my Msys2/mingw64 build, it's fine. Ditto TDM-gcc. With my older Msys/mingw(32) setup, it's bad...

 

[Albrecht Schlosser]

On 8/6/26 22:37 Oliver Bailey wrote:
> When I installed MSYS2, I fetched a new git version of fltk.  I used
> the Mingw64 console and ran the following from the
> /home/fltk/build-mingw64 folder:
>
> $ /c/"Program FIles"/CMake/bin/cmake.exe -G "MSYS Makefiles" ..
> CMake Error: The current CMakeCache.txt directory
> C:/msys64/home/olive/fltk/build-mingw64/CMakeCache.txt is different
> than the directory /home/olive/fltk/build-mingw64 where CMakeCache.txt
> was created. This may result in binaries being created in the wrong
> place. If you are not sure, reedit the CMakeCache.txt
> CMake Error: The source "C:/msys64/home/olive/fltk/CMakeLists.txt"
> does not match the source "/home/olive/fltk/CMakeLists.txt" used to
> generate cache.  Re-run cmake with a different source directory.

No matter if these directories ( C:/msys64/home/olive/fltk/build-mingw64
vs. /home/olive/fltk/build-mingw64) are physically the same directories,
CMake "sees" the directory *strings* and bails out because they are
literally different.

This happens because you executed CMake twice on the same directory with
different CMake versions and/or path (current directory) settings. If
you need to reuse an existing build folder with a new CMake run, then
you should really delete the entire folder (not only the included
CMakeCache.txt file) and start CMake again from scratch.

> This error is because the two CMakeCache.txt files are different,
> which they should be.  However, the Visual Studio build works perfectly,

Note that the *source* folder of FLTK can be the same for any CMake
build you want, but the *build* folders must be different. I assume that
your VS build was done in another folder, not in ".../build-mingw64".

> so I am trying ti understand if:
> I am running the build correctly by being in the
> home/olive/fltk/build-mingw64 folder, which is what the current
> documentation readme states or if something else is wrong.  The only
> way I could qualify the proper cmake.exe was by using --help.  On the
> cmake program in the Windows Program Files\Cmake\bin executable offer
> the MSYS Makefiles option. Both version of Cmake were at 4.4.2.
>
> Or, am I running from the wrong console?

I don't know, but as a general advice: Don't add any of the MSYS
directories to the Windows System PATH variable (as I wrote already in a
prior reply) and always use the tools that come with the particular
environment. Hence, if you build with MSYS2, run a MSYS2 shell (with the
"environment" you need/want) and preferably the CMake that comes with
MSYS2 (see Greg's reply), and if you want to build with Visual Studio,
run a VS Developer Command Prompt, or whatever they call it.

Exception: if you start the CMake GUI version installed from the CMake
site (you may have created a desktop icon for it), you don't need to run
a console at all. You can just click on Configure, Build, and then "Open
Project" or similar. This should launch Visual Studio and should work
w/o ever using a Windows console.

[Oliver Bailey]

Good morning,

I was able to get the tools installed and a compile started.  Until I got to the pen driver which generated the following error:

mingw32-make[2]: *** [src\CMakeFiles\fltk.dir\build.make:2674: src/CMakeFiles/fltk.dir/drivers/WinAPI/Fl_WinAPI_Pen_Driver.cxx.obj] Error 1
mingw32-make[1]: *** [CMakeFiles\Makefile2:746: src/CMakeFiles/fltk.dir/all] Error 2

Since this is a copy of the git source that compiles on Visual Studio 2022 and 2026 with success, I'm not going further until the pen driver issues are resolved.  I recommending to the cliient moving to wxWidgets.  I've been in hardware and systems level development for over 55 years. MSYS2 works well but the different consoles have their own issues.  Ironically, this is where I started out about a week ago, with things ending at the pen driver.  This works in the Mingw64 console.  FYI-There is a Min
mingw32-make: *** [Makefile:155: all] Error 2

The following is the makefile build configuration report

$ cmake -B build -G "MinGW Makefiles"

-- The C compiler identification is GNU 16.1.0
-- The CXX compiler identification is GNU 16.1.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done

-- Check for working C compiler: C:/msys64/mingw64/bin/cc.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: C:/msys64/mingw64/bin/c++.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: C:/msys64/mingw64/bin/pkg-config.exe (found version "3.0.5")
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Looking for EWOULDBLOCK
-- Looking for EWOULDBLOCK - found
-- Found OpenGL: opengl32

-- Configuration Summary for FLTK 1.5.0 generated by CMake 4.4.2 --

-- The following OPTIONAL packages have been found:

 * OpenGL

-- The following OPTIONAL packages have not been found:

 * Doxygen

-- Static libraries    will be built in: C:/msys64/home/olive/fltk/build/lib

-- Shared libraries    will not be built (set FLTK_BUILD_SHARED_LIBS=ON to build)

-- The forms library   will not be built (set FLTK_BUILD_FORMS=ON to build)
-- The OpenGL library  will be built in: C:/msys64/home/olive/fltk/build/lib
-- Pen/tablet support  will be built in: C:/msys64/home/olive/fltk/build/lib
--
-- fluid               will be built in: C:/msys64/home/olive/fltk/build/bin
-- fltk-options        will be built in: C:/msys64/home/olive/fltk/build/bin
-- Test programs       will be built in: C:/msys64/home/olive/fltk/build/bin/test

-- Example programs    will not be built (set FLTK_BUILD_EXAMPLES=ON to build)

-- Screenshot programs will not be built (set FLTK_BUILD_SCREENSHOTS=ON to build)
--
-- FLTK Library (API) version     1.5.0
-- ABI version (FL_ABI_VERSION)   10500

-- Bundled Libraries              JPEG     = Bundled
--                                PNG      = Bundled
--                                ZLIB     = Bundled

-- Fl_Cairo_Window support        No

-- Build Environment:

-- Build configuration            <unspecified>
-- Installation prefix            C:/Program Files (x86)/FLTK

-- MinGW Environment (MSYSTEM)    MINGW64
-- C Compiler                     C:/msys64/mingw64/bin/cc.exe
-- C++ Compiler                   C:/msys64/mingw64/bin/c++.exe
-- CMAKE_CXX_STANDARD             11
-- CMAKE_CXX_STANDARD_REQUIRED    Yes
-- CMAKE_CXX_EXTENSIONS           No

-- End of Configuration Summary --

-- Configuring done (28.8s)
-- Generating done (1.3s)
-- Build files have been written to: C:/msys64/home/olive/fltk/build

$ cmake --build build -j8
[  1%] Building C object zlib/CMakeFiles/fltk_z.dir/adler32.c.obj
[  1%] Building C object zlib/CMakeFiles/fltk_z.dir/compress.c.obj
[  1%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jmemnobs.c.obj
[  1%] Building C object zlib/CMakeFiles/fltk_z.dir/crc32.c.obj
[  1%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jaricom.c.obj
[  1%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jcomapi.c.obj
[  1%] Building C object zlib/CMakeFiles/fltk_z.dir/deflate.c.obj
[  1%] Building CXX object src/CMakeFiles/fltk.dir/Fl.cxx.obj
[  2%] Building CXX object src/CMakeFiles/fltk.dir/Fl_Adjuster.cxx.obj
[  2%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jutils.c.obj
[  2%] Building CXX object src/CMakeFiles/fltk.dir/Fl_Bitmap.cxx.obj
[  2%] Building CXX object src/CMakeFiles/fltk.dir/Fl_Browser.cxx.obj
[  2%] Building C object zlib/CMakeFiles/fltk_z.dir/gzclose.c.obj
[  3%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jerror.c.obj
[  3%] Building C object zlib/CMakeFiles/fltk_z.dir/gzlib.c.obj
[  4%] Building C object zlib/CMakeFiles/fltk_z.dir/gzread.c.obj
[  4%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jmemmgr.c.obj
[  4%] Building CXX object src/CMakeFiles/fltk.dir/Fl_Browser_.cxx.obj
[  4%] Building C object jpeg/CMakeFiles/fltk_jpeg.dir/jcapimin.c.obj

Thanks for all the help, I hope some of this helps.

Thanks again,

Oliver

On Wed, Aug 5, 2026 at 8:02 AM Manolo <manol...@gmail.com> wrote:

[Oliver Bailey]

Hi Albrecht,

One of the README files illustrated using the cmake executable from the Windows Program Files directory, which is why I used the path directory the executable in the MSYS2 console.  I tried using that make program using the console alias command but that command doesn't always work as I read somewhere else.  I did not add the path to the MSYS console, I simmply substituted the Windows cmake version for the MSYS console version.  This did not disturb the visual studio version because I did a git for a MSYS console isolated version. I am grateful for your help and got a build going only to have issues with the FL_PEN_DRIVER on the Mingw64 side of the build. The long and short of this is the same source that builds and works on Visual Studio 2022 and 2026, fails on the MinGW64 side which tells me the problem if either with MinGW64 defines or the MinGW64 build system.  I am not interested in the problem, I just needed to determine of the system would build per instructions.  The instructions are not well organized and are in themselves contradictory. depending on which of the 21 or so README and notes files you read.  If I can't figure it out, I cannot expect a client's developer to figure it out.  Its too easy to fall into these traps on community developed software products.  It the nature of various factors but no one other than the developers know the product as they do,  and hurried or incomplete versioning documents lead to problems.  And of course there is always the other tools that factor in, here with MYSY2.  FLTK is a great product and it works great when compiled with Visual Studio.  MSYS2 is also a great tool and makes consistent builds with products it works with.  But it can be a pain with others.  The problem in this case is that the build system has some issues with the current source version.  I don't know where the problems re and don't need to.  If I can't build this from the instructions provided without intimate knowledge of how the build tools are coded, I can't use the product.  There are too many tools on the floor to figure out why they aren't working.  

Thanks to everyone who chimed in to help.  

Oliver Bailey

--
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 visit https://groups.google.com/d/msgid/fltkgeneral/01592cff-147b-4a22-8f03-883029ee7ade%40aljus.de.

[Oliver Bailey]

Hi Ian,

Thank you, you've given me insight and I'll try your work arounds.  This is for a client who wants VS compatibility, GNU freedom from VS, and the target platform is a Windows 11 Tablet that uses a pen.  Jackpot!  One of the biggest issues with MinGW is how many different "MinGW" branded toolchains there are.  And that is a rabbit hole all its own. I will try your Msys2/mingw64 suggestion.  Microsoft isn't helping with where they are trying to take Windows either.  I'll give these a try and report back.  

Thank you so very much.

Oliver

--

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 visit https://groups.google.com/d/msgid/fltkgeneral/c23376be-7d4a-4d6c-bb4c-358c89c16c63n%40googlegroups.com.

[Oliver Bailey]

Thank you so much. I will try that.

--
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 visit https://groups.google.com/d/msgid/fltkgeneral/781124b5-4248-4275-b245-72aec1f14264%40aljus.de.

[Albrecht Schlosser]

Hi Oliver, thank you very much for your detailed comments.

I apologize for the incomplete and/or confusing (or even contradicting) README files. These have grown over time and really need a rework to be more concise, and they also need to be updated for current development of build tools like MSYS2/MinGW64. Many of these instructions have been written prior to broad usage of MSYS2 for the - now abandoned - old MinGW tools (from no longer existent mingw.org). But anyway, that's only to let you know why this is the current state. I'm sorry if users like you have trouble building FLTK with these Windows tools, but I really appreciate your feedback.

However, I need to say that FLTK 1.5 from Git is our current development version, and if you use the bleeding edge of software development you may run into issues. This is normal and to be expected. The pen driver is a brand new development in FLTK 1.5, and - as I wrote before - I'm working on a fix for its build issues. Note that FLTK 1.5 has not been released to the public yet.

For a production environment (as you say: a client) I suggest to use a released (stable) version of the software, i.e. FLTK 1.4.5. In FLTK 1.4 you can still use configure + make for MSYS2 (with bundled Makefiles), but we recommend using CMake as well. You need to use CMake anyway to generate the Visual Studio IDE files. Using MSYS2 *should* work OOTB if the build tools are installed and working correctly, and if you use the correct tool setup which is, as we already know, difficult to get right.

If you try and have issues with FLTK 1.4.5, please let us know and feel free to ask for help.

I'm personally building FLTK 1.5 [1] with my Windows test system for all build systems I'm aware of, and I got everything working as expected:

- Visual Studio 2019 (not the latest, I know)
- old MinGW (previously from mingw.org, see above), it's still working with some tweaks, and it's 32-bit only
- MSYS2/MINGW64: this is nowadays called a "legacy" environment by the MSYS2 people
- MSYS2/UCRT64: this is AFAICT the preferred MSYS2 environment for current Windows versions
- MSYS2/CLANG64: uses the Clang compiler

All these build environments have their own issues, which is not easy to document, particularly because there are so many options to install the build tools and compilers.

I hope this helps or - at least - clarifies some of the issues you experienced. I'll take your feedback to work on the documentation and README files to improve particularly the instructions for building on Windows with these specific tools.

------
[1] I added to my to-do list: build the latest stable 1.4.5 on my test system with all Windows build tools to be sure they work as well.

To view this discussion visit https://groups.google.com/d/msgid/fltkgeneral/CAD186y%2BHcX2RDrRtBsa-TygJDDyV9fyZ6%2BgTSRkFSd0SNTdSmg%40mail.gmail.com.

[Oliver Bailey]

I built the VS2022 and 2026 libraries first and tested fltk, fluid, demo and test.  When a GNU build was requested, I installed MSYS2, and copied the folder structure that worked for VS over to the MinGW64 console environment.  Since it had already compiled and worked on VS, it should,, in theory, work on MYSY2, I thought. One of the README files, I believe it was Windows, suggested using alias to point to the CMake Windows Program Files Cmake program.  When I installed the MSYS2 Mingw64 mingw-w6-x86_64 toolchain, the make versions between MSYS2 and Windows Cmake were both at 4.4.2.  The only difference was file size AND available make base scripts -G "MinGW Makefiles". There are six different sets of instructions on how to build fltk outside of VS with Cygwin, MSYS2, and several different methods for MinGW64.  I only made the mistake of adding Windows or MSYS to the other path and then doing a build once.  I had to reinstall Windows because I accidentally built a system driver with MSYS and the driver got loaded on a Windows reboot.  Not a pretty sight.

Thank you so much Albrecht.

I welcome your and the other members input gratefully.

Oliver

--

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 visit https://groups.google.com/d/msgid/fltkgeneral/987b95ac-1a31-43e8-bc20-61cd50ca22c0%40aljus.de.

[Oliver Bailey]

That is where is initially got messed up with CMAKE.  Windows native uses nmake for command line builds, which is their own product.  Cmake has a Windows installer for their tools. 

The README.Windows. txt file included with fltk 1.5, has a snippet using the alias command to point to the Windows CMake installed binary.  When I ran that and got the version number, it was the same version as MSYS64 Cmake, both were 4.4.2.  But, when you run the Cmake --help, they have completely different supported CMake build scripts.  And comparing those to the MSY64 vs MSYS64 MinGW cmake, they are ALL at version 4.4.2, and all have a varying list is supported builds for and without IDE build scripts.  The last one I posted this morning was using the following tools installed by pacman in MSYS2 MinGW:

pacman -S mingw-w64-x86_64-toolchain mingw-w64-x86_64-cmake mingw-w64-x86_64-ninja

the initial build using that cmake is:

cmake -B build -G "MinGW Makefiles"

followed by:

cmake --build build 

the output I copied earlier was produced with those commands inside the MSYS64 MINGW64 console.

and there is a package in the pacman repository named:

mingw-w6-x86_64-fltk

I found that a couple days ago and I'm not sure what exactly its for.  And your right Ian, some of the older compilers work better as you mentioned earlier.  

Oliver

--
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 visit https://groups.google.com/d/msgid/fltkgeneral/CAGFM6dbxHFKohUCVZOzMWPnA5V2vOF%3DTLu7ZGJZDTkixQpGJ9Q%40mail.gmail.com.

[Albrecht Schlosser]

Just a few notes, please see my comments below.

On 8/7/26 14:22 Oliver Bailey wrote:

I built the VS2022 and 2026 libraries first and tested fltk, fluid, demo and test.  When a GNU build was requested, I installed MSYS2, and copied the folder structure that worked for VS over to the MinGW64 console environment.  Since it had already compiled and worked on VS, it should,, in theory, work on MYSY2, I thought.

Your thoughts are correct, but there's something that doesn't seem clear from your description. CMake has a notion of a source folder and a build folder. It's important to know that *ideally* the source folder is NOT modified by CMake if you build in a separate build folder, and you can have several distinct build folders. This is called a out-of-source build, and FLTK strictly follows this idea and does not modify the build folder when using out-of-source builds. FLTK does even block doing in-source builds since some time (likely since 1.5 development, but maybe even already in 1.4, not sure).

In my systems (Linux, macOS, and Windows) I use a nested build structure:

- fltk-root
  |- build
     |- Visual Studio
     |- MinGW
     |- MSYS2/MINGW64
     |- ...

This way I can share the FLTK root folder by old build systems. You can even have the build folders anywhere else on your disk, i.e. totally outside the FLTK root, and the FLTK source folder can even be read-only.

One of the README files, I believe it was Windows, suggested using alias to point to the CMake Windows Program Files Cmake program. 

I think this was still at the time where old MinGW was used, and this was much more compatible with the original Windows CMake program (downloaded from the CMake download site).

When I installed the MSYS2 Mingw64 mingw-w6-x86_64 toolchain, the [c]make versions between MSYS2 and Windows Cmake were both at 4.4.2.  The only difference was file size AND available make base scripts -G "MinGW Makefiles".

Yes, that's typical for CMake. Use `cmake --help` to see which generators are available. It depends on the CMake build which ones a particular CMake executable offers. It may also be that the CMake executable checks if a particular build system like VS can be found at runtime, but I don't know.

There are six different sets of instructions on how to build fltk outside of VS with Cygwin, MSYS2, and several different methods for MinGW64.

Unfortunately you need different instructions for different build tools. However, the generic CMake instructions would be pretty similar, at least from the commandline or if you are using a CMake GUI version. But even the latter has basically two different flavors (Windows GUI, aka cmake-gui, Linux/unix ccmake with text mode interface). The former (the real GUI) can be used on all platforms.

I only made the mistake of adding Windows or MSYS to the other path and then doing a build once.

Yep, that should really be avoided, particularly if you're using more than one build system on a particular Windows system.

[Oliver Bailey]

No problem Albrecht.  After all these years I've been in development, this is routine to some extent.  I originally built using the UCRT console and tools to eliminate dependency on VS libraries. I thought I had pulled the 4.5 source.  So, I will go back and see where things do build with GNU.  I was unaware the pen drivers were new probably because I didn't read all the change logs in the fltk folder.  I would be glad to post what I find.  This may take me a couple of days since its Friday and my plate is full. Thanks Ian, happy to help any way I can. 

Oliver

To view this discussion visit https://groups.google.com/d/msgid/fltkgeneral/933ba7d0-a7ce-41f9-9491-e1ec4ae33cf2%40aljus.de.

[Albrecht Schlosser]

On 8/7/26 14:53 Oliver Bailey wrote:
> That is where is initially got messed up with CMAKE.  Windows native
> uses nmake for command line builds, which is their own product.  Cmake
> has a Windows installer for their tools.
> The README.Windows. txt file included with fltk 1.5, has a snippet
> using the alias command to point to the Windows CMake installed
> binary.  When I ran that and got the version number, it was the same
> version as MSYS64 Cmake, both were 4.4.2. But, when you run the Cmake
> --help, they have completely different supported CMake build scripts.

Yes, that's how CMake works, please see also my previous reply.

Note to all: I will now take a break, and then I'll concentrate on
fixing the build issues with pen support, which is already tested and
(almost) ready to install. I'll read further notes here after this is
done, and I'll let you know when the update is pushed to the repo.

Please don't expect anything from me here within the next 1-3 hours,
unless the fix is uploaded earlier.

[Oliver Bailey]

Ian,

I couldn't wait.  I tried building 1.3.11, 1.4.2, 1.4.3, and 1.4.4-relased.  Al of them built and work with the same MSYS2-Mingw64 console and the same make build parameters used in the fltk-1.5 build.  I will document the process and post it.  And that was using the CMake 4.4.2 with the -g "MinGW Makefiles" parameter and the latest toolchain.

On to other things.  Thanks again Ian.

Oliver

On Fri, Aug 7, 2026 at 4:43 AM Ian MacArthur <imaca...@gmail.com> wrote:

--

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 visit https://groups.google.com/d/msgid/fltkgeneral/c23376be-7d4a-4d6c-bb4c-358c89c16c63n%40googlegroups.com.

[Albrecht Schlosser]

On 8/7/26 15:08 Albrecht Schlosser wrote:
> I'll let you know when the update is pushed to the repo.

Done in commit c50d068841a5bb69cbac0352621e85565ffc6871. This should
enable building with or w/o pen support on Windows with build systems
that define the required symbols. VS 2019 and later are known to work,
as well as current MSYS2 build systems (if configured appropriately).

The default is to include pen driver support, unless the required
symbols are not available on the build system. The latter is known to be
the case with old MinGW (32-bit) build systems from (no longer existent)
mingw.org. The cmake build will issue a warning if this is the case.

Please note that pen driver support is still in development and may not
work entirely as expected. Please report issues here or on GitHub.

CMake option FLTK_OPTION_PEN_SUPPORT=OFF can be used to disable pen
support if not needed or if the build doesn't work with pen support for
any reason. If this is the case, please file a bug report.

Any feedback would be appreciated. TIA.

[imm]

On Fri, 7 Aug 2026, 13:09 Oliver Bailey, wrote:

Hi Ian,

Thank you, you've given me insight and I'll try your work arounds.  This is for a client who wants VS compatibility,

This might not be feasible.

The MS C++ compiler uses a "proprietary" ABI that's basically incompatible with all the other compilers.

(The plain-C compilers can more or less inter-operate but the C++ not.)

The llvm & intel icc compilers do (I believe) have an MS compatibility mode, but gcc does not, so that may constrain your compiler options.

Llvm in MS mode might be an option. And using the ucrt runtime... Or maybe icc, but probably not gcc.

GNU freedom from VS, and the target platform is a Windows 11 Tablet that uses a pen.  Jackpot!  One of the biggest issues with MinGW is how many different "MinGW" branded toolchains there are.  And that is a rabbit hole all its own. I will try your Msys2/mingw64 suggestion.  Microsoft isn't helping with where they are trying to take Windows either.  I'll give these a try and report back.  

Thank you so very much.

Oliver

--

Ian

From my Fairphone FP6

[Oliver Bailey]

Hi Ian,

Thanks for the insight on the feasibility of gaining freedom from Microsoft libraries.  If I were at liberty to discuss that further, I would love to share.  But, my experiences, relationships, and tenure with the industry and aforementioned parties prevents me from too much public comment.  Given our brief exchanges over the past few days, I a pretty certain you understand my position. 

Thank you as always,

Oliver

.  

--
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 visit https://groups.google.com/d/msgid/fltkgeneral/CAGFM6dZhb8vuNRrwj35oJ6%2Ba459ryBJOOw1Rs1hj1mdw8wFyfQ%40mail.gmail.com.