Skip to content
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

Merged
merged 14 commits into from
Oct 14, 2022

Conversation

planetmarshall
Copy link
Contributor

Specify library name and version: pybind11


  • I've read the guidelines for contributing.
  • I've followed the PEP8 style guides for Python code in the recipes.
  • I've used the latest Conan client version.
  • I've tried at least one configuration locally with the conan-center hook activated.

@conan-center-bot

This comment has been minimized.

@planetmarshall
Copy link
Contributor Author

Something is causing pybind to link in libpython which it shouldn't be doing for a module. A modification to the test package can workaround the issue, but I'd still like to get to the bottom of it as it will break consumers using the typical path.

# pybind11 method:
pybind11_add_module(MyModule1 src1.cpp)

Results in a linking error because libpython is linked in

# 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.

See Pybind11 CMake helpers

@ghost
Copy link

ghost commented Oct 3, 2022

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")
Copy link
Contributor Author

@planetmarshall planetmarshall Oct 3, 2022

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.

Copy link
Contributor

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.

@conan-center-bot

This comment has been minimized.

@conan-center-bot

This comment has been minimized.

@conan-center-bot

This comment has been minimized.

jwillikers
jwillikers previously approved these changes Oct 4, 2022
find_package(pybind11 REQUIRED CONFIG)

pybind11_add_module(test_package MODULE test_package.cpp)
#pybind11_add_module(test_package MODULE test_package.cpp)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lingering comment?

Copy link
Contributor Author

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.

@planetmarshall planetmarshall marked this pull request as ready for review October 8, 2022 23:03
@conan-center-bot

This comment has been minimized.

1 similar comment
@conan-center-bot

This comment has been minimized.

@conan-center-bot

This comment has been minimized.

jwillikers
jwillikers previously approved these changes Oct 11, 2022
prince-chrismc
prince-chrismc previously approved these changes Oct 11, 2022
uilianries
uilianries previously approved these changes Oct 13, 2022
@ericLemanissier
Copy link
Contributor

@planetmarshall please close the PR for 10 second then reopen it so that it retriggers a build and finally merge this change

@conan-center-bot

This comment has been minimized.

@uilianries
Copy link
Member

My guess is, it failed with a runtime error. Need to run on Windows to check it.

@conan-center-bot
Copy link
Collaborator

All green in build 12 (430971e3a835eb0c8dd7026e8b7df021c018025b):

  • pybind11/2.7.1@:
    All packages built successfully! (All logs)

  • pybind11/2.8.1@:
    All packages built successfully! (All logs)

  • pybind11/2.9.1@:
    All packages built successfully! (All logs)

  • pybind11/2.10.0@:
    All packages built successfully! (All logs)

  • pybind11/2.9.2@:
    All packages built successfully! (All logs)

@conan-center-bot conan-center-bot merged commit 1c28d5c into conan-io:master Oct 14, 2022
feltech added a commit to feltech/OpenAssetIO that referenced this pull request Nov 23, 2022
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>
feltech added a commit to feltech/OpenAssetIO that referenced this pull request Nov 23, 2022
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>
feltech added a commit to feltech/OpenAssetIO that referenced this pull request Nov 25, 2022
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>
feltech added a commit to feltech/OpenAssetIO that referenced this pull request Nov 28, 2022
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>
@planetmarshall planetmarshall deleted the pybind11-fix-linkage branch March 4, 2024 22:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants