Recent commit in Fl_Help_View.H by Matt introduces problems with some compilers

[Gonzalo Garramuño]

I'm writing this away from my computer, but the problem was the use of:

std::list<std::shared_ptr<something>> var;

It should be for proper C++:

std::list<std::shared_ptr<something> > var;

--
ggar...@gmail.com

[melcher....@googlemail.com]

Done. Thanks.

Is there still a c++ compiler out there that does not understand this? Sigh ;-)

[Gonzalo Garramulo]

El 5/7/25 a las 10:30, 'melcher....@googlemail.com' via fltk.coredev
escribió:

> Done. Thanks.
>
> Is there still a c++ compiler out there that does not understand this?
> Sigh ;-)

macOS /usr/bin/cc.

I am afraid your latest (large) fluid commit was really problematic in
terms of backwards compatibility, too.

On Linux, I get even more errors on RH compatible systems using the scl
toolchain like:

/opt/rh/gcc-toolset-13/root/usr/libexec/gcc/x86_64-redhat-linux/13/ld:
fluid/CMakeFiles/fluid-lib.dir/nodes/Function_Node.cxx.o:(.data.rel.ro._ZTI14CodeBlock_Node[_ZTI14CodeBlock_Node]+0x0):
referencia a `vtable for __cxxabiv1::__si_class_type_info' sin definir

I thought you guys (developers) had the equivalent of github actions (I
thought Albrecht mentioned it once) to test compilation on several systems.


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

[Gonzalo Garramulo]

El 5/7/25 a las 16:42, Gonzalo Garramulo escribió:

>
> On Linux, I get even more errors on RH compatible systems using the
> scl toolchain like:
>
> /opt/rh/gcc-toolset-13/root/usr/libexec/gcc/x86_64-redhat-linux/13/ld:
> fluid/CMakeFiles/fluid-lib.dir/nodes/Function_Node.cxx.o:(.data.rel.ro._ZTI14CodeBlock_Node[_ZTI14CodeBlock_Node]+0x0):
> referencia a `vtable for __cxxabiv1::__si_class_type_info' sin definir
>
> I thought you guys (developers) had the equivalent of github actions
> (I thought Albrecht mentioned it once) to test compilation on several
> systems.

Actually, let me take that back.  I think this may be a problem on my
end.  I'm checking.

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

[melcher....@googlemail.com]

Thanks for checking, Gonzalo. The very latest and working commit is 2a1677802fe68a9745e9ab6b2dcbeb515e50886c . And fa22585bbb0c0674c9f154120d274be9d7d10084 was the last commit before removing the internal workings from the header file. 

I have not changed the public API except for the order in which methods are listed in the header. I did remove include statement in the header that I no longer need,, but restored them because external apps relied on them. Bad style, but what can you do.

Please let me know if I modified anything that breaks your code, and how we can restore that. 

Oh, and yes, we compile ofr X11, Wayland, macOS, and Windows with every commit. Due to some bugs, three commits did not compile all the way through, but everything should be fine by now.

 - Matthias

[melcher....@googlemail.com]

PS: reason for the reorganization was a Fl_Help_View that was missing comments and features, and became increasingly unmanageable. By replacing quite number of fixed size arrays with modern C++ containers, I hope to have improved the widget and its maintainability. But as always, let me know your concerns.

[Gonzalo Garramuño]

Using the latest version of macOS clang on my macOS Intel I ran into
linker (not compile) errors which would have been extremely painful to
debug with cmake.  That was why I reverted to a previous clang version
and switched to using /usr/bin/cc instead for the time being.

Another issue was the removal of compilation of fl_ask() by default.  As
swig's bindings for 1.4 are still unaware of that, you end up with a
broken pyFLTK if building against 1.5.

I'll give it another go probably tomorrow to see if it was some mistake
on my part or Apple is not only deprecating its OpenGL support but
*also* its compile ABI too.

--
ggar...@gmail.com

[melcher....@googlemail.com]

ggar...@gmail.com schrieb am Sonntag, 6. Juli 2025 um 01:41:42 UTC+2:

Using the latest version of macOS clang on my macOS Intel I ran into 
linker (not compile) errors which would have been extremely painful to 
debug with cmake.  That was why I reverted to a previous clang version 
and switched to using /usr/bin/cc instead for the time being.

Ok, interesting. You mentioned the changes to Fluid which were very minimal, but added another source file. If your build system doe not add `fluid/proj/i18n.cpp`, you will get linker errors. The current CMake setup includes this file.

 

Another issue was the removal of compilation of fl_ask() by default.

Yeah, maybe we should have kept the API and added fl_ask() with two additional string arguments for "yes" and "no". If this is a real issue, I will discuss it with Albrecht.

 

I'll give it another go probably tomorrow to see if it was some mistake 
on my part or Apple is not only deprecating its OpenGL support but 
*also* its compile ABI too. 

For us, OpenGL still seems  to be fine on macOS. Worst case, we keep Mesa in mind. So if Apple really thinks it must drop OpenGL, we may need to bundle or at least link somehow to Mesa to keep old apps running. 

OTOH, Vulkan support will be great. I did not have time yet to wrap my head around Vulkan, but I am hoping to do so soon to get the widget in.

[Albrecht Schlosser]

On 7/5/25 21:42 Gonzalo Garramulo wrote:
>
> On Linux, I get even more errors on RH compatible systems using the
> scl toolchain like:

What is the "scl toolchain"? Are you sure it supports C++11 ?

> /opt/rh/gcc-toolset-13/root/usr/libexec/gcc/x86_64-redhat-linux/13/ld:
> fluid/CMakeFiles/fluid-lib.dir/nodes/Function_Node.cxx.o:(.data.rel.ro._ZTI14CodeBlock_Node[_ZTI14CodeBlock_Node]+0x0):
> referencia a `vtable for __cxxabiv1::__si_class_type_info' sin definir

BTW, if you want to post error messages, please select locale `C` before
compilation so we get English error messages. TIA.

> I thought you guys (developers) had the equivalent of github actions
> (I thought Albrecht mentioned it once) to test compilation on several
> systems.

To clarify: a long time ago we used a few selected systems for build
tests. Nowadays we use GitHub Actions and GitLab for CI (build tests).

We can't find issues with other (maybe non-compliant) build systems
automatically.

[Albrecht Schlosser]

On 7/6/25 01:41 Gonzalo Garramuño wrote:

Another issue was the removal of compilation of fl_ask() by default.  As swig's bindings for 1.4 are still unaware of that, you end up with a broken pyFLTK if building against 1.5.

Then swig should be updated for 1.5, shouldn't it?  ;-)

Seriously, this is maybe a point, but - citing a comment in the source code:

```

// Note to FLTK developers: fl_ask() had been deprecated since FLTK 1.1.7
// (released Jan 17, 2006 !) but was still available in FLTK 1.4.x.
// FLTK 1.5 disables it by using an *undocumented* preprocessor macro.
// This allows us to restore it (as a last resort) if there are too many
// complaints that fl_ask() is missing. If users don't complain, the
// conditional implementation of fl_ask() should be removed in FLTK 1.6.

```

This means:

1. fl_ask() has been deprecated more than 19 years ago. At some time we definitely need to remove deprecated methods, although we try not to do this too often.

2. Restoration of fl_ask() is an undocumented feature for a reason. Users should *NOT* restore it by defining the respective macro (w/o an official report), otherwise it will be removed in 1.6 anyway and make their code uncompileable.

3. I anticipated that some users might still use it, and that's why I didn't remove it entirely now, but I hope we don't need to restore it.

4. Bindings like pyFLTK (Python) or fltk-rs (Rust) could implement their own fl_ask() equivalent by utilizing another non-deprecated method. However, this is not recommended.

[Gonzalo Garramuño]

El 6/7/25 a las 12:02, 'Albrecht Schlosser' via fltk.coredev escribió:

> What is the "scl toolchain"? Are you sure it supports C++11 ?

Yes.  scl toolchain is not actual toolchain but an environment setup on
RH systems (which, they seem to have found a loophole in the GPL and
keep it proprietary).  You might need to google it up.  It allows using
newer compilers with old system libs like libm, libstdc++, libc, etc. 
It mainly solves one of Linux headaches: distributing binaries for
multiple architectures.

--
ggar...@gmail.com