Problem with Windows development

[david allen]

I'm making plans to port my project to Windows. I installed Msys2. It uses the Arch Linux package system. I installed the compiler package and successively compiled and ran a small program. I installed packages for cairo, GSL, and FLTK. However, I got a "program not found" message when attempting to run fltk-config. I am wondering if others have followed this path for developing on Windows and have any suggestions for what might be my problem.

[pvr...@btinternet.com]

Hi David,

FWIW, I use MSVC. I clone the FLTK github and then it's almost a matter of building it. This requires FLTK at least 1.40 with CMake support.

When compiling my app, I have to be careful about getting all the dependencies OK. As it's been some time since I built an app from scratch, I don't know if its possible to use fltk-config to configure my solution in MSVC.

Regards

Phil Rose

---

From: fltkg...@googlegroups.com <fltkg...@googlegroups.com> on behalf of david allen <texju...@gmail.com>
Sent: Thursday, June 19, 2025 4:06 PM
To: fltk.general <fltkg...@googlegroups.com>
Subject: [fltk.general] Problem with Windows development

 

I'm making plans to port my project to Windows. I installed Msys2. It uses the Arch Linux package system. I installed the compiler package and successively compiled and ran a small program. I installed packages for cairo, GSL, and FLTK. However, I got a "program not found" message when attempting to run fltk-config. I am wondering if others have followed this path for developing on Windows and have any suggestions for what might be my problem.

--
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/d794e608-dc6a-4f0e-8607-bf986923aadfn%40googlegroups.com.

[Gonzalo Garramuño]

El 19/6/25 a las 12:06, david allen escribió:

Albrecht is probably a better source to answer this, since he does a lot
of MingW compilation and maintains the CMake's port but I'll pitch in.

If you are developing your application on Windows with FLTK, you are
usually better sticking to Windows native compilers (MSVC or Clang --
both come with Microsoft's developing environment) and use fltk's
fl_draw.H calls to draw.  FLTK will translate drawing to Microsoft's
GDI+ API calls on Windows, cairo on Unix systems and Cocoa on macOS. 
That will give you the absolute best performance on every (common)
platform.  I understand using FLTK like that also allows you to run it
on less common platforms like BSD or ReactOS, but I have not personally
verified that myself.

However, if you are dealing with legacy code or are a security conscious
person you might want to ask Cyprinus Carpio --the newest guy to the
FLTK mailing list-- for advice besides Albrecht.  He is familiar with
several virtual machines and Arch Linux ports.  Cyprinus is without a
job right now so he should probably charge you a fee for his knowledge
and to get new hardware.  In case you care, he states in his github bio
he's from Poland, the land of the great film director Kieslowski, btw.

--
Gonzalo Garramuño
ggar...@gmail.com

[Ian MacArthur]

On Thursday, 19 June 2025 at 16:06:04 UTC+1 David wrote:

I'm making plans to port my project to Windows. I installed Msys2. It uses the Arch Linux package system. I installed the compiler package and successively compiled and ran a small program. I installed packages for cairo, GSL, and FLTK. However, I got a "program not found" message when attempting to run fltk-config. I am wondering if others have followed this path for developing on Windows and have any suggestions for what might be my problem.

David,

Despite Gonzalo's reservations, I'm "keen" on the Msys/mingw approach. I find it much more consistent (and portable) than the MSVC tools (though recent versions of cl are "better", the older versions had very idiosyncratic attitudes to my code...)

Anyway, since I generally have _many_ versions of FLTK on the go (and often several different compilers...) what I tend to do is stick a shell script in the "usr/bin" folder as seen by the Msys or Msys2 shell.

Ok, just checked, on this particular machine I have the following scripts:

fltk-config    - invokes the fltk-config of my current fltk-1.5 32-bit build

fltk-config-1.4  - invokes the fltk-config of my current fltk-1.4  build

fltk-config64    - invokes the fltk-config of my current fltk-1.5 64-bit build

fluid     - invokes fluid

So each script is like this: (this is fltk-config-1.4 FWIW)

#!/bin/sh
/d/Support/fltk-1.4/build-32/fltk-config $@

So with that, if I type "fltk-config --compile blah.cxx" it does the build using my current fltk-1.5 32-bit build, or "fltk-config64 --compile blah.cxx" does the 64-bit build, and so forth...

Works for me, at any rate!

[Gonzalo Garramuño]

El 19/6/25 a las 13:26, Ian MacArthur escribió:

> Despite Gonzalo's reservations, I'm "keen" on the Msys/mingw approach.
> I find it much more consistent (and portable) than the MSVC tools
> (though recent versions of cl are "better", the older versions had
> very idiosyncratic attitudes to my code...)

I had forgotten about you, Ian!  Sorry.  Thanks for pitching in. The
problem with your approach is that if the user has a large code base
fltk-config is kind of useless.  And autoconf is being deprecated in the
fltk1.5 branch so building around that toolchain is *probably* no longer
a good idea.
I understand your experience is mainly with kiosks and raspberry pi's,
so as usual, YMMV.

If you actually hate cmake and are not depending on that many external
libraries that use it, I would build my tool with premake, these days.


--
Gonzalo Garramuño
ggar...@gmail.com

[Ian MacArthur]

On Thursday, 19 June 2025 at 17:58:31 UTC+1 Gonzalo wrote:

El 19/6/25 a las 13:26, Ian MacArthur escribió:
> Despite Gonzalo's reservations, I'm "keen" on the Msys/mingw approach.
> I find it much more consistent (and portable) than the MSVC tools
> (though recent versions of cl are "better", the older versions had
> very idiosyncratic attitudes to my code...)

I had forgotten about you, Ian!  Sorry.  Thanks for pitching in. The
problem with your approach is that if the user has a large code base
fltk-config is kind of useless. 

No, not at all - I use it a lot in my Makefiles to provide "portability" across host platforms, and it works really well. Indeed, I even did a HowTo about it some time in the dim and distant past (2006 apparently) and it still works to this day... https://www.fltk.org/articles.php?L599

 

And autoconf is being deprecated in the
fltk1.5 branch so building around that toolchain is *probably* no longer
a good idea.

Note that cmake still generates the fltk-config script for each build target you set up, so my scheme still works.

I concede that cmake is handy for doing multiple different builds of one FLTK repo though, which was always harder with autoconf...

I understand your experience is mainly with kiosks and raspberry pi's,
so as usual, YMMV.

Technically my experience is embedded, which probably explains why I always have a strange mixture of obscure and ancient compilers around.

It also explains my "disdain" for cmake.

I do *a lot* of cross-compilation, naturally, often using "strange" toolchains.

Now, cmake has "good" support for cross-compilation - IF your host and your targets are tings that cmake "knows" about (it brings quite a lot of "built-in knowledge"  with it, to ease the task.)

Unfortunately, that very same "built-in knowledge" can make is insanely difficult to cross-compile for obscure combinations that don't work the way cmake "expects", whereas a simple, old-fashioned Makefile just does what you tell it. (Exactly what you tell it, of course, which is often not quite what you meant, but...)

So for my desktop work, cmake is fine, and that's how I would choose to build FLTK now, but for stuff I'm building to work across platforms portably, Makefile and fltk-config is still the easy win for me.

As regards the R-Pi - yeah, they are very good, you can do a lot with an R-Pi, though for my more recent hobby work, I've been using a lot more RasPi Pico and Pico-style boards.

Great little boards, cheap, good tooling, lots of usable i/o and even the PIO which is just like having your own tiny wee FPGA on the board. Buy one, they're great. Indeed, but ten, they are so cheap!

 

If you actually hate cmake and are not depending on that many external
libraries that use it, I would build my tool with premake, these days.

I don't hate it, I just find it makes my job harder, not easier, so I choose to avoid it except where it actually helps. My Pico projects I usually build with cmake for example, since the tooling is set-up that way, and there's usually only one target, so it Just Works.

But for more complex targets, Makefiles every time...

 

[david allen]

Thanks for all the suggestions and discussion. I found my answer in Greg's post in <https://groups.google.com/g/fltkgeneral/c/Buhe9zeA2YA>.

I still have questions about Msys2. For example, what does the fltk pacman package do? But these can wait.

[Mohammed]

Msys2 comes with multiple environments: MSYS, MINGW64, UCRT64, CLANG64. Apart from the first, they’re used for native windows dev (i.e they don’t link the cygwin shim library). 

When you install a package, you’ll have to specify for which environment you’re developing. Default packages (those lacking an environment prefix), are ok for working just in the msys2 shell and will become universally available for any environment. Those are packages like git and a command line editor. For packages used for native dev, you’ll have to specify the environment prefix to install them. Then to use them normally you’ll have to access the environment you installed them in. 

If you go to the msys64 directory on your pc, you’ll see them listed the ucrt64, clang64, ming64. Or from an msys2 shell, type `source shell ucrt64`. This will enable you to access fltk-config if you’ve installed the ucrt64 fltk package for example. 

Another workflow you can use, once in the msys2 shell:

source shell ucrt64

pacman -S $MINGW_PACKAGE_PREFIX-fltk

fltk-config —api-version

Sent from my iPhone

On 21 Jun 2025, at 02:28, david allen <texju...@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/fb29a616-9def-4ab6-b871-e254e7d4e5d9n%40googlegroups.com.

[Gonzalo Garramuño]

El 21/6/25 a las 06:14, Mohammed escribió:

> Msys2 comes with multiple environments: MSYS, MINGW64, UCRT64,
> CLANG64. Apart from the first, they’re used for native windows dev
> (i.e they don’t link the cygwin shim library).

What's the difference between MINGW64 and UCRT64?

--
ggar...@gmail.com

[Mohammed]

The difference between environments is in the linked c and c++ libraries.
ucrt64 links libucrt and libstdc++.
mingw64 links msvcrt and libstdc++.
clang64 links libucrt and libc++.

Sent from my iPhone

> On 21 Jun 2025, at 15:09, Gonzalo Garramuño <ggar...@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/2f0f8ad7-949d-4064-876d-cdb8025f7752%40gmail.com.

[imm]

On Sat, 21 Jun 2025, 13:47 Mo wrote:

The difference between environments is in the linked c and c++ libraries.
ucrt64 links libucrt and libstdc++.
mingw64 links msvcrt and libstdc++.
clang64 links libucrt and libc++.

As an addendum to what Mo wrote, I'd note that I generally go the msvcrt route myself. I fondly imagine (albeit on sparse evidence) that it's more portable moving exe's from machine to machine.

As regards the C++ lib options, that's a bit more "open". Until fairly recently MS were changing (breaking) their own C++ ABI with each new compiler release, and in any case their C++ ABI is incompatible with just about everyone else anyway, so trying to link to the "native" MS C++ lib is a lost cause.

FWIW I generally link libstdc++, and generally link it static, so I don't need to worry about it not finding the lib if moved to a different machine.

The "plain-C" libs generally have compatible ABI so that's usually less of an issue.... (In effect the C-standard defines how symbols are named, exposed, etc. so most libs "look" the same. The C++ standards don't do that, so as a result the C++ libs are much less compatible. Which is a pity, makes my job harder a lot of the time...)
--
Ian
From my Fairphone FP3

