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

-fPIC compile error #35

Closed
dave992 opened this issue Jun 8, 2020 · 4 comments · Fixed by #36
Closed

-fPIC compile error #35

dave992 opened this issue Jun 8, 2020 · 4 comments · Fixed by #36

Comments

@dave992
Copy link
Contributor

dave992 commented Jun 8, 2020

On my system, I ran into the following error when compiling:

/usr/bin/ld: libyak.a(device_memory.cpp.o): relocation R_X86_64_PC32 against symbol `_ZN7kfusion4cuda5errorEPKcS2_iS2_' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value

I'm not sure what caused this, as I've successfully compiled the library in the past. Perhaps a new version of CMake or other libraries involved changed something?

Anyway, going through the generated CMake files I saw that the -fPIC flag was only added during the compiling of the .cu CUDA files and not for the regular .cpp files while creating the libyak library which in turn caused the error shown above.

@dave992
Copy link
Contributor Author

dave992 commented Jun 8, 2020

I've submitted a PR (#36) which adds the missing flag and fixes the compile error.

@schornakj
Copy link
Contributor

Anyway, going through the generated CMake files I saw that the -fPIC flag was only added during the compiling of the .cu CUDA files and not for the regular .cpp files while creating the libyak library which in turn caused the error shown above.

I think that's because the -fPIC flag is added to CUDA_NVCC_FLAGS before the libyak library is built:

https://github.com/ros-industrial/yak/blob/742d0cb55461be9782c3b5993956c25a49527734/yak/CMakeLists.txt#L59

I had issues similar to this error when I was refactoring this package last year. At the time my "solution" was to keep linking libyak against ${PCL_LIBRARIES}, which I think adds the -fPIC flag. This shouldn't be necessary and frankly it's messy, bad, and reliant on PCL behaving consistently, and the fix in your PR solves the core problem in a much better way.
https://github.com/ros-industrial/yak/blob/742d0cb55461be9782c3b5993956c25a49527734/yak/CMakeLists.txt#L79-L84

I'm not sure what caused this, as I've successfully compiled the library in the past. Perhaps a new version of CMake or other libraries involved changed something?

A possible explanation is that something changed in your version of PCL and it no longer exposes the -fPIC flag to targets that link against the PCL libraries.

@schornakj
Copy link
Contributor

Also, this is tangentially related to #13. CMake adds the -fPIC flag to SHARED libraries by default, and if we were using CUDA as a first-class language we would probably have built libyak as a shared library to begin with.

@dave992
Copy link
Contributor Author

dave992 commented Jun 8, 2020

I think that's because the -fPIC flag is added to CUDA_NVCC_FLAGS before the libyak library is built:

https://github.com/ros-industrial/yak/blob/742d0cb55461be9782c3b5993956c25a49527734/yak/CMakeLists.txt#L59

My CMake knowledge is limited, but it seems the nvcc compiler (and therefore the CUDA_NVCC_FLAGS) is only used for the CUDA files. As the .cpp files don't use nvcc they do not inherit the flag, which is quite confusing behavior to me as I would expect the complete library to be compiled with nvcc when using the cuda_add_library.

I had issues similar to this error when I was refactoring this package last year. At the time my "solution" was to keep linking libyak against ${PCL_LIBRARIES}, which I think adds the -fPIC flag. This shouldn't be necessary and frankly it's messy, bad, and reliant on PCL behaving consistently, and the fix in your PR solves the core problem in a much better way.

I saw that comment indeed but was unsure how this fixed the problem then. PCL not being consistent may actually be the cause of this change in compile behavior.

A possible explanation is that something changed in your version of PCL and it no longer exposes the -fPIC flag to targets that link against the PCL libraries.

I recently installed PCL 1.9 (for Noether) which can indeed be the reason this is now causing compile errors. I just tried commenting out the ${PCL_LIBRARIES} line in addition to the changes in this PR and the library then still compiles correctly. I will add this to the PR then.

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 a pull request may close this issue.

2 participants