-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Typeid information not synchronized across shared library boundaries #912
Comments
Hm, is |
Yes, indeed -- the typeids differ in these two modules despite the |
We do have a few places that do a pointer equality comparison, which seems slightly wrong, but fixing it (PR #914) doesn't fix the issue. I think, however, given the response in https://bugs.llvm.org/show_bug.cgi?id=33542:
we might have to switch to using the I'm curious, though, why this doesn't seem to affect macOS. |
As a workaround, you can call this before loading the pybind modules: import os, sys
sys.setdlopenflags(os.RTLD_NOW | os.RTLD_GLOBAL) |
Using `std::type_info::operator==` fails under libc++ because the .so is loaded with RTLD_LOCAL. libc++ considers types under such .sos distinct, and so comparing typeid() values directly isn't going to work. This adds a custom hasher and equality class for the type lookup maps when not under stdlibc++, and adds a `detail::same_type` function to perform the equality test. It also converts a few pointer arguments to const lvalue references, particularly since doing the pointer comparison wasn't technically valid to being with (though in practice, appeared to work everywhere). This fixes pybind#912.
I just did, and it works with that patch -- thank you! Regarding the OSX inconsistency: it's likely that the dlopen semantics are a bit different on Mach-O binaries. |
Using `std::type_info::operator==` fails under libc++ because the .so is loaded with RTLD_LOCAL. libc++ considers types under such .sos distinct, and so comparing typeid() values directly isn't going to work. This adds a custom hasher and equality class for the type lookup maps when not under stdlibc++, and adds a `detail::same_type` function to perform the equality test. It also converts a few pointer arguments to const lvalue references, particularly since doing the pointer comparison wasn't technically valid to being with (though in practice, appeared to work everywhere). This fixes #912.
Dear all,
I've been running into strange inconsistencies where type information is not synchronized across shared library boundaries. This happens when using Clang & libc++ on Linux/x86_64 machines.
Before escalating to Clang/LLVM, I wanted to gauge if anyone here has previously run into this. To reproduce:
issue.py
CMakeLists.txt:
shared.h
shared.cpp
mod1.cpp
mod2.cpp
Best,
Wenzel
The text was updated successfully, but these errors were encountered: