FLTK 1.3.6 Release Candidate 1 is now available for download and testing

[Albrecht Schlosser]

The first release candidate for FLTK 1.3.6 is now available for download and testing.

Please look for:

  fltk-1.3.6rc1-source.tar.gz

.. on the FLTK downloads page https://www.fltk.org/software.php

Please test and report bugs within 2 weeks (until May 10, 2021) if you find any issues with this release candidate.

Please see the following page on how to report bugs and issues:

  https://www.fltk.org/bugs.php

Note: Since problems reported on the FLTK newsgroups or mailing lists are *not* automatically entered as bug reports, it is imperative that you report any problems using a "GitHub Issue" as described in 'bugs.php' mentioned above.


For more information on this release please see this article:

  https://www.fltk.org/articles.php?L1749

[Albrecht Schlosser]

On 4/26/21 11:02 PM Remy Oukaour wrote:

> Excellent news! I built this on Windows 8.1 x64 with Visual Studio 2019,
> after adding #define FL_ABI_VERSION 10306 to abi-version.ide.
> The VisualC2010 projects were automatically upgraded
> <https://i.imgur.com/pzwWN3c.png> to the latest Windows SDK version and
> platform toolset, the Debug and Release configs built correctly, and
> building my own programs with the libraries hasn't found any bugs so
> far. (In particular, the issues from
> https://github.com/Rangi42/copy-paste-example
> <https://github.com/Rangi42/copy-paste-example> are resolved.)

Thank you very much for testing and the quick feedback!

> (Although I see that
> https://groups.google.com/g/fltkgeneral/c/SQ3RSqNgXbE/m/lIl2lnjdBQAJ
> <https://groups.google.com/g/fltkgeneral/c/SQ3RSqNgXbE/m/lIl2lnjdBQAJ>
> is not, even in fltk's 1.4.x master branch.)

Well, that's one of the things that may get forgotten if it's only
discussed in fltk.general. In such a case opening a GitHub issue would
be the best choice.

However, although I worked on a patch, after reading this thread again,
I must say: the VS compiler warning concerns the declaration of the
variable 'i' in the user program which is *formally* not FLTK's fault.
Basically it says that the declaration of 'i' in the user program is
"wrong" (not the FLTK variable it is shadowing). ;-)

But anyway, I opened issue #223 "Rename Fl_X* Fl_Window::i private class
member" so it won't be forgotten again.

[Albrecht Schlosser]

I forgot the link: https://github.com/fltk/fltk/issues/223

[Ian MacArthur]

Albrecht,

This one is a bit of an outlier report - I don't think there's anything with the R.C., rather this is about an odd interaction with my (known to be odd) build environment on Win10.

Specifically, after doing my usual tests (which seem to be fine, of course) I thought I'd have a go with the GLEW extension (someone was asking about support for "advanced" GL versions recently...)

So, I turned on the glew stuff in cmake (from cmake-gui, as it happens) and rebuilt. Now, I DO NOT have a working pkg-config in this build environment, and I believe our cmake uses pkg-config to find glew, so I didn't really expect this to work at all; so it was the way it didn't work that surprised me, really!

First off, the build failed because, when linking the glew examples, it could not locate libGLEW.a. The glew lib on mingw* is called libglew32.a (for both 32 or 64-bit builds) however, so it looks like we have asked for "the wrong" lib name. 

I copied libglew32.a to libGLEW.a and the build then found and linked the lib OK. 

However, the link failed for want of libopengl32.a in the link command. For the "normal" OpenGL examples, we do link "-lopengl32.a" correctly so this behaviour is peculiar to the glew targets. I tweaked the libs to ensure "-lopengl32.a" and thereafter the glew examples built and ran correctly.

Anyway, I assume these issues are all because I do not have pkg-config, but thought I'd flag them here just as a record of sorts, in case anyone else stumbles into this.

Tested with mingw32 and mingw64 targets.

FWIW: I also tried this on 1.4, and it behaves in the same way.

 

[Albrecht Schlosser]

On 4/28/21 8:19 PM Ian MacArthur wrote:
> Albrecht,
>
> This one is a bit of an outlier report - I don't think there's anything
> with the R.C., rather this is about an odd interaction with my (known to
> be odd) build environment on Win10.

Ian, can you please open a GitHub Issue for this report so it doesn't
get lost in the noise? I'm too busy now but I think this is worth
further investigation.

Please anser this on the GitHub issue page:

Which build environment is it exactly? If MinGW (which I assume), which
flavor (original MinGW, MSYS2, anything else)?