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

MSB8066 Error #17

Closed
bipul-mohanto opened this issue Dec 16, 2021 · 5 comments
Closed

MSB8066 Error #17

bipul-mohanto opened this issue Dec 16, 2021 · 5 comments

Comments

@bipul-mohanto
Copy link

Hi!
First I tried to build the repository with OptiX 7.4 and CUDA 11.5. However, as of the older dependencies, that did not work.

Later I tried to build the repository for OptiX 6.5.0, and CUDA 10.0 with MSVS 2019 (64bit) following the discussion (https://forums.developer.nvidia.com/t/build-errors-in-optix-advanced-samples/107275).

Unfortunately, the building process with CMake was success, but while opening the .sln and opening any project (as startup project), it is not working showing the MSB8066 Error. How can I get rid of it and run the sample codes? Here is a screen shot:

three

@droettger
Copy link
Collaborator

droettger commented Dec 16, 2021

I'm guessing that you either didn't set the CUDA_HOST_COMPILER correctly inside the CMake GUI or didn't select the x64 platform target.

CUDA_HOST_COMPILER should point to the proper MSVS 2019 x64 version of cl.exe. Looks like this on my machine:
C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/MSVC/14.29.30133/bin/Hostx86/x64
(Probably also works with Host64/x64.)

I have no issues building these examples with CUDA 10.2 (I don't have CUDA 1.0 installed), MSVS 2019, OptiX SDK 6.5.0, and CMake 3.17.3.

Since that CUDA_HOST_COMPILER assignment is broken inside the FindCUDA scripts present inside this legacy repository for MSVS versions 2017 and above which have then in a different location than MSVS 2015 and earlier, you could also rename or delete the FindCUDA folder and FindCUDA.cmake script in your local repository.

That local FindCUDA versions was only required for very old CMake versions which hadn't the correct code, yet.
Newer CMake versions have a corrected and surpassed that one (and the newest CMake versions actually deprecated the FindCUDA script in favor of the FindCUDAToolkit script).

Means when using CMake's version of the FindCUDA.cmake it will correctly set the CUDA_HOST_COMPILER automatically. Somebody else claimed in an issue that this was not actually working but I don't see that.
(Again, I'm using CMake 3.17.3 and I would recommend this renaming method of the FIndCUDA folder and *.cmake.)

In my case it will set CUDA_HOST_COMPILER to
$(VCInstallDir)Tools/MSVC/$(VCToolsVersion)/bin/Host$(Platform)/$(PlatformTarget)

Make sure you have set the CMake "Optional Platform for Generator" field to x64 or nothing will work.

I tried both methods just now and I don't see the issue you're reporting. Both "Rebuild Solution" runs for Release and Debug targets built without errors when having the FindCUDA folder and FindCUDA.cmake renamed.

In any case, I do not recommend using any of these outdated OptiX API based examples for development today
New developments should be done with the more modern OptiX 7 API which will always be faster and more flexible.

@droettger
Copy link
Collaborator

Another reason for NVCC to fail would be if you still used the CUDA 11.x toolkit because the translation to PTX uses the Kepler Streaming Multiprocessor target 3.0 in these projects which is not supported inside CUDA 11.x anymore.

Which CUDA toolkit version is used inside the CMake generator is selected by the environment variable CUDA_PATH.
Check if that is pointing to the correct CUDA 10.x installation and if not change the environment variable before opening the CMake GUI program.

You should be able to see if the correct CUDA toolkit is used inside the Cmake GUI CUDA variables.
After loading the solution into the MSVS IDE you can also check if everything is correctly referenced by looking at any of the projects' properties and reading the compiler and linker command line entries.

Unfortunately MSVS doesn't report the actual errors of custom build steps by default or it would have been clear immediately what the actual problem is in your case.

When you ever see that a custom nvcc rule fails, you can get the nvcc compiler output by raising the verbosity inside MSVS via
Menu Tools -> Options -> Projects and Solutions -> Build and Run
Default is Minimal which only outputs that it failed. Raise it to Normal to get the actual nvcc compiler errors.

@bipul-mohanto
Copy link
Author

Hi @droettger,

I sincerely thanks for your assistance. You were right, the problem was CUDA_HOST_COMPILER path during the CMake Configuration. I manually select the path to the appropriate cl.exe (that is okay for me). Besides, I have used OptiX6.5 with CUDA 10.1 extension 2. Although I did not find the IL_LIBRARIES in the DevIL Windows SDK I download, but your sample codes are working perfectly. Here I have attached a screen shot of the CMake configuration, hope it will help others in future.

git

@bipul-mohanto
Copy link
Author

bipul-mohanto commented Dec 27, 2021

cap

@droettger
Copy link
Collaborator

The IL_LIBRARIES needs to point to the DevIL.lib in your DevIL installation.
It's inside the same folder as your ILU.lib and ILUT.lib files.
It's just not named IL.lib under Windows.

The 3rd party dependencies are found more automatically inside the newer OptiX 7 examples I linked above.

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

No branches or pull requests

2 participants