Hi James,
Thanks for the quick reply! As I mentioned, we've hit two issues. The
first is the project dependencies one, which I'll try and describe more
a bit below. I'm not a CMake expert, so please bear with me.
The second is what I've put under 2).
The only CMake build dependency changes when doing separable compilation
are found in CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS. Basically what
this does is create a new rule to build an intermediate link file. For
everything but some versions of MSVC generators it adds a custom command
to generate this intermediate link file. The other case adds a custom
command that runs as a PRE_LINK command to generate the object file (the
reasons for this is a bug in VS custom command dependency scanning), but
this should happen during link phase and not compile phase.
Nothing in here should change what happens before the target is built,
though.
1) Okay, I understand that, but I do think we saw a different behaviour
when we switched to separable compilation. Let me describe what we are
doing.
We generate part of our library from a simple program (call the simple
program 'gen', which generates a source file 'gen.hpp') that we want to
execute before compiling our library (call our library 'main'). We set
this up with the following:
- add_executable(...) is called for 'gen'
- add_custom_command(...) sets up a command that executes 'gen'
- set_source_files_properties(...) is called to set 'gen.hpp' as having
the PROPERTY of GENERATED
- add_dependencies(main gen) is called to establish 'main' depends on 'gen'
So far, this has only failed for CUDA with separable compilation. (It
has worked for all of our other configurations. including CUDA without
separable compilation.)
Have we done something wrong? Is there some additional information we
can look at to figure out what's going on?
2) A second problem we've run into is an error when trying to link a
CUDA shared library with separable compilation. This is specifically a
Linux problem, on Mac it is fine. A static library is also fine, working
for both Linux and Mac.
The particular error is "relocation R_X86_64_32S against
`__nv_module_id' can not be used when making a shared object; recompile
with -fPIC". However, we are already compiling with -fPIC. I can confirm
that -fPIC appears to be passed to both the host compiler for non-CUDA
source and via -Xcompiler -fPIC for CUDA source.
This error occurs when trying to link all the different object files
together of our library.
Do you have any idea of what this could be?
--
Thanks for all of your help.
Cheers,
Irwin
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
