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