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

[Riccardo Mottola]

Hi,

David Chisnall wrote:
> 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.

I see.. although I have not been able to get a working GNUstep on 
FreeBSD either.. butp erhaps for other reasons.

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

And we support this independently of libobjc2, just if we have an 
Obj-C++ capable compiler (which I have and sure it gets detected).

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

Of the two options, I'd try the latter. I think that if GNUstep is build 
with the package provided gcc and configured so with gnustep base, all 
programs build by the user will use by default that gcc and it makes 
sense to use "its" C++ library, so somehow it is gnusteb-base at fault here.

I think the unusual name was because the packaged gcc has the "e" 
prefix, so gcc became egcc, stdc++ became estdc++

We don't use ccmake for base, how can I use it to get the information 
you suggest?

I suppose I need to work on the LDFLAGS, correct?

Thank you,

Riccardo