[Bug]: Undefined symbol referenced from absl::lts_20240722::log_internal::LogMessage::operator<<(unsigned long)

[Chekov2k]

Describe the issue

I'm trying to use protobuf 27.3 which uses abseil 20240722.0 on Mac OS X Sonoma 14.6.1 and llvm 18.1.8 or gcc 14.1.0 (all installed using homebrew). I'm getting this undefined symbol (my code is compile with C++23 standard):

Undefined symbols for architecture arm64:
 "__ZN4absl12lts_2024072212log_internal10LogMessagelsImTnNSt3__19enable_ifIXntsr4absl16HasAbslStringifyIT_EE5valueEiE4typeELi0EEERS2_RKS6_", referenced from:
      absl::lts_20240722::log_internal::LogMessage::operator<<(unsigned long) in engine.pb.cc.o

I have been trying to narrow down the cause and only found one other report of someone having a similar issue (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280885). As far as I can tell, I am following all the advised linking steps for protobut and abseil (tried adding all of the abseil libs as well just to be sure and still the same issue). I tried changing the CXX standard used for compilation of protobuf and abseil to CXX23 as well and still get the same error.

In our CI we get the same undefined symbol if we try and use llvm 18.1 or gcc 14.1 on linux (abseil and protobuf being compiled with the standard OS compiler for Ubuntu 22.04).

Does someone have an idea of what the issue might be or what I should try next? Everything works fine if I stick with llvm 17.0.6 or gcc 13.3.0.

Steps to reproduce the problem

Using protoc to generate C++ protobuf bindings

What version of Abseil are you using?

20240722

What operating system and version are you using?

Mac OS X Sonoma 14.6.1 arm64v8 or. Ubuntu 22.04 amd64

What compiler and version are you using?

Issues with llvm 18.1.8 and gcc 14.1.0 using C++23 standard
Fine with llvm 17.0.6 and gcc 13.3.0 using C++23 standard

What build system are you using?

cmake 3.30.2

Additional context

No response

[derekmauro]

Probably related reports:
#1743
llvm/llvm-project#102443

[Chekov2k]

@derekmauro Thank you very much for pointing out these other reports. The llvm one provides a workaround using
-fclang-abi-compat=17. Much appreciated!

[4kangjc]

Adding the following code to your source file can also temporarily solve this problem

#include "absl/base/config.h"

namespace absl {

ABSL_NAMESPACE_BEGIN

namespace log_internal {

template LogMessage& LogMessage::operator<<(const char& v);
template LogMessage& LogMessage::operator<<(const signed char& v);
template LogMessage& LogMessage::operator<<(const unsigned char& v);
template LogMessage& LogMessage::operator<<(const short& v);           // NOLINT
template LogMessage& LogMessage::operator<<(const unsigned short& v);  // NOLINT
template LogMessage& LogMessage::operator<<(const int& v);
template LogMessage& LogMessage::operator<<(const unsigned int& v);
template LogMessage& LogMessage::operator<<(const long& v);           // NOLINT
template LogMessage& LogMessage::operator<<(const unsigned long& v);  // NOLINT
template LogMessage& LogMessage::operator<<(const long long& v);      // NOLINT
template LogMessage& LogMessage::operator<<(
    const unsigned long long& v);  // NOLINT
template LogMessage& LogMessage::operator<<(void* const& v);
template LogMessage& LogMessage::operator<<(const void* const& v);
template LogMessage& LogMessage::operator<<(const float& v);
template LogMessage& LogMessage::operator<<(const double& v);
template LogMessage& LogMessage::operator<<(const bool& v);

}  // namespace log_internal

ABSL_NAMESPACE_END

}  // namespace absl

[Chekov2k]

Thank you!

[bitsim-ab]

I think there is some kind of regression, this exact problem appears with clang-19.1.7.
-fclang-abi-compat=17 is still a possible workaround.