You are probably missing the definition of std::allocator<char>::deallocate(char*, unsigned long)

[shikui08]

Unexpected behavior when building cppyy-backend master-branch from source using g++ >= 10.

1. Have to pass -D_POSIX_SEM_VALUE_MAX=32767 flag manually or the following error occur:

In file included from .<...>/cling/builddir/include/ROOT/TReentrantRWLock.hxx:21:
In file included from /usr/include/c++/12/condition_variable:46:
In file included from /usr/include/c++/12/stop_token:37:
In file included from /usr/include/c++/12/semaphore:35:
/usr/include/c++/12/bits/semaphore_base.h:59:41: error: use of undeclared identifier '_POSIX_SEM_VALUE_MAX'; did you mean '_SC_SEM_VALUE_MAX'?
static constexpr ptrdiff_t _S_max = _POSIX_SEM_VALUE_MAX;

2. After that I manage to build and install it in python. However when I run python code a few link error occur, the following one is one of them

import cppyy
cppyy.cppdef("""
#include <string>
void f() { std::string mPath; }
""")
from cppyy.gbl import f
f()

and error message is

IncrementalExecutor::executeFunction: symbol '_ZNSaIcE10deallocateEPcm' unresolved while linking symbol '__cf_4'!
You are probably missing the definition of std::allocator::deallocate(char*, unsigned long)
Maybe you need to load the corresponding shared library?

Building using g++-9 works great and both errors disappear. I assume it's more stable however some of the c++ codes that I am planning to expose to python only compile on newer compilers.
What might cause these link errors?
Any help is appreciated~

[wlav]

It's unexpected that a simple #include <condition_variable> can result in that error message. Can you try a basic program with your gcc12 that uses std::condition_variable? E.g. from here: https://en.cppreference.com/w/cpp/thread/condition_variable ? Trying to exclude a local installation issue with the compiler.

The second may be a mismatch between C++ versions. From what I see, there are several changes in gcc's allocator.h specific to C++20 v.s. C++17. Can you run cppyy.cppexec('std::cerr << __cplusplus << std::endl;') to see what version is being used?

Alternatively, since you have multiple compilers installed (yes?), the wrong stdc++.so may have been loaded. This is done explicitly in cppyy._stdcpp_fix.

[shikui08]

Thanks for your reply~

It's unexpected that a simple #include <condition_variable> can result in that error message. Can you try a basic program with your gcc12 that uses std::condition_variable? E.g. from here: https://en.cppreference.com/w/cpp/thread/condition_variable ? Trying to exclude a local installation issue with the compiler.

I tried on a fresh ubuntu 22.04 virtual machine with g++11 and still got compile error.
Here's what I did to make it build.

./src/core/thread/CMakeLists.txt
add
add_definitions("-D_POSIX_SEM_VALUE_MAX=32767")
2)
./src/etc/dictpch/makepch.py
insert
cppFlagsList += ["-D_POSIX_SEM_VALUE_MAX=32767"]
before
command.append("-cxxflags")

The second may be a mismatch between C++ versions. From what I see, there are several changes in gcc's allocator.h specific to C++20 v.s. C++17. Can you run cppyy.cppexec('std::cerr << __cplusplus << std::endl;') to see what version is being used?

Alternatively, since you have multiple compilers installed (yes?), the wrong stdc++.so may have been loaded. This is done explicitly in cppyy._stdcpp_fix.

Building using g++-11 or g++-12:

1. If python code is run with environment variable CLING_STANDARD_PCH= , then the c++ source can be recognized as c++20, however std::string s; will cause link error;
2. Otherwise c++ source is recognized as c++17, and std::string s; is ok.

[shikui08]

Is there a workaround for std::string && c++20 combination?

[wlav]

The _POSIX_SEM_VALUE_MAX seems to be a clang v.s. gcc thing: https://gcc.gnu.org/pipermail/gcc/2023-July/242042.html

Basically, there's a limits.h in gcc-12 that's not the system limits.h and which in turn does not include posix1_lim.h that defines _POSIX_SEM_VALUE_MAX. Depending on how gcc-12 is setup, either the system one or the gcc-12 one is found first after the Clang limits.h declares #include_next.

I put a workaround in, as well as resolving several gcc12 warnings.

[wlav]

The You are probably missing the definition of std::allocator::deallocate(char*, unsigned long) is a gcc12 (and later) thing. See: https://github.com/sxs-collaboration/spectre/pull/5222/files#diff-093aadf224e5fee0d33ae1810f2f1c23304fb5ca398ba6b96c4e7918e0811729

(which mentions Clang15, but clearly it's already an issue with Clang13 and although they are not checking GLIBCXX version, the offending function wasn't introduced until version 12).

I'm putting that workaround (after a bit of clean up) in clingwrapper.cxx.