|
From: | David Chisnall |
Subject: | Re: OpenBSD crashes - GWorkspace coredumps - mismatched C++ libraries |
Date: | Fri, 21 May 2021 15:22:59 +0100 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 |
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.0vs: 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
[Prev in Thread] | Current Thread | [Next in Thread] |