Re: OpenBSD crashes - GWorkspace coredumps - mismatched C++ libraries

David Chisnall <[email protected]> Fri, 21 May 2021 15:22:59 +0100
Newsgroups gmane.comp.lib.gnustep.devel
Message-ID <[email protected]>
Hi Riccardo,

On 21/05/2021 15:14, Riccardo Mottola wrote:
> So indeed, once running, there is a mix of:
> 
>          0f88c000 2f96f000 rlib  0    1   0 
> /usr/local/lib/libestdc++.so.19.0
> 
> vs:
>          08fb7000 28fbd000 rlib  0    2   0 /usr/lib/libc++.so.7.0
>          0ca18000 2ca1c000 rlib  0    3   0 /usr/lib/libc++abi.so.5.0

That is, indeed, the problem.  You can mix libc++ and libstdc++ (though 
the types cannot cross a library boundary) but both libc++abi and 
libsupc++ expose the same symbols and cannot be mixed.  By default, 
libstdc++ statically links libsupc++.  On FreeBSD, we avoid this by 
linking both libc++ and libstdc++ against the system-provided libcxxrt. 
  It looks as if OpenBSD (at least with your egcc build) doesn't do this.

> but why do base and FSNode link against this system library? Do we use 
> C++ stuff? not that I know, explicitely. Only PDFKit has an explicit use 
> of the C++ compiler.

We need to hook into the C++ runtime library to ensure that 
Objective-C++ exceptions work.  You need to either:

  - Compile and link the C++ library (PDFKit) against the system C++ 
implementation (libc++ / libc++abi), or
  - Compile and link the Objective-C runtime against the extra c++ 
runtime (libestd++).  Note that libestdc++ is an unusual name and so 
won't be found by default, you will need to pass this as an explicit 
option in the libobjc2 build (ccmake will show you the name).

David