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