[odb-users] Internal compiler error linked to spdlog

[Boris Kolpackov]

Paul Stath <PStath at jmawireless.com> writes:

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

Yes, just including the <spdlog/spdlog.h> header is sufficient to trigger
this bug.


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

Correct.


> [...] 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?

Correct, you can do something along these lines:

#ifndef ODB_COMPILER
#  include <spdlog/spdlog.h>
#endif

#pragma db object
struct object
{
  std::shared_ptr<Address> const& address() const {
#ifndef ODB_COMPILER
    if (m_short_code == "PRIVATE") {
      auto log = spdlog::get("main");
      log->error("Customer::address : Customer address of PRIVATE customer cannot be accessed");
    }
#endif
    return m_address;
  }
};


> For those stuck on ODB 2.4.0 [...]

I am sure there are good reasons for this, but this case illustrates
one of the major benefits of switching to the 2.5.0 beta/build2-based
build: I was able to fix the bug, stage the fix, have it tested on
all the supported platforms[1], and make it available to anyone
interested (again, regardless of their platform of choice) all in a
few hours. There is no way I would have been able to do (nor, to be
honest, interested in doing) the same if it required building and
testing binary packages/installers for a bunch of platforms.

[1] https://stage.build2.org/?builds=odb