-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Pybind11 fix linkage #13283
Pybind11 fix linkage #13283
Conversation
This comment has been minimized.
This comment has been minimized.
Something is causing pybind to link in # pybind11 method:
pybind11_add_module(MyModule1 src1.cpp) Results in a linking error because # Python method:
Python_add_library(MyModule2 src2.cpp)
target_link_libraries(MyModule2 pybind11::headers) However, links correctly. It's a bit mysterious as conan targets only links the headers, they don't do anything else. Linking in Python (or not) is handled by pbind11's custom CMake scripts. |
I detected other pull requests that are modifying pybind11/all recipe: This message is automatically generated by https://github.com/ericLemanissier/conan-center-conflicting-prs so don't hesitate to report issues/improvements there. |
if can_run(self): | ||
python_path = os.path.join(self.build_folder, self.cpp.build.libdirs[0]) | ||
module_path = os.path.join(self.source_folder, "test.py") | ||
self.run(f"PYTHONPATH={python_path} {self._python_interpreter} {module_path}", env="conanrun") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a better way to set the PYTHONPATH
env var in Conan V2? I can't set it in generate
as I don't have access to self.build_folder
at that point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a great question. Hopefully someone who knows will update us.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
find_package(pybind11 REQUIRED CONFIG) | ||
|
||
pybind11_add_module(test_package MODULE test_package.cpp) | ||
#pybind11_add_module(test_package MODULE test_package.cpp) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lingering comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR still in draft - there are still a few things I want to test.
This comment has been minimized.
This comment has been minimized.
1 similar comment
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@planetmarshall please close the PR for 10 second then reopen it so that it retriggers a build and finally merge this change |
This comment has been minimized.
This comment has been minimized.
430971e
My guess is, it failed with a runtime error. Need to run on Windows to check it. |
All green in build 12 (
|
Whilst attempting to write a test executable with an embedded Python interpreter for OpenAssetIO#739, it turned out that the old problem reported in OpenAssetIO#528 was still present. To recap, ultimately (via circuitous logic) every CMake target created by the Conan pybind11 package links to `libpython` (the `pybind11::embed` target is the only one that should). This means that Python extension modules (`pybind11::module`s) link to `libpython`, causing linker errors at runtime or even segfaults due to ODR violations. As of conan-io/conan-center-index#13283 this bug was fixed upstream. However, we still see it because the bug was not fixed for the deprecated `cmake_find_package` generator, which we use. It has not affected us so far because we haven't added in the `Development.Embed` component to our `find_package(Python` call. As soon as we add that component (e.g. for adding the aforementioned Python unit test) we see this problem. So modernise our `conanfile.py` to use the non-deprecated `CMakeDeps` generator. `CMakeDeps` insists on having the `build_type` setting available, so add that. Unfortunately `CMakeDeps` is designed to install dependencies with the same configuration (Release, Debug, etc) as the parent project, which is usually undesirable - we want Release versions of dependencies whilst we develop the project in Debug mode. This is logged upstream in conan-io/conan#11607, where a workaround is posted, which is used here (see code comments). Signed-off-by: David Feltell <david.feltell@foundry.com>
Whilst attempting to write a test executable with an embedded Python interpreter for OpenAssetIO#739, it turned out that the old problem reported in OpenAssetIO#528 was still present. To recap, ultimately (via circuitous logic) every CMake target created by the Conan pybind11 package links to `libpython` (the `pybind11::embed` target is the only one that should). This means that Python extension modules (`pybind11::module`s) link to `libpython`, causing linker errors at runtime or even segfaults due to ODR violations. As of conan-io/conan-center-index#13283 this bug was fixed upstream. However, we still see it because the bug was not fixed for the deprecated `cmake_find_package` generator, which we use. It has not affected us so far because we haven't added in the `Development.Embed` component to our `find_package(Python` call. As soon as we add that component (e.g. for adding the aforementioned Python unit test) we see this problem. So modernise our `conanfile.py` to use the non-deprecated `CMakeDeps` generator. `CMakeDeps` insists on having the `build_type` setting available, so add that. Unfortunately `CMakeDeps` is designed to install dependencies with the same configuration (Release, Debug, etc) as the parent project, which is usually undesirable - we want Release versions of dependencies whilst we develop the project in Debug mode. This is logged upstream in conan-io/conan#11607, where a workaround is posted, which is used here (see code comments). Signed-off-by: David Feltell <david.feltell@foundry.com>
Whilst attempting to write a test executable with an embedded Python interpreter for OpenAssetIO#739, it turned out that the old problem reported in OpenAssetIO#528 was still present. To recap, ultimately (via circuitous logic) every CMake target created by the Conan pybind11 package links to `libpython` (the `pybind11::embed` target is the only one that should). This means that Python extension modules (`pybind11::module`s) link to `libpython`, causing linker errors at runtime or even segfaults due to ODR violations. As of conan-io/conan-center-index#13283 this bug was fixed upstream. However, we still see it because the bug was not fixed for the deprecated `cmake_find_package` generator, which we use. It has not affected us so far because we haven't added in the `Development.Embed` component to our `find_package(Python` call. As soon as we add that component (e.g. for adding the aforementioned Python unit test) we see this problem. So modernise our `conanfile.py` to use the non-deprecated `CMakeDeps` generator. `CMakeDeps` insists on having the `build_type` setting available, so add that. Unfortunately `CMakeDeps` is designed to install dependencies with the same configuration (Release, Debug, etc) as the parent project, which is usually undesirable - we want Release versions of dependencies whilst we develop the project in Debug mode. This is logged upstream in conan-io/conan#11607, where a workaround is posted, which is used here (see code comments). Signed-off-by: David Feltell <david.feltell@foundry.com>
Whilst attempting to write a test executable with an embedded Python interpreter for OpenAssetIO#739, it turned out that the old problem reported in OpenAssetIO#528 was still present. To recap, ultimately (via circuitous logic) every CMake target created by the Conan pybind11 package links to `libpython` (the `pybind11::embed` target is the only one that should). This means that Python extension modules (`pybind11::module`s) link to `libpython`, causing linker errors at runtime or even segfaults due to ODR violations. As of conan-io/conan-center-index#13283 this bug was fixed upstream. However, we still see it because the bug was not fixed for the deprecated `cmake_find_package` generator, which we use. It has not affected us so far because we haven't added in the `Development.Embed` component to our `find_package(Python` call. As soon as we add that component (e.g. for adding the aforementioned Python unit test) we see this problem. So modernise our `conanfile.py` to use the non-deprecated `CMakeDeps` generator. `CMakeDeps` insists on having the `build_type` setting available, so add that. Unfortunately `CMakeDeps` is designed to install dependencies with the same configuration (Release, Debug, etc) as the parent project, which is usually undesirable - we want Release versions of dependencies whilst we develop the project in Debug mode. This is logged upstream in conan-io/conan#11607, where a workaround is posted, which is used here (see code comments). Signed-off-by: David Feltell <david.feltell@foundry.com>
Specify library name and version: pybind11