On Thu, Jan 31, 2019 at 01:12:10AM +0000, Tinker wrote:
> Hi Otto and Jeremie,
>
> I think I have the answer to your particular question, and it's
> platform-independent:
>
> Reading your log file
> http://build-failures.rhaalovely.net//sparc64/2019-01-10/net/amule,-daemon.log
> , there is mentioning of libestdc++ in there.
>
> Please be aware that a program that links to both libstdc++ and
> libestdc++ will likely crash, and in my experience exception handling
> gone-haywire is a typical form of such a crash.
That does not explain my simple test case I posted erlier, where
mixing of libs does not play a roll at all.
-Otto
>
> The problem lies in that one part of your program, shared libraries
> included, generated an object using the C++ standard library - say an
> exception - and this was passed to another part of the program, that
> passed that C++ standard library version's object to another C++
> standard library version, and from there things break down in undefined
> ways very fast, for instance leading to sudden program termination but
> no SIGSEGV.
>
> When a library port is built with one g++ version and another library
> port or your program is built with another g++ version, you run into
> these troubles.
>
> The above is my experience from combining g++ and eg++ code previously.
>
> If you don't experience this on AMD64, it may be because all
> dependencies there are compiled with llvm and therefore all depend on
> one and the same libc++ only.
>
> C++ library version incompatibilities is a really uncomfortable aspect
> of the C++ ecosystem. I don't recall exactly but I think Linux has a
> custom library loading logic where if there are dependencies to more
> libstdc++ versions, it will only load the highest version, and not sure
> but libstdc++ versions could be backwards compatible, that one would
> need to be doublechecked too.
>
> Specifically the libraries are:
>
> OS GCC: /usr/lib/libstdc++
> Ports GCC: /usr/lib/libestdc++
> LLVM: /usr/lib/libc++
>
>
> You check whether this is the case using ldd.
>
> Jonathan Wakely aka redi and boru on #gcc on FreeNode IRC are big
> experts.
>
> This incomplete Gnu C++ page by Wakely discusses specific Gnu C++
> standard library incompatibilities:
> https://gcc.gnu.org/wiki/Cxx11AbiCompatibility
>
> Also note LLVM's expressed design goal of "ABI compatibility with gcc's
> libstdc++ for some low-level features such as exception objects, rtti
> and memory allocation.", ref. https://libcxx.llvm.org .
>
> Also note LLVM has an "--stdlib=libstdc++" to use Gnu's library instead
> of its own, ref.
> https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-stdlib
> , and Wakely comments it here
> https://stackoverflow.com/questions/19774778/when-is-it-necessary-to-use-use-the-flag-stdlib-libstdc
> .
>
> Also there's the ABI aspect, Gnu /usr/lib/libsupc++ and LLVM
> /usr/lib/libc++abi , didn't study how these play in.
>
> Tinker
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, January 31, 2019 12:27 AM, Otto Moerbeek <[email protected]> wrote:
>
> > On Wed, Jan 30, 2019 at 01:36:17PM +0100, Otto Moerbeek wrote:
> >
> > > On Wed, Jan 30, 2019 at 01:21:55PM +0100, Jeremie Courreges-Anglas wrote:
> > >
> > > > On Wed, Jan 30 2019, Otto Moerbeek [email protected] wrote:
> > > >
> > > > > Hi,
> > > > > net/powerdns does not work well on sparc64. It is a C++ program that
> > > > > uses exceptions quite extensively. The case I'm running into is a
> > > > > unknown item in a config file. The code should catch the exception and
> > > > > exit gracefully with an proper error message, but instead a catch-all
> > > > > is being hit:
> > > > > Jan 30 13:12:42 Reading random entropy from '/dev/urandom'
> > > > > Jan 30 13:12:42 Loading '/usr/local/lib/pdns/libgsqlite3backend.so'
> > > > > Jan 30 13:12:42 This is a standalone pdns
> > > > > Jan 30 13:12:42 Listening on controlsocket in
> > > > > '/var/run/pdns.controlsocket'
> > > > > terminate called after throwing an instance of 'PDNSException'
> > > > > terminate called recursively
> > > > > Abort trap (core dumped)
> > > > > Is C++ exception handling a known broken thing on sparc64?
> > > > > Any suggested remedy or should the port just be marked broken for
> > > > > sparc64?
> > > > > On amd64 the config file error is handled correctly.
> > > >
> > > > I've noticed this in the last sparc64 bulk build report:
> > > > http://build-failures.rhaalovely.net//sparc64/2019-01-10/net/amule,-daemon.log
> > > > I haven't looked into the details yet. It might be a fluke, or it might
> > > > support your "exceptions are broken" theory.
> > >
> > > This is reproducable on 6.3 and 6.4, so it is not recent breakage.
> > > I'll try to write a test program.
> > > -Otto
> >
> > The test program below already shows the problem when compiled with eg++
> > (and clang++ for that matter). This is using the most recent snap.
> >
> > The base C++ compiler does produce the correct result.
> >
> > $ eg++ x.cc && ./a.out
> > terminate called after throwing an instance of 'ex'
> > terminate called recursively
> > Abort trap (core dumped)
> > $ c++ x.cc && ./a.out
> > Catching...
> > $
> >
> > -Otto
> >
> > #include <iostream>
> >
> > class ex {
> > };
> >
> > void f(void)
> > {
> > throw ex();
> > }
> >
> > int main()
> > {
> > try {
> > f();
> > }
> > catch (const ex & myex) {
> > std::cout << "Catching..." << std::endl;
> > }
> > }
>
>
