Undefined symbols: pqxx::usage_error::usage_error on macOS ARM64

[jviotti]

Hey there! I'm attempting to use libpqxx on macOS Sonoma ARM64 and getting some weird linker errors:

ld: Undefined symbols:
  pqxx::usage_error::usage_error(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, std::__1::source_location), referenced from:
      pqxx::internal::stream_query<int>::stream_query(pqxx::transaction_base&, std::__1::basic_string_view<char, std::__1::char_traits<char>>) in main.cc.o
  pqxx::argument_error::argument_error(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, std::__1::source_location), referenced from:
      pqxx::internal::(anonymous namespace)::throw_for_encoding_error(char const*, char const*, unsigned long, unsigned long) in main.cc.o
  pqxx::conversion_overrun::conversion_overrun(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, std::__1::source_location), referenced from:
      pqxx::string_traits<char const*>::into_buf(char*, char*, char const* const&) in main.cc.o
      pqxx::string_traits<std::__1::basic_string_view<char, std::__1::char_traits<char>>>::into_buf(char*, char*, std::__1::basic_string_view<char, std::__1::char_traits<char>> const&) in main.cc.o

From what I can tell, I'm linking to libpqxx correctly (I'm using 7.8.1 from Homebrew):

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++  -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/opt/homebrew/Cellar/libpqxx/7.8.1/lib -lpqxx CMakeFiles/test.dir/main.cc.o -o test

Using pqxx::work and pqxx::row works fine, but using the stream-based templates trigger the issue. Also, if I inspect the static library I'm linking against, it does seem to define the supposedly missing usage_error symbols:

$ nm -a /opt/homebrew/Cellar/libpqxx/7.8.1/lib/libpqxx.a | grep usage_error
                 U __ZN4pqxx11usage_errorC1ERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE
00000000000005cc T __ZN4pqxx11usage_errorD1Ev
0000000000002d78 S __ZTIN4pqxx11usage_errorE
0000000000002cbc S __ZTSN4pqxx11usage_errorE
                 U __ZN4pqxx11usage_errorC1ERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE
0000000000000a08 T __ZN4pqxx11usage_errorD1Ev
0000000000007f00 S __ZTIN4pqxx11usage_errorE
0000000000007b2c S __ZTSN4pqxx11usage_errorE
                 U __ZN4pqxx11usage_errorC1ERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE
00000000000011f0 T __ZN4pqxx11usage_errorD1Ev
00000000000021c8 S __ZTIN4pqxx11usage_errorE
0000000000001cca S __ZTSN4pqxx11usage_errorE
0000000000000584 T __ZN4pqxx11usage_errorC1ERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE
0000000000000560 T __ZN4pqxx11usage_errorC2ERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE
0000000000000804 T __ZN4pqxx11usage_errorD0Ev
0000000000000800 T __ZN4pqxx11usage_errorD1Ev
00000000000010d8 S __ZTIN4pqxx11usage_errorE
0000000000001337 S __ZTSN4pqxx11usage_errorE
0000000000000ee0 S __ZTVN4pqxx11usage_errorE
                 U __ZN4pqxx11usage_errorC1ERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE
000000000000062c T __ZN4pqxx11usage_errorD1Ev
00000000000020d0 S __ZTIN4pqxx11usage_errorE
0000000000002028 S __ZTSN4pqxx11usage_errorE
                 U __ZN4pqxx11usage_errorC1ERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE
0000000000001b90 T __ZN4pqxx11usage_errorD1Ev
00000000000046d8 S __ZTIN4pqxx11usage_errorE
0000000000003d40 S __ZTSN4pqxx11usage_errorE
                 U __ZN4pqxx11usage_errorC1ERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE
00000000000004dc T __ZN4pqxx11usage_errorD1Ev
0000000000002518 S __ZTIN4pqxx11usage_errorE
0000000000002408 S __ZTSN4pqxx11usage_errorE
                 U __ZN4pqxx11usage_errorC1ERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE
0000000000000f10 T __ZN4pqxx11usage_errorD1Ev
0000000000003720 S __ZTIN4pqxx11usage_errorE
0000000000003444 S __ZTSN4pqxx11usage_errorE
                 U __ZN4pqxx11usage_errorC1ERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE
0000000000000780 T __ZN4pqxx11usage_errorD1Ev
0000000000001d20 S __ZTIN4pqxx11usage_errorE
0000000000001c99 S __ZTSN4pqxx11usage_errorE

Have you seen something like this before? Here is an example CMake project that reproduces the issue for me: https://github.com/jviotti/pqxx-test

[jviotti]

I think there is something wrong with the Homebrew formula. Opening a PR there extending their formula test to see if we can surface it.

[jviotti]

A key difference seems to be that Homebrew builds using Autotools, and not CMake. Could there be something off on the Autotools builds files?

[jviotti]

The definition of this usage_error class is at https://github.com/jtv/libpqxx/blob/7.8.1/src/except.cxx, and that file seems to be indeed included here: https://github.com/jtv/libpqxx/blob/7.8.1/src/Makefile.am#L10

[jviotti]

Building it from source with CMake actually works for me. There is definitely something off with that Homebrew formula, but not sure what.

[tt4g]

Maybe duplicate #732

Homebrow builds libpqxx with C++17 because it appends -std=c++17 to CXXFLAGS.

https://github.com/Homebrew/homebrew-core/blob/430023d585e8429b7c22d19cf53d6e015d2e980d/Formula/lib/libpqxx.rb#L29

Your project uses C++20 because std::source_location is included in the symbols in the link error message.
std::source_location was added in C++20 and is not included in the Homebrow generated library symbols.

Link your own build of libpqxx or use C++17 in your project.

[jtv]

Yes, that's the same issue. I'm working on a new way to store the configuration in a header, and that should solve this immediate problem. However, it's still not a given that mixing C++17 and C++20 will work, so it's important to harmonise that build!

[jviotti]

Ah, interesting. That explains why it works when I build it locally: I did so with C++20. I'm unblocked now (by using my own build) but it'd be interesting to solve the Homebrew problem.

Thanks a lot, and if this issue is duplicated, feel free to close it!

[jtv]

Glad to hear that. I think I'll have to move to libpqxx 8.0 soon, because that's where I'm going to drop support for C++17. As for Homebrew, I fear the best solution there would have been for the packaging to provide separate C++17 and C++20 builds. But it's a pain for users, of course.

[jtv]

And indeed, I'll close this as a duplicate of #732.

[jtv]

@jviotti Some blockers for the next release have cleared up in recent days, so hoping to release 7.9.0 soon, and hopefully the problem won't happen with that.

However in the grander scale, we're still stuck with the problem that all package managers encourage us to link things together that may or may not actually be compatible, because of different language versions etc.

[jviotti]

Thanks for the updates and no worries! I'm consuming pqxx as an external CMake dependency, which is working great so far