[odb-users] Internal compiler error linked to spdlog

[Paul Stath]

Hi Boris,

Thanks for the explanation and the fix in the ODB 2.5.0 beta.
I have been investigating changing our logging layer and spdlog one of the solutions to be evaluated.

It was not absolutely clear from the example, but I'm going to assume the accessor statement was inline-ed in the header file, since the ODB compiler was having issues.
Is this how you were able to recreate the issue?

If so, a simple work-around would be to simply declare the accessor in the persistent class header, and implement the accessor in the cxx file.  Right?

For those stuck on ODB 2.4.0, and unwilling to keep spdlog out of the header files, it should be possible to wrap the spdlog code bits in #ifndef ODB_COMPILER sections.  Right?

--- Paul



-----Original Message-----
From: Boris Kolpackov <boris at codesynthesis.com> 
Sent: Monday, May 4, 2020 10:11 AM
To: Sean Clarke <sean.clarke at sec-consulting.co.uk>
Cc: odb-users at codesynthesis.com
Subject: Re: [odb-users] Internal compiler error linked to spdlog

Sean Clarke <sean.clarke at sec-consulting.co.uk> writes:

> Has anyone else seen anything similar?

I was able to reproduce and fix this based on your description (details for those interested below).

I've also staged the fix so if you would like to give it a try, just follow the build2-based installation instructions[1] but use this
repository:

https://stage.build2.org/1

Instead of:

https://pkg.cppget.org/1/beta

To get ODB.

(I believe you should be able to use the 0.12.0 build2 toolchain but if not, upgrade to staged[2].)

Now, if anyone is interested, the problem was caused by this code in
spdlog:

namespace spdlog
{
  class logger
  {
    log_err_handler err_handler_{[this](const std::string &msg) { this->default_err_handler_(msg); }};
  }
}

It appears that in GCC's AST this is represented as an injected into the spdlog namespace class-type that implements the lambda. It turns out such a type cannot be treated as an ordinary class which is what ODB tried to do. The fix is simply to ignore such lambda classes since there is nothing interesting about them from the ODB's POV.

Here is the commit that fixes this:

https://git.codesynthesis.com/cgit/odb/odb/commit/?id=ba69cf5f0d916c4fdc943f2171691e074417f2e8

[1] https://codesynthesis.com/products/odb/doc/install-build2.xhtml
[2] https://build2.org/community.xhtml#stage