ros-industrial / yak

A library for integrating depth images into Truncated Signed Distance Fields.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

-fPIC compile error

dave992 opened this issue · comments

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.

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

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:

list(APPEND CUDA_NVCC_FLAGS "--compiler-options -fPIC")

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.

yak/yak/CMakeLists.txt

Lines 79 to 84 in 742d0cb

target_link_libraries(${PROJECT_NAME}
${OpenCV_LIBRARIES}
${CUDA_LIBRARIES}
${CUDA_CUDA_LIBRARY}
${PCL_LIBRARIES} # BUG: shouldn't need this, but get -fPIC errors if it's not included
Eigen3::Eigen)

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.

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.

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

list(APPEND CUDA_NVCC_FLAGS "--compiler-options -fPIC")

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.