Can arbitrary C++ compilers use each other's classes?

[valdir.marcos]

Debian 14 will drop Gtk2 – unless Ardour rides to the rescue
https://forums.theregister.com/forum/all/2026/02/26/debian_14_will_drop_gtk2/

Debian 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?

                                                       

i 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]

Interesting. 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

Can 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][+][-]

1.  
2. Type
3.   NPlatformParameters = Pointer;
4.  
5.   { NClientParameters }
6.  
7.   NClientParameters = Record
8.     serverKey, host: string;
9.     port: Int32;
10.     ssl:  Boolean;
11.     platformParams: Pointer;
12.   End;
13.  
14.   Vtable = Record
15.     CPP_Destructor:   Pointer;
16.     SetErrorCallback: Procedure(this: Pointer; NError: Pointer); Cdecl;
17.     setUserData: Procedure(this: Pointer; userData: Pointer); Cdecl;
18.     getUserData: Function(this: Pointer): Pointer; Cdecl;
19.   End;
20.   PVtable  = ^Vtable;
21.   PPVtable = ^PVtable;
22.  
23.   NClientInterface = Record
24.     Vtable: PPVtable;
25.   End;
26.   NClientPtr = ^NClientInterface;
27.  
28. Function CreateClientInterface(this, Parameters: Pointer): Pointer;
29.   Cdecl; External 'nakama-sdk' Name '??0NClientInterface@Nakama@@QEAA@AEBV01@@Z';
30.  
31. Function createDefaultClient(this, Parameters: Pointer): NClientPtr;
32.   Cdecl; External 'nakama-sdk' Name
33.   '?createDefaultClient@Nakama@@YA?AV?$shared_ptr@VNClientInterface@Nakama@@@std@@AEBUNClientParameters@1@@Z';
34.  
35. Function getNakamaSdkVersion(): PChar; Cdecl; External 'nakama-sdk' Name '?getNakamaSdkVersion@Nakama@@YAPEBDXZ';
36.  
37. Function CreateNClientParameters(SERVER, IP: String; PORT: Int32): NClientParameters;
38.  
39. Implementation
40.  
41. { NClientParameters }
42.  
43. Function CreateNClientParameters(SERVER, IP: String; PORT: Int32): NClientParameters;
44. Begin
45.   FillByte(Result, SizeOf(NClientParameters), 0);
46.   Result.host      := IP;
47.   Result.serverKey := SERVER;
48.   Result.port      := PORT;
49. End;
50.  
51.  

And we call it with

Code: Pascal  [Select][+][-]

1. Var
2.   ClientParams: NClientParameters;
3.   Client: NClientPtr;
4. Begin
5.  
6.   WriteLn('Nakama Loaded');
7.   WriteLn('Nakama Version = ', getNakamaSdkVersion());
8.  
9.   ClientParams := CreateNClientParameters('SERVER_KEY', '127.0.0.1', 8080);
10.   Client := AllocMem(SizeOf(NClientInterface));
11.   Client := createDefaultClient(Client, @ClientParams);
12.   If Client <> nil Then
13.   Begin
14.     WriteLn('SetUserData = ', HexStr($1337C0DE, 16));
15.     Client.Vtable^.SetUserData(Client.Vtable, Pointer($1337C0DE));
16.     WriteLn('UserDater   = ', HexStr(Client.Vtable^.getUserData(Client.Vtable)));
17.   End;
18.  
19.   ReadLn;
20. End.
21.  

[Khrys]

Can arbitrary C++ compilers use each other's classes?

Some C++ compilers can't even use their own classes  :

The 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]

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]

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.

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.

What's your viewpoint?

See thread at https://forum.lazarus.freepascal.org/index.php/topic,73405.msg578010.html#msg578010 from which I quote PascalDragon below:

FPC 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]

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]

What'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]

        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]

Can arbitrary C++ compilers use each other's classes?

Some C++ compilers can't even use their own classes  :

The 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.

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.

Thanks.

[valdir.marcos]

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.

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.

What's your viewpoint?

See thread at https://forum.lazarus.freepascal.org/index.php/topic,73405.msg578010.html#msg578010 from which I quote PascalDragon below:

FPC 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]

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.

Thanks.

[valdir.marcos]

What'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.

        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]

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