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

Linking problems with CMake + MinGW + pybind11::embed #1915

Closed
sgsaenger opened this issue Sep 9, 2019 · 1 comment
Closed

Linking problems with CMake + MinGW + pybind11::embed #1915

sgsaenger opened this issue Sep 9, 2019 · 1 comment

Comments

@sgsaenger
Copy link
Contributor

I have a project that consists of three parts:

  • a library
  • standalone python-bindings (created via pybind11_add_module)
  • a qt-based GUI

Now, I want to include python in the GUI via target_link_libaries(vipster pybind11::embed).

What works:

  • building on Linux
  • building the bindings on windows
  • building the GUI without python support on windows

If i try to to build the GUI with Python support though, it fails at the linking stage with

ld.exe: final link failed: File truncated
collect2.exe: error: ld returned 1 exit status

Compiling does not throw any warnings. An example build can be found here. Note that I also tried disabling LTO to no effect, so this can be disregarded from the output.
Curiously, this failing build also invalidates some files that had previously been built correctly.
If make is executed anew, it (succesfully, but unnecessarily) re-links the library and then throws a ton of undefined reference when linking the standalone bindings. For any further build to succeed, i have to do a make clean.

Tried versions:

  • cmake 3.12.3, 3.15.2
  • mingw 7.3.0, 8.1.0
  • pybind11 2.2.4, 2.3.0
@sgsaenger
Copy link
Contributor Author

The problem was having two similarly named cmake-targets.
Having the library target "libvipster" with OUTPUT_NAME "vipster" leads to an import library called "libvipster.dll.a" (using mingw).
Something in pybind makes the compiler also create an import library for the executable target called "vipster", which therefore overwrites the library's import library with its own.
I don't know if any of this is unintended behavior, at least it is circumventable by issuing a custom IMPORT_PREFIX or IMPORT_SUFFIX to one of the cmake-targets.

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

No branches or pull requests

1 participant