gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]