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. 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 <o...@drijf.net> 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 o...@drijf.net 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; > } > }
