Vray 4.20.01 linker errors with Intel C++ 19 Update 4 (in Visual Studio 2017)

[MichaelHubbard]

Hello,

There seems to an issue with some linker errors when using the Intel 19 C++ compiler (Update 4) in Visual Studio 2017. We had previously been using successfully been using Vray3.6 with the Intel C++ 15 (in Visual Studio 2012) without issue, but with Visual Studio 2017 and Intel 19 we get multiple errors at link time (some below).

rayserver_s.lib(newdeleteoverload.cpp.obj) : : error LNK2005: "void * __cdecl operator new (unsigned __int64)" (??2@YAPEAX_K@Z) already defined in framework.lib
rayserver_s.lib(embreemeshdistancetree.cpp.obj) : : error LNK2019: unresolved external symbol rtcDeviceNewScene referenced in function "public: __cdecl embree::BVHDistanceTree::BVHDistanceTree(struct __RTCDevice *)"
rayserver_s.lib(embreerayserver.cpp.obj) : : error LNK2001: unresolved external symbol rtcDeviceNewScene

When attempting to build an embree 2.3 or embree 2.7 release to link it, it appears like there are custom rtcNewVRayMesh and rtcGetMemUsage functions which aren't in the main embree releases.

rayserver_s.lib(newdeleteoverload.cpp.obj) : : error LNK2005: "void * __cdecl operator new (unsigned __int64)" (??2@YAPEAX_K@Z) already defined in framework.lib
rayserver_s.lib(embreerayserver.cpp.obj) : : error LNK2019: unresolved external symbol rtcGetMemUsage referenced in function "public: virtual class VUtils::Box __cdecl EmbreeBoxTree::getBoundingBox(void)const "
rayserver_s.lib(embreevoxeltree.cpp.obj): : error LNK2019: unresolved external symbol rtcNewVRayMesh referenced in function "public: virtual void __cdecl EMbreeTree<0,0,class VUtils::StaticTreeDelegateParams

The code using Vray4 will compile with Visual Studio 2017 MSVC compiler, but it seems like when it detects the Intel compiler it causes these linker errors to appear. I have tried including all of the .lib files included in the Vray 4.2 (Max2016) sdk, but nothing seems to be able to properly link. Are there any environment variables or other things that could be done to allow the Intel C++ 19 compiler in VS2017 to be used with Vray4 (so we can continue using an Intel compiler as we did with VRay3)? We did notice speedups in our resulting plugins when the Intel compiler was used previously, and would like to try it again with Vray4 (if possible).

Thanks,
Michael

[yavor.rubenov]

Hello,

Sorry for the delayed reply.

For V-Ray 4 we switched to MSVC with vc14 libs for all V-Ray for 3ds Max builds. Generally this shouldn't be an issue - the Intel compiler should be compatible. Is your plugin intended to be a Max (+V-Ray) plugin or a V-Ray standalone plugin ?
There seems to be two different errors:

• "void * __cdecl operator new (unsigned __int64)" (??2@YAPEAX_K@Z) already defined in framework.lib - is framework.lib one of your libs ? Are you compiling the file newdeleteoverload.cpp from the vraysdk as part of this lib ?
• The other 3 seem embree related. Are you linking to the proper V-Ray lib (vray2016.lib if you are making a Max plugin and vray.lib for standalone plugins).

The embree libs are already linked in the vray lib so you don't need to link you own libs. Linking different embree versions is not supported.

Best regards,
Yavor

[MichaelHubbard]

Hi Yavor,

Thanks for the response. It does seem like two issues. This is targeting a Max plugin (+V-Ray) that is being compiled.

1. It seems like both Vray and the framework.lib (which is a separate library) are overriding the new and delete operators. This only seems to be causing the linker issue with the Intel compiler. The newdeleteoverload.cpp is not included in the framework.lib or the Max plugin. Is there a way to turn off the new and delete overloads in Vray when using the Intel compiler? I am not explicitly setting the "WITH_GLOBALNEWDELETE" but maybe it is being set when the Intel compiler is detected?

2. I have tried linking both the vray2016.lib and vray.lib separately and together, but still get the embree linker issues (but only when using the Intel compiler). Is there a copy of embree that would be compatible with this (or another workaround)?

I will also try running this in Max2020 with the latest version of Vray 4 available, and certainly would appreciate any further suggestions on resolving the issues with the Intel compiler.

Thanks,
Michael

[yavor.rubenov]

There are no specific Intel related defines in the new/delete overloads - we only have some ifdefs about supported features like override keyword etc.. Could you share the compiler and linker command line (without the c++ files list) you are using ?

In the mean time I'll try to install Intel 19 here and to compile something to see if I get the same errors.

[yavor.rubenov]

I tried compiling a test plugin with Intel 19 Update 4 and things seem to work correctly. I've linked to the following libs from the V-Ray SDK:
vutils_s.lib
plugman_s.lib
rayserver_s.lib
vray2018.lib
vrender2018.lib

Then I created some testing geometry plugins inheriting from VRenderInstance and had no problem.
The only problem I saw so far is that if I try to manually create an Embree Ray server in my code with newEmbreeRayServer(); I then need the embree libs which is a problem.

What V-Ray APIs are you trying to use in your project ?

[MichaelHubbard]

Hi Yavor,

Thanks for the response. It looks like the embree linking was from how I had the vray .lib files ordered. Originally what I had was the following:

plugman_s.lib
rayserver_s.lib
vutils_s.lib
vray2016.lib
vrender2016.lib

By moving the vutils_s.lib to the top, it looks like it will properly link the embree functionality in the rayserver_s.lib.

I am still having some issues however with the operator new and operator delete linker issues (LNK2005 defined in vutils_s.lib (newdeleteoverload.cpp.obj) with the Intel compiler. I have tried with both Max2016 and Max2020 versions of Vray 4.20.01, but will see if I can create a small reproducible example of this issue.

Thanks again,
Michael

[MichaelHubbard]

Hi Yavor,

It seems like by recreating the Visual Studio solution again (via CMake) with "vutils_s.lib" as the first linked library the other issues with linking with newdeleteoverload.cpp.obj also went away. I think the confusion was that we had the previous lib order for Vray3 (and Intel15) was also working with VRay4 and Visual Studio 2017 (MSVC compiler) and just not the Intel 19 compiler. It seems to be compiling now as expected with the new order you suggested.

Thanks again,
Michael

[yavor.rubenov]

Glad to hear it is sorted now.