Hi,

I spend few evenings creating bindings for CFLTK / FLTK. It is not only call H2Pas but made own converter tool which convert macros as flatten C methods and do a lot of stuff.

Description: FLTK is very lightweight multiplatform GUI written in C++. It doesn't use Qt / GTK / WinCtrls in backend but pure X11 / GDI. It is similar to our fpGUI / MSEGUI for Free Pascal.

Link to repo: https://github.com/dibok/PasFLTK

I need some testers for windows and macos because I'm not able do it by my self for now.

I have also question for FPC guru here. Please see section "Other static linking options". I have trouble there. Is there correct way to link *.a libs (even written in C++) so there is no need to deploy libcfltk.so / libfltk.so?

In short. Structure looks like that:

FPC headers -> cfltk lib (C wrapper) -> fltk lib (C++)

I used GDB to debug these libs and noticed that the main problem which cause this SIGSEGV is related to some kind different initialization order of C++ classes. For example:

Class A {

public:

   *char get_filesystem_label();

}

Class B {

static const *char somelabel = A::get_filesystem_label();

}

Demo is running but has SIGSEGV in some particular places. In FPC demo, seems like C++ class B is initializated first before A so const somelabel contain empty value (NULL in fact). But the same demo written in C works fine. Even ldd command shows that both my demo and C demo has linked the same libs in the same order. I didn't debug deeper but I think that method in class A is using some X11 routine, so maybe FPC demo should call some init from linked X11 first? But C demo doesn't call anything like that. I have also tried compiler option --whole-archive with no result. I looked at other bindings for FLTK and for example Rust is generating one single small executable without needing libcfltk.so / libfltk.so so it is probably linking *.a libs. It would be great if FPC could do that too.

Regards

Version 1.5.23.3 with experimental static linking. There is an issue which I could not solve. If there is FPC guru and could help me, please see section "Building project using PasFLTK and static libs (experimental with not solved bugs)" in the main page (README.md). I have also prepared demo which point to SIGSEGV error

Version 1.5.23.4. Finally solved issues with static linking. It turned out that FPC while linking doesn't call everything as g++ call while linking. I had to write patch. Does anyone know why it is needed and why FPC doesn't call this by default? This is a code which I need to call in my bindings at first thing before anything else:

{$IFNDEF USE_FLTK_SHARED_LIBS}
{$IFDEF LINUX}
type
   TCtorProc = procedure(); cdecl;
   PCtorProc = ^TCtorProc;
var
   __init_array_start: Byte; external name '__init_array_start';
   __init_array_end: Byte; external name '__init_array_end';
procedure RunCppGlobalConstructors;
var
   p, pend: PCtorProc;
begin
   p := PCtorProc(@__init_array_start);
   pend := PCtorProc(@__init_array_end);
   while p < pend do
   begin
     if Assigned(p^) then
       p^();
     Inc(p);
   end;
end;
{$ENDIF}
{$ENDIF}
(* ====== *)
(* === Added / Modified by cfltk2pas === *)
initialization
   {$IFNDEF USE_FLTK_SHARED_LIBS}
   {$IFDEF LINUX}
   RunCppGlobalConstructors;
   {$ENDIF}
   {$ENDIF}
(* ====== *)

W dniu 22.06.2026 o 10:13, Dibo via fpc-pascal pisze:

FPC does not really support linking to C++ libraries. The usual mechanism is to write a C library that sits between FPC/C++, which handles initialization.

Probably there will be other initialization routines that must be called, you will likely discover them one by one, whenever a new widget is used that needs one.

Michael.

Yes, and that is how it works now. FPC call libcfltk (flatten C - the base for all bindings in other languages) which then call libfltk (C++). The difference is that when linking *.a libs, method "__init_array_start" is not called but it is called in case of *.dll. I worked with this with Claude AI which finally found solution by analyzing binary ELF and how linkers work in other languages. A lot of low level technic speach which I don't understand but in short, he found differences between gcc and rust and FPC linkers. FPC linking is just a proxy which generate linkXXXX.res map where ".init_array" is not filled and this array is later called by "_start" from "__libc_start_main". I'm porting now some app on PasFLTK and I don't see any other errors after made this patch, seems like only this stage of init globals was missing and later C is initializing C++ constructors fine

In fact, FLTK and CLTK are written specifically for static linking for bindings (licence allow that), they solved  "Static Initialization Order Fiasco" in the code