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

Fix the build of the Python bindings. #387

Merged
merged 3 commits into from
Aug 22, 2024

Conversation

robquill
Copy link
Contributor

When attempting the build the Python bindings like this:

cmake -DKOMPUTE_OPT_BUILD_PYTHON=ON ..
make

I get this error:

[100%] Linking CXX shared module ../lib/kp.cpython-310-x86_64-linux-gnu.so
lto-wrapper: warning: using serial compilation of 2 LTRANS jobs
/usr/bin/ld: ../lib/libfmt.a(format.cc.o): warning: relocation against `stdout@@GLIBC_2.2.5' in read-only section `.text'
/usr/bin/ld: ../lib/libkompute.a(Algorithm.cpp.o): relocation R_X86_64_PC32 against symbol `_ZTINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[2]: *** [python/CMakeFiles/kp.dir/build.make:102: lib/kp.cpython-310-x86_64-linux-gnu.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:373: python/CMakeFiles/kp.dir/all] Error 2
make: *** [Makefile:156: all] Error 2

@axsaucedo
Copy link
Member

Thank you for the contribution @robquill - this could make sense, but could you expand what this flag would do in context of the broader codebase? Asking as if it's more of a corner case for a particular use-case, it may make more sense adding this on the respective project cmake file as opposed to by default to the repo to all targets

@robquill
Copy link
Contributor Author

My understanding is that building a shared object requires position-independent code (https://stackoverflow.com/questions/57649452/why-must-shared-libraries-be-position-independent-while-static-libraries-dont), so I could try only setting this option if -DKOMPUTE_OPT_BUILD_PYTHON=ON is set.

I don't think you can only set it e.g. for the Pybind11 module itself as that shared library is still built using the static libraries which would still contain position dependent code.

Signed-off-by: Robert Quill <robert.quill@imgtec.com>
Doing so is a partial fix for building with -DKOMPUTE_OPT_BUILD_TESTS=ON
-DKOMPUTE_OPT_BUILD_PYTHON=ON but there are still undefined symbols at
link time.

Building either the tests or the Python bindings works correctly.
Building both at the same time still does not work.

Signed-off-by: Robert Quill <robert.quill@imgtec.com>
Position-independent code is only required when building a shared
object.

Signed-off-by: Robert Quill <robert.quill@imgtec.com>
@axsaucedo
Copy link
Member

axsaucedo commented Aug 21, 2024

so I could try only setting this option if -DKOMPUTE_OPT_BUILD_PYTHON=ON is set

From my understanding position independent code is glowingly the default in more modern distros, and it may indeed be the case that restricting it to only -DKOMPUTE_OPT_BUILD_PYTHON=ON may be the way to go, as I can't think of a corner case at this stage (unless someone wants to build static vs dynamic version of python although haven't tried if possible)

@robquill
Copy link
Contributor Author

so I could try only setting this option if -DKOMPUTE_OPT_BUILD_PYTHON=ON is set

From my understanding position independent code is glowingly the default in more modern distros, and it may indeed be the case that restricting it to only -DKOMPUTE_OPT_BUILD_PYTHON=ON may be the way to go, as I can't think of a corner case at this stage (unless someone wants to build static vs dynamic version of python although haven't tried if possible)

OK then, that is already done, so I think this should be good to go.

Copy link
Member

@axsaucedo axsaucedo left a comment

Choose a reason for hiding this comment

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

LGTM

@axsaucedo axsaucedo merged commit 4712657 into KomputeProject:master Aug 22, 2024
8 checks passed
@robquill robquill deleted the python_build_fix branch September 5, 2024 08:53
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.

2 participants