Build windows msys2

[Francois Arrona]

Hi, all.

I'm trying to build fltk on a windows machine with msys2 and mingw64.

When I run ./configure, it stops on error : cannot find requested X11 libs.

I used pacman to install mingw-...-tk tools which install what I supposed the configure needed, but it still fails.

What is missing and how can I install it ?

Thanks

[Greg Ercolano]

    For fltk 1.4.x I've been using cmake to build FLTK on Windows with msys2/mingw.

    Here's some instructions I reposted in September 2020 of something I posted
    on coredev back in June.

    In particular step 6 shows how to build with cmake, which assumes
    cmake was installed w/pacman; if not see step 5 for the mingw/cmake install instructions.

---

Subject: Re: [fltk.general] Configure error when installing FLTK 1.4 on Windows/Mingw
From: Greg Ercolano <er...@seriss.com>
Date: Fri, 4 Sep 2020 10:51:40 -0700

[..]

   1. Started with https://www.msys2.org/
      Download and run the .exe, which guides you through a simple GUI wizard installation.
      You end up with a c:\msys64 directory once installed.

   2. Open a mingw64 shell window from DOS, e.g.

      cd \msys64
      mingw64.exe

   3. Inside the new shell that opens, get the latest updates by running:

      pacman -Syu        # -S=sync, -y=refresh pkg dbase, -u=upgrades out of date pkgs,

   4. The above step may close the shell window you opened as part of the updating process.
      Docs say to open the window again, and this time run:

      pacman -Su

   5. Now install man, vim, the 64bit compiler, make, man, and cmake for mingw:

      pacman -S man
      pacman -S vim
      pacman -S mingw-w64-x86_64-gcc
      pacman -S mingw-w64-x86_64-cmake
      pacman -S make

      Installing man is optional, but useful for 'man pacman'.
      Installing vim is optional, but it's useful to have a console editor of some kind.

   6. With this installed, one should be able to run cmake to build fltk the usual way:

      cd /c/fltk-1.4.x-git
      mkdir build-mingw64
      cd build-mingw64
      /mingw64/bin/cmake -G "Unix Makefiles" ..
      make

      My result was a nice colorful progress and no errors.

      Please note the ".." at the end of the cmake command is literal, and not an elipsis.
      You can add other flags to the cmake command to affect the build of FLTK; see the
      README.CMake.txt docs for more about that.

---

[Francois Arrona]

Hi,

Thanks for your answer.

I tried a lot of different configurations.

First of all, I tried cmake on the folder where fltk sources were installed. It has generated all libs libfltk.a, libfltk_images.a, libfltk_forms.a, ...

But none of them were usable for link with my application : undefined reference of new (or sometimes delete) operator.

Thus, I remove everything and tried your tutorial. Install a new msys2 env. as described, Download the fltk sources and launch cmake.

But I can't configure the compiler. Neither with an export CC=/mingw64/bin/gcc.exe and CXX=/mingw64/bin/g++.exe nor in the CMakeList.txt file.

/mingw64/bin/cmake don't find it...

