Missing symbols in MSVC C++ compilation, many headers fail to compile #1006
Comments
|
Thanks for the report! We very recently made efforts to catch issues where libcu++ breaks when NVCC is not present. I'll follow up with your reproducer to see what we may have missed. I distinctly remember fixing a similar sounding atomic macro that was missing... |
|
NVIDIA/libcudacxx#340 has changes that seem relevant. |
|
Thanks for the reply! Having moved from the version of
Summary of fixes needed by version:
I apologize for not trying top-of-tree initially; I looked to see if the code relating to the I also saw #968 and #940 after posting the issue (only looked back two pages in the issues, not three 🙃 ), but I'm glad things have changed since then. The value of a library which works across host and device is substantially limited if the host code can't be compiled with a normal host compiler. If there were fundamental incompatibilities that would be one thing, but these are just a few missing symbols and tweaks to a few templates. |
jrhemstad
added
thrust
`_D1` and `_D2` are macros defined in MSVC xmath.hpp #fixes Missing symbols in MSVC C++ compilation, many headers fail to compile #354
|
@lpisha thanks alot for the detailed description and reproducer. AFAIK we fixed the |
`_D1` and `_D2` are macros defined in MSVC xmath.hpp #fixes Missing symbols in MSVC C++ compilation, many headers fail to compile #354
`_D1` and `_D2` are macros defined in MSVC xmath.hpp #fixes Missing symbols in MSVC C++ compilation, many headers fail to compile #354
* Move functors like `plus` into their own file * Move `unary_negate` into its own file * Move `binary_negate` into its own file * Move `binder1st` into its own file * Move `binder2nd` into its own file * Move `pointer_to_unary_function` into its own file * Move `pointer_to_binary_function` into its own file * Move `mem_fun_ref` into its own file * Move `mem_fn` into its own file * Move `bind` to its own file * Add `perfect_forward` helper struct to <functional> * Move `not_fn` into its own file * Move `__is_transparent` helper to its own file * Implement C++20 `bind_front` also backport it to C++17 as we will need it for ranges * Add `__bind_back` helper method to functional * Add `__compose` helper method to functional * Move `default_searcher` to its own file * Move `function` to its own file * Fix compilation issues with MSVC `_D1` and `_D2` are macros defined in MSVC xmath.hpp #fixes Missing symbols in MSVC C++ compilation, many headers fail to compile #354 * Fix missing abort in unreachable.h --------- Co-authored-by: Wesley Maxey <wesley.maxey@gmail.com>
Simple reproducer and more info at this repo: https://github.com/lpisha/test_cudastd_msvc
This is in the context of projects which contain both C++ and CUDA source files, where the C++ files are compiled with MSVC and the CUDA files with nvcc. The project uses the CUDA Standard Library across host and device code, so common headers which get included by both .cpp and .cu files include parts of the CUDA Standard Library.
During C++ compilation, two headers in the CUDA Standard Library,
<cuda/std/limits>and<cuda/std/atomic>, expect that MSVC will have declared / defined certain symbols, but it has not, causing compilation errors. About half of the headers in the CUDA Standard Library include these two headers, making much of the library unusable.This bug does not arise in the compilation of .cu files with nvcc, only in the compilation of .cpp files with MSVC.
The issues with
<cuda/std/limits>were introduced between VS 2019 and VS 2022 due to changes to the MSVC headers. The issues with<cuda/std/atomic>do not appear to be version-related; it appears that thelibcudacxxcode could never have worked on MSVC in the C++ context.Please see the README at https://github.com/lpisha/test_cudastd_msvc for more info.
The text was updated successfully, but these errors were encountered: