search

AaronRobinsonMSFT / DNNE

Prototype native exports for a .NET Assembly.
MIT License
397 stars 41 forks source link

compile error with VS2017 but works with VS2019 #69

Closed tvogel-nid closed 3 years ago

tvogel-nid commented 3 years ago

this call fails with EXEC : fatal error C1007: unrecognized flag '-NoRTTI' in 'p2'

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x64\cl.exe" /O2 /LD /TC /MT /GS /Zi /D DNNE_ASSEMBLY_NAME=NationalInstruments.VectorCalLib.API /D DNNE_COMPILE_AS_SOURCE /I "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\include" /I "C:\Users\labviewbuild.nuget\packages\dnne\1.0.19\tools\platform" /I "C:\agent\w_tool\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\5.0.4\runtimes\win-x64\native" /I "C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\shared" /I "C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um" /I "C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\ucrt" "C:\agent\w\2\s\Objects\NetCore\VectorCalLib.API.NetCore\Release\dnne\NationalInstruments.VectorCalLib.API.g.c" "C:\Users\labviewbuild.nuget\packages\dnne\1.0.19\tools\platform\platform.c"
/link /DLL /LTCG /LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.16.27023\lib\x64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.17763.0\um\x64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.17763.0\ucrt\x64" "C:\agent\w_tool\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\5.0.4\runtimes\win-x64\native\libnethost.lib" Advapi32.lib /IGNORE:4099 /IMPLIB:"C:\agent\w\2\s\Objects\NetCore\VectorCalLib.API.NetCore\Release\dnne\bin\NationalInstruments.VectorCalLib.APINE.lib" /OUT:"C:\agent\w\2\s\Objects\NetCore\VectorCalLib.API.NetCore\Release\dnne\bin\NationalInstruments.VectorCalLib.APINE.dll

but this call passes: "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\bin\Hostx64\x64\cl.exe" /O2 /LD /TC /MT /GS /Zi /D DNNE_ASSEMBLY_NAME=NationalInstruments.VectorCalLib.API /D DNNE_COMPILE_AS_SOURCE /I "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\include" /I "C:\Users\tvogel.nuget\packages\dnne\1.0.19\tools\platform" /I "C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\5.0.4\runtimes\win-x64\native" /I "C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\shared" /I "C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\um" /I "C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt" "C:\ws\git\ASW\Objects\NetCore\VectorCalLib.API.NetCore\Release\dnne\NationalInstruments.VectorCalLib.API.g.c" "C:\Users\tvogel.nuget\packages\dnne\1.0.19\tools\platform\platform.c"
/link /DLL /LTCG /LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\lib\x64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\um\x64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\ucrt\x64" "C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\5.0.4\runtimes\win-x64\native\libnethost.lib" Advapi32.lib /IGNORE:4099 /IMPLIB:"C:\ws\git\ASW\Objects\NetCore\VectorCalLib.API.NetCore\Release\dnne\bin\NationalInstruments.VectorCalLib.APINE.lib" /OUT:"C:\ws\git\ASW\Objects\NetCore\VectorCalLib.API.NetCore\Release\dnne\bin\NationalInstruments.VectorCalLib.APINE.dll"

AlexGer123 commented 3 years ago

https://stackoverflow.com/questions/20936074/getting-fatal-error-c1007-unrecognized-flag-archvfpv3-d32-in-p2-error-wh

Maybe not a DNNE problem....

tvogel-nid commented 3 years ago

I agree, it might not be a bug a all, but as DNNE handles the compilation (and therefore the selection of the CL version and the LIBPATHS) under the hood I'm basically looking for a hint whether there might be switch/setting/whatever to solve this problem.

AaronRobinsonMSFT commented 3 years ago

@tvogel-nid This is quite likely a scenario bug that may not be easily fixed - boo. I think the issue is between how the CoreCLR's nethost.lib is built and how one is using DNNE. CoreCLR tends to build on the latest VS, in this case VS2019, but this scenario is consuming that lib in VS2017 - which causes the issue. It isn't immediately obvious how to make this work because we are dependent on the compiled lib in CoreCLR to be backwards compatible with previous compilers.

I think this should cause at least a conversation about how .NET thinks about its nethost.lib scenario from a backwards compat perspective.

/cc @vitek-karas @elinor-fung

tvogel-nid commented 3 years ago

Yes, in my company we have a somehow uncommon scenario at our build machines, we have that the .NET Framework build requires VS2017 to be installed on the built agents, but the .NET Core build does not require Visual Studio to be installed at all - because it is just using the .NET SDK and here we used the relative new version 5.0.104 Seems the real solution will be to convince the right people to update to VS2019 on our build machines