Can arbitrary C++ compilers use each other's classes? lazarus / 64-FPC development ---------------------------------------------------------------------- valdir.marcos · 2026-03-26 02:51 Debian 14 will drop Gtk2 – unless Ardour rides to the rescue https://forums.theregister.com/forum/all/2026/02/26/debian_14_will_dro p_gtk2/ QuoteDebian 14 will drop Gtk2 – unless Ardour rides to the rescue Version 2 of the widely used Gtk toolkit will be dropped from the next Debian release. The problem is that many things still need it, including FreePascal and its Lazarus IDE. Debian 14, codenamed "Forky," is in development and will very probably be released in about 18 months. As with any new release, the developers are … COMMENTS     28 days     MarkMLl     Free Pascal Compiler and the Lazarus IDE     My understanding is that the FPC issue (that it has precompiled units which support the GTK2 developer libraries) and the Lazarus IDE issue (that on Linux its preferred widget set is still GTK2) are distinct.     The FPC issue appears to have been resolved. It wasn't strictly a problem of the FPC project itself, but appears to have been caused by a combination of Debian policy and a (possibly automatic) checking procedure which refused to believe that a development tool which fully-supports separate compilation didn't require the libraries for everything it referenced (i.e. not just GTK2, but standards like libusb where the compiler etc. is entirely happy if the underlying libraries aren't present).     I also believe that the maintainers of the Lazarus IDE for Debian have resolved the matter by having separate support packages for the various widget sets.     28 days     Doctor Syntax     Qt is an option for Lazarus. However I wonder if it's better to regard projects such as GTk2 as not dead but "complete". Does sofware have to be in continuous development once it's good enough?         27 days         MarkMLl         Qt generally works well, but needs a special shim library since FPC has the feature (ardently defended by some if its developers) that it can't interwork directly with code that uses C++ classes etc.             19 days             MarcoV             I didn't know C++ classes (VMT layout etc?) were standarized. Did I miss something in more recent standards?             Can arbitrary C++ compilers use each other's classes?                                                       Quote from: MarkMLl on March 07, 2026, 10:40:26 pmQuote from: robert rozee on March 07, 2026, 03:25:58 pmi was not aware of this C++ issue. Mark - are you able to expand more on this outside of the thread? i would very much like to be able to statically bind libQt5Pas into a lazarus-created ELF binary, if it were possible.I'd much rather not spend more time on this right now, but the bottom line is that while FPC code can interwork with either C or C++ (non-OO) code the object models are distinct. That's why whenever linking to an API which is only expressed in C++ (with OO) there's likely to be half-arsed suggestions like "tell the other project that they ought to maintain a pure-C version of their API"... which is of course fairly close to the ongoing GTK2 issue. For anything else I suggest looking back through this thread for mention of libQt#Pas since I'm pretty sure that there's discussion of the extent to which static linkage would fall foul of the Qt licensing terms. MarkMLl That unfinished discussion on The Register is interesting. What's your viewpoint? ---------------------------------------------------------------------- valdir.marcos · 2026-03-26 05:15 Quote from: Coldzer0 on March 26, 2026, 05:01:23 amQuote from: valdir.marcos on March 26, 2026, 04:03:46 amInteresting. Thanks. Is your solution [even remotely] related to the issue below? Can arbitrary C++ compilers use each other's classes? https://forum.lazarus.freepascal.org/index.php/topic,73766.0.html QuoteCan arbitrary C++ compilers use each other's classes?I don't think so. This Merge-Request is purely linker-level work, it has nothing to do with interfacing with C++ classes or VMT layouts. What we've done is teach FPC's internal linker to understand the COFF object file format as produced by MSVC, Clang, and GCC, so you can statically link their .a/.lib files without needing an external linker. That said, using C++ classes from Pascal is definitely possible. I've done something similar with a C++ library before, but it requires re- creating the C++ VMT layout in Pascal as a record with function pointers in the correct order. It's manual work and depends on the specific compiler's ABI, but it works. A small snippet from the project Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  Type  NPlatformParameters = Pointer;   { NClientParameters }   NClientParameters = Record    serverKey, host: string;    port: Int32;    ssl:  Boolean;    platformParams: Pointer;  End;   Vtable = Record    CPP_Destructor:   Pointer;    SetErrorCallback: Procedure(this: Pointer; NError: Pointer); Cdecl;    setUserData: Procedure(this: Pointer; userData: Pointer); Cdecl;    getUserData: Function(this: Pointer): Pointer; Cdecl;  End;  PVtable  = ^Vtable;  PPVtable = ^PVtable;   NClientInterface = Record    Vtable: PPVtable;  End;  NClientPtr = ^NClientInterface; Function CreateClientInterface(this, Parameters: Pointer): Pointer;  Cdecl; External 'nakama-sdk' Name '??0NClientInterface@Nakama@@QEAA@AEBV01@@Z'; Function createDefaultClient(this, Parameters: Pointer): NClientPtr;  Cdecl; External 'nakama-sdk' Name  '?createDefaultClient@Nakama@@YA?AV?$share d_ptr@VNClientInterface@Nakama@@@std@@AEBUNClientParameters@1@@Z'; Fun ction getNakamaSdkVersion(): PChar; Cdecl; External 'nakama-sdk' Name '?getNakamaSdkVersion@Nakama@@YAPEBDXZ'; Function CreateNClientParameters(SERVER, IP: String; PORT: Int32): NClientParameters; Implementation { NClientParameters } Function CreateNClientParameters(SERVER, IP: String; PORT: Int32): NClientParameters;Begin  FillByte(Result, SizeOf(NClientParameters), 0);  Result.host      := IP;  Result.serverKey := SERVER;  Result.port      := PORT;End; And we call it with Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Var  ClientParams: NClientParameters;  Client: NClientPtr;Begin   WriteLn('Nakama Loaded');  WriteLn('Nakama Version = ', getNakamaSdkVersion());   ClientParams := CreateNClientParameters('SERVER_KEY', '127.0.0.1', 8080);  Client := AllocMem(SizeOf(NClientInterface));  Client := createDefaultClient(Client, @ClientParams);  If Client <> nil Then  Begin    WriteLn('SetUserData = ', HexStr($1337C0DE, 16));    Client.Vtable^.SetUserData(Client.Vtable, Pointer($1337C0DE));    WriteLn('UserDater   = ', HexStr(Client.Vtable^.getUserData(Client.Vtable)));  End;   ReadLn;End. ---------------------------------------------------------------------- H₂SO₄ · 2026-03-26 06:16 Quote from: valdir.marcosCan arbitrary C++ compilers use each other's classes? Some C++ compilers can't even use their own classes  : Quote from: MicrosoftThe Microsoft C++ (MSVC) Build Tools in Visual Studio 2013 and earlier don't guarantee binary compatibility across major versions. You can't link object files, static libraries, dynamic libraries, and executables built by different versions of these build tools. The ABIs, object formats, and runtime libraries are incompatible. We've changed this behavior in Visual Studio 2015 and later versions. The problem is that the C++ standard leaves important details like name mangling unspecified. This means that in general, different C++ compilers cannot interoperate. You might be able to get away with mixing GCC and Clang, but that's only because Clang was designed with GCC compatibility in mind. ---------------------------------------------------------------------- 440bx · 2026-03-26 07:08 It's probably also worth mentioning that this lack of compatibility is likely to continue because standard bodies go out of their way to avoid specifying _how_ language features should be implemented. ---------------------------------------------------------------------- MarkMLl · 2026-03-26 07:28 Quote from: valdir.marcos on March 26, 2026, 03:51:58 amQuote from: MarkMLl on March 07, 2026, 10:40:26 pmFor anything else I suggest looking back through this thread for mention of libQt#Pas since I'm pretty sure that there's discussion of the extent to which static linkage would fall foul of the Qt licensing terms. That unfinished discussion on The Register is interesting. As I've already said, I knew from the piece's author (Liam) that it was going to appear, but had not been able to brief him (the situation was changing day by day) before he passed it to his editor. Having made the point about Qt and the required shim, I felt that continuing in a general-purpose forum would not be constructive: Pascal's on sufficiently thin ice as it is. QuoteWhat's your viewpoint? See thread at https://forum.lazarus.freepascal.org/index.php/topic,734 05.msg578010.html#msg578010 from which I quote PascalDragon below: QuoteFPC does not support the name mangling and the vtables that C++ classes require for correct functionality (*), thus a wrapper library (like Qt*Pas) is required that takes in the C++ API and provides it in turn as a C API that FPC can work with. (*) To be more precise FPC supports some C++ mangling as well as primitive C++ classes in the form of the cppdecl calling convention and cppclass, however these are not usable enough for directly declaring a C++ class like the Qt ones. Somewhere there are also similar points being made regarding Python's perceived interoperability with C++. I post the above as a useful xref, not because I am committed to this discussion. MarkMLl ---------------------------------------------------------------------- marcov · 2026-03-26 18:25 My remark was simply to detract from putting the term "C++" on a pedestal in the context of linking, because that might not be as unified as often presented.  (due to object model layout, mangling etc, as per PascalDragon's post). A simply litmus test for that two C++ compilers linking on a classes level. And then preferably not a rock bottom one. ---------------------------------------------------------------------- PascalDragon · 2026-03-26 22:53 Quote from: valdir.marcos on March 26, 2026, 03:51:58 amWhat's your viewpoint? MSVC, GCC and C++ builder are not compatible to each other and thus can't use each others classes, libraries, etc. (except if one restricts onself to a C API with the correct calling conventions). Only clang can be mixed together with GCC on *nix platforms and with MSVC on Windows platforms cause they're going to great lengths to be compatible to the corresponding system compiler. ---------------------------------------------------------------------- PascalDragon · 2026-03-26 22:59 Quote        27 days         MarkMLl         Qt generally works well, but needs a special shim library since FPC has the feature (ardently defended by some if its developers) that it can't interwork directly with code that uses C++ classes etc. @MarkMLI: why did you phrase it like that? It's not that we don't want to be able to link against C++ code, it's just that someone needs to find the time and motivation to implement that in a compatible way for the corresponding system compiler (mainly GCC vs. MSVC), we do have cppclass after all. But that is also not easy and some C++ aspects also aren't trivial to map to Pascal (e.g. methods that exist as a const and non-const variant where FPC does not have such a concept at all). ---------------------------------------------------------------------- valdir.marcos · 2026-03-30 04:08 Quote from: Khrys on March 26, 2026, 07:16:51 amQuote from: valdir.marcosCan arbitrary C++ compilers use each other's classes? Some C++ compilers can't even use their own classes  : Quote from: MicrosoftThe Microsoft C++ (MSVC) Build Tools in Visual Studio 2013 and earlier don't guarantee binary compatibility across major versions. You can't link object files, static libraries, dynamic libraries, and executables built by different versions of these build tools. The ABIs, object formats, and runtime libraries are incompatible. We've changed this behavior in Visual Studio 2015 and later versions. The problem is that the C++ standard leaves important details like name mangling unspecified. This means that in general, different C++ compilers cannot interoperate. You might be able to get away with mixing GCC and Clang, but that's only because Clang was designed with GCC compatibility in mind. Very interesting. Thanks. Quote from: 440bx on March 26, 2026, 08:08:12 amIt's probably also worth mentioning that this lack of compatibility is likely to continue because standard bodies go out of their way to avoid specifying _how_ language features should be implemented. Thanks. ---------------------------------------------------------------------- valdir.marcos · 2026-03-30 04:14 Quote from: MarkMLl on March 26, 2026, 08:28:52 amQuote from: valdir.marcos on March 26, 2026, 03:51:58 amQuote from: MarkMLl on March 07, 2026, 10:40:26 pmFor anything else I suggest looking back through this thread for mention of libQt#Pas since I'm pretty sure that there's discussion of the extent to which static linkage would fall foul of the Qt licensing terms. That unfinished discussion on The Register is interesting. As I've already said, I knew from the piece's author (Liam) that it was going to appear, but had not been able to brief him (the situation was changing day by day) before he passed it to his editor. Having made the point about Qt and the required shim, I felt that continuing in a general-purpose forum would not be constructive: Pascal's on sufficiently thin ice as it is. QuoteWhat's your viewpoint? See thread at https://forum.lazarus.freepascal.org/index.php/topic,734 05.msg578010.html#msg578010 from which I quote PascalDragon below: QuoteFPC does not support the name mangling and the vtables that C++ classes require for correct functionality (*), thus a wrapper library (like Qt*Pas) is required that takes in the C++ API and provides it in turn as a C API that FPC can work with. (*) To be more precise FPC supports some C++ mangling as well as primitive C++ classes in the form of the cppdecl calling convention and cppclass, however these are not usable enough for directly declaring a C++ class like the Qt ones. Somewhere there are also similar points being made regarding Python's perceived interoperability with C++. I post the above as a useful xref, not because I am committed to this discussion. MarkMLl Thanks. ---------------------------------------------------------------------- valdir.marcos · 2026-03-30 04:19 Quote from: marcov on March 26, 2026, 07:25:28 pmMy remark was simply to detract from putting the term "C++" on a pedestal in the context of linking, because that might not be as unified as often presented.  (due to object model layout, mangling etc, as per PascalDragon's post). A simply litmus test for that two C++ compilers linking on a classes level. And then preferably not a rock bottom one. Thanks. ---------------------------------------------------------------------- valdir.marcos · 2026-03-30 04:24 Quote from: PascalDragon on March 26, 2026, 11:53:24 pmQuote from: valdir.marcos on March 26, 2026, 03:51:58 amWhat's your viewpoint? MSVC, GCC and C++ builder are not compatible to each other and thus can't use each others classes, libraries, etc. (except if one restricts onself to a C API with the correct calling conventions). Only clang can be mixed together with GCC on *nix platforms and with MSVC on Windows platforms cause they're going to great lengths to be compatible to the corresponding system compiler. Thanks. Quote from: PascalDragon on March 26, 2026, 11:59:49 pmQuote        27 days         MarkMLl         Qt generally works well, but needs a special shim library since FPC has the feature (ardently defended by some of its developers) that it can't interwork directly with code that uses C++ classes etc. @MarkMLI: why did you phrase it like that? It's not that we don't want to be able to link against C++ code, it's just that someone needs to find the time and motivation to implement that in a compatible way for the corresponding system compiler (mainly GCC vs. MSVC), we do have cppclass after all. But that is also not easy and some C++ aspects also aren't trivial to map to Pascal (e.g. methods that exist as a const and non-const variant where FPC does not have such a concept at all). Thanks. ---------------------------------------------------------------------- Warfley · 2026-03-30 15:16 So the C++ standard does not specify the ABI, unlike for C. This means that generally speaking, every C++ compiler can decide on how to compile certain things, like the already mentioned name mangling, but also memory layout of classes using non C features (like virtual methods, public/private visibility, etc.) and be completely conforming to the ISO Standard. That said at least Clang (and I think also GCC and MSVC++) decided to have a more or less stable ABI for their compilers, and provide to some degree compatibility with other compilers. This is relatively new (in terms of C++ lifetime, it's been like that for many years now), it highly depends on the compiler you are using. IIRC there was a big break in ABI compatibility back with Clang 3.x to version 4 in 2017ish. But to take the example of QT, QT provides a list of supported compilers for which the library is compatible with, but they also have a list of settings you must set up for each compiler to ensure it works exactly for that reason. If you want to use a different compiler, or different configurations, QT is not guaranteed to work with that