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.

Sign up for GitHub

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

Jump to bottom

Linking problem with host portion of CUDA kernels for CMake >= 3.15 #109

Closed
martinschwinzerl opened this issue Nov 7, 2019 · 3 comments
Closed

Linking problem with host portion of CUDA kernels for CMake >= 3.15 #109

martinschwinzerl opened this issue Nov 7, 2019 · 3 comments
Labels
bug C++ cmake cuda Problems related to the CUDA architecture backend and/or technologies like pycuda, numba or cupy

Comments

@martinschwinzerl
Copy link
Contributor

It seems that the mangled c++ symbols for the host side of cuda kernels are not exported by the shared library and causes problems during linking of applications (even non-cuda ones):

Scanning dependencies of target dump_cbuffer
[ 27%] Building C object tools/CMakeFiles/dump_cbuffer.dir/dump_cbuffer.c.o
[ 27%] Linking C executable dump_cbuffer
../sixtracklib/libsixtrack.so: undefined reference to `__cudaRegisterLinkedBinary_55_tmpxft_000026c9_00000000_6_managed_buffer_remap_cpp1_ii_da9df0a7'
../sixtracklib/libsixtrack.so: undefined reference to `__cudaRegisterLinkedBinary_57_tmpxft_000026ae_00000000_6_extract_particles_addr_cpp1_ii_90dc0973'
../sixtracklib/libsixtrack.so: undefined reference to `__cudaRegisterLinkedBinary_64_tmpxft_00002678_00000000_6_be_monitors_assign_out_buffer_cpp1_ii_54dd6e05'
../sixtracklib/libsixtrack.so: undefined reference to `__cudaRegisterLinkedBinary_50_tmpxft_000026e4_00000000_6_track_particles_cpp1_ii_c22b58a6'
../sixtracklib/libsixtrack.so: undefined reference to `__cudaRegisterLinkedBinary_65_tmpxft_00002693_00000000_6_elem_by_elem_assign_out_buffer_cpp1_ii_2a58a681'
collect2: error: ld returned 1 exit status
tools/CMakeFiles/dump_cbuffer.dir/build.make:88: recipe for target 'tools/dump_cbuffer' failed
make[2]: *** [tools/dump_cbuffer] Error 1
CMakeFiles/Makefile2:2253: recipe for target 'tools/CMakeFiles/dump_cbuffer.dir/all' failed
make[1]: *** [tools/CMakeFiles/dump_cbuffer.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2

The same source code compiles and links successfully under cmake < 3.15. May have something to do with LINKER_LANGUAGE=C setting for sixtrack_cuda_device and sixtrack_cuda_host which always seemed a bit fishy to me.
@martinschwinzerl martinschwinzerl added bug C++ cmake cuda Problems related to the CUDA architecture backend and/or technologies like pycuda, numba or cupy labels Nov 7, 2019
@martinschwinzerl martinschwinzerl mentioned this issue Nov 7, 2019
Closed
@aoeftiger
Copy link
Contributor

👍 😄

@aoeftiger aoeftiger mentioned this issue Oct 19, 2020
Closed
martinschwinzerl added a commit to martinschwinzerl/sixtracklib that referenced this issue Oct 21, 2020
@martinschwinzerl
sixtracklib/cuda: attempts to fix linking issue with CMake > 3.14.x
1ce557c 
- The flag CUDA_RESOLVE_DEVICE_SYMBOLS should be enabled by default on
  shared libraries like SixTrackLib. The property does not work on
  OBJECT libraries like sixtrack_cuda_device. It seems that starting
  with cmake 3.15, cmake did not pick up the property for the resulting
  compound SHARED library just by inferring the dependency on the CUDA
  device part.

  This fix attempts to rectify this by adding the property explicitly
  to the SHARED sixtracklib library if the sixtrack_cuda_device
  target is present.

  Tested on CMake 3.14, 3.16 und 3.18 -> seems to work

- Note: this would fix issue SixTrack#109 but more investigation is required whether
  this solves all problems encountered therein
@martinschwinzerl
Copy link
Contributor Author

Fixed by #132 , commit 1ce557c

martinschwinzerl added a commit to martinschwinzerl/sixtracklib that referenced this issue Oct 22, 2020
@martinschwinzerl
sixtracklib/cuda: attempts to fix linking issue with CMake > 3.14.x
762615c 
Backported from #PR130

- The flag CUDA_RESOLVE_DEVICE_SYMBOLS should be enabled by default on
  shared libraries like SixTrackLib. The property does not work on
  OBJECT libraries like sixtrack_cuda_device. It seems that starting
  with cmake 3.15, cmake did not pick up the property for the resulting
  compound SHARED library just by inferring the dependency on the CUDA
  device part.

  This fix attempts to rectify this by adding the property explicitly
  to the SHARED sixtracklib library if the sixtrack_cuda_device
  target is present.

  Tested on CMake 3.14, 3.16 und 3.18 -> seems to work

- Note: this would fix issue SixTrack#109 but more investigation is required whether
  this solves all problems encountered therein
@martinschwinzerl
Copy link
Contributor Author

Closing due to merge of PR #132 into the main branch, please re-open if the problem persists

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug C++ cmake cuda Problems related to the CUDA architecture backend and/or technologies like pycuda, numba or cupy
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@aoeftiger @martinschwinzerl