[Mohammed]

msvcrt is indeed more portable. It can target older versions of windows, similarly the mingw toolchains available in Linux for cross-compilation to windows targets msvcrt. 

The msys2 project however seems to want to push developers towards ucrt64 since modern versions of windows target ucrt by default, so you get better interop with newer shared libraries. 

So there are tradeoff whichever environment one chooses. 

Sent from my iPhone

On 21 Jun 2025, at 17:35, imm <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/CAGFM6dbVM%2BwSZEzH1xai34g2MBDY%3D8MUKwmhOtFy3zij4pmR%3DA%40mail.gmail.com.

[Albrecht Schlosser]

On 6/19/25 17:32 Gonzalo Garramuño wrote:
>
> El 19/6/25 a las 12:06, david allen escribió:
>> I'm making plans to port my project to Windows. I installed Msys2. It
>> uses the Arch Linux package system. I installed the compiler package
>> and successively compiled and ran a small program. I installed
>> packages for cairo, GSL, and FLTK. However, I got a "program not
>> found" message when attempting to run fltk-config. I am wondering if
>> others have followed this path for developing on Windows and have any
>> suggestions for what might be my problem.
>
> Albrecht is probably a better source to answer this, since he does a

> lot of MingW compilation and maintains the CMake's port ...

Almost everything I could have contributed has already been written by
Mohammed, but anyway:

Using MSVC, i.e. the MS compilers, can make deployment on other Windows
systems easier (once you got it working) because the built executables
typically don't have external dependencies.

The "classic" MinGW approach produces mostly compatible (32-bit)
executables, at least if you link libstdc++ and libgcc statically (see
e.g. README.CMake.txt and/or README.Windows.txt). However, as of today,
I believe that MinGW development has stalled (their websites are down or
"don't work"), but you can probably still download and install it from
sourceforge (https://sourceforge.net/projects/mingw/). Download a recent
(?) version of `mingw-get.exe` and launch it. This is the installer program.

MSYS2 is a newer version with many more options (see other replies).
It's very useful to build FLTK and your own executables, but programs
always seem to depend on some MSYS2 DLL's (in my experience). There are
ways to work around this, but it needs a little more effort. MSYS2 can
build 32-bit and 64-bit Windows executables. Runnig these executables on
the build system (under the correct MSYS2 environment) works fine, but
distributing them to other Windows systems may need some supporting
DLL's too.

Final notes: I don't recommend using the FLTK package provided by MSYS2.
I assume that programs built with these packages **may** depend on even
more MSYS2 DLL's - although I didn't test this. Feedback would be
appreciated. I also recommend to build FLTK and your own applications
with CMake for better cross-platform support - although I know that
others prefer using Makefiles for their apps. YMMV.