So, I have no ideas :(

[Francois Arrona]

Hi, Greg.

This morning I decided to restart for scratch. I found a tuto on cmake.

Thus, I suppressed mingw fltk and reload it.

Finally I built a lib I could compile with using code::block.

Everything is almost OK. It remains a small problem I can't fix.

The native application built by C::B in debug mode works well when launched from Windows.

It cannot runs correctly when launched by C::B. Strange behaviour isn't it ?

The main program creates a window with 4 buttons, and then launch some modules initialization and enter fltk main loop.

When on debug under C::B, it never returns from the fl::show() call.

    Fl_Window *fen = new Fl_Window(250, 180, "Campay");

    Fl_Button *CB_Reserver = new Fl_Button(10,10,230,30, "Nouvelle Résa");
    Fl_Button *CB_Payer = new Fl_Button(10,50,230,30, "Régler une Résa");
    Fl_Button *CB_Gerer = new Fl_Button(10,90,230,30, "Gérer l'historique");
    Fl_Button *CB_Tarif = new Fl_Button(10,130,230,30, "Gérer les tarifs");

    cb_data_type cb_data;
    CB_Reserver->callback(res_callback, &cb_data);
    CB_Tarif->callback(tar_callback, &cb_data);

    /***** mode modules initi */
.../...

    fen->end();
    fen->show(argc, argv);

    return Fl::run();

The behaviour is the same if I remove all my specific project's code and only do a new on Fl_Window, on one button and that's all.

The debug target runs launched from Windows and not from Code::Block on debug.

---

[Greg Ercolano]

On 3/17/21 11:20 PM, Francois Arrona wrote:

The native application built by C::B in debug mode works well when launched from Windows.

It cannot runs correctly when launched by C::B. Strange behaviour isn't it ?

[..] When on debug under C::B, it never returns from the fl::show() call.

    Hmm, if you're in CodeBlocks debug mode and the code gets "stuck" in fen->show() call,
    check if you accidentally set a stray "breakpoint" or "stop" for that line of code,
    as I can't offhand think of a reason show() would not return, as it doesn't actually show
    the window, just sets some flags for it to be shown.. the actual action of opening the
    window should be handled deep in the application loop, Fl::run().

[Francois Arrona]

Yeah, I understand what you mean. I checked and found no breakpoint on C::B (it does not mean there's no breakpoint, but the IDE don't show them).

I faced another problem :  the generated application does not start on a windows 7. It has been generated on Windows 10.

Thus I installed C::B, mingw64, and fltk sources on the 7 machine and try to build it. Building fltk was done. So, I used C::B for my app.

Unforunately, it is not same C::B release than previous machine, and the IDE blocks on strange message, with no source line number. As if it is the script file launched by IDE to compile which has a problem.

I decided to give up code:block for better understanding, and build manually launching mingw64-g++ manually in a command prompt.

The new code works fine on the 7 machine, but not on windows 10...

Maybe I'm wrong but I thought binaries built on windows were compatible. How to make an fltk app runnig on all machines from Windows 7 to upper release ?

[Ian MacArthur]

On 19 Mar 2021, at 05:51, Francois Arrona wrote:
>
> I faced another problem : the generated application does not start on a windows 7. It has been generated on Windows 10.

OK... that’s not normal, there *must* be something wrong with the build environment... 64-bit Windows apps will *only* run on 64-bit machines, but Win7 & Win10 are effectively interchangeable otherwise.
32-bit Windows apps. will generally run on *any* Windows version back to about Win2k...

When you say the application does not start on Win7, what does happen?
What error messages do you get if any?
Are you trying to launch the application by clicking on it in Explorer, or are you launching it from the CLI?

If you launch by double-clocking, Windows has a tendency to “eat” error and diagnostic messages, so it make sit look like the app simply doe snot respond - if you laugh it form the Msys shell, you should get the diagnostic either as pop-ups or at least printed to the shell.

Tell us what you see in that case, as it may be informative.

My only guess is that the mingw compiler you are using is a version that needs the libgcc ad libstdc++ libs to be explicitly linked statically for portability between machines, but that’s just a guess...

> Thus I installed C::B, mingw64, and fltk sources on the 7 machine and try to build it. Building fltk was done. So, I used C::B for my app.
> Unforunately, it is not same C::B release than previous machine, and the IDE blocks on strange message, with no source line number. As if it is the script file launched by IDE to compile which has a problem.
> I decided to give up code:block for better understanding, and build manually launching mingw64-g++ manually in a command prompt.
> The new code works fine on the 7 machine, but not on windows 10...

I pretty much always use the mingw tools at the shell in an Msys shell, and it has always Just Worked, and the code has always been portable between machines without issues.
The fact that it does not for you is very surprising, so something must be awry in your configuration - but I have No Idea what! Sorry.

>
> Maybe I'm wrong but I thought binaries built on windows were compatible. How to make an fltk app runnig on all machines from Windows 7 to upper release ?

See above, but yes - this ought to work...

[Albrecht Schlosser]

On 3/19/21 11:56 PM Ian MacArthur wrote:
> On 19 Mar 2021, at 05:51, Francois Arrona wrote:
>>
>> I faced another problem : the generated application does not start on a windows 7. It has been generated on Windows 10.
>
> OK... that’s not normal, there *must* be something wrong with the build environment... 64-bit Windows apps will *only* run on 64-bit machines, but Win7 & Win10 are effectively interchangeable otherwise.
> 32-bit Windows apps. will generally run on *any* Windows version back to about Win2k...
>
> When you say the application does not start on Win7, what does happen?
> What error messages do you get if any?
> Are you trying to launch the application by clicking on it in Explorer, or are you launching it from the CLI?
>
> If you launch by double-clocking, Windows has a tendency to “eat” error and diagnostic messages, so it make sit look like the app simply doe snot respond - if you laugh it form the Msys shell, you should get the diagnostic either as pop-ups or at least printed to the shell.

My latest experience on windows 10 is that launching an app from the
explorer does indeed show an error popup that says that a dll could not
be loaded if that's the case. If you are lucky it does even tell you
which one.

> Tell us what you see in that case, as it may be informative.

Yes, please!

> My only guess is that the mingw compiler you are using is a version that needs the libgcc ad libstdc++ libs to be explicitly linked statically for portability between machines, but that’s just a guess...

Yep, and the OP also said that his own app could not start. Depending on
the msys version it's possible that it uses image libs (png, jpeg) or
libz as a shared lib if it's available on the system. This could also
lead to a missing dll.

To the OP: In such case the program can be launched from inside the
build environment (mingw/msys shell) but likely not from the explorer -
unless the msys/mingw paths have been added to the system PATH
environment variable.

[Francois Arrona]

Finally, I decided to

- rebuild from scratch fltk with mingw64 running in a command.com shell

- rebuild the Haru lib I also use in same way

- rebuild my app in same way and link libharu and fltk as static .a

and now, app works on all machines I tried. For some it asks libs like libwinpthread, libs concerned by exceptions and so on (3 libs has been asked by a popup at launch time). But not for all machines.

It seems ok.

The message can be closed. Thanks to Albert, Greg and Ian for support.

--

François