koobas.hobune.stream
How to enable '-fdeclspec' or '-fms-extensions' compiler options to compile C++ source code in project?
I'm trying to have C++ source code in my project compiled when I build it instead of having a library instead to avoid the performance costs of P/Invoke.
Following the instructions here: https://docs.unity3d.com/2019.3/Documentation/Manual/macOSPlayerCPlusPlusSourceCodePluginsForIL2CPP.html
I've got the C++ code in Assets/Plugins/Mac/x86_64/NativeFunctions.cpp and the import settings set to Standalone/Mac OS X x64.
When I try to build and run I get this error (and warning):
[ERROR] FATAL UNHANDLED EXCEPTION: Unity.IL2CPP.Building.BuilderFailedException: /Users/....../project/Temp/StagingArea/Data/il2cppOutput/NativeFunctions.cpp:1:15: error: '__declspec' attributes are not enabled; use '-fdeclspec' or '-fms-extensions' to enable support for __declspec attributes
<U+FEFF>extern "C" __declspec(dllexport) int __stdcall CountLettersInString(wchar_t* str)
^
/Users/...../project/Temp/StagingArea/Data/il2cppOutput/NativeFunctions.cpp:1:41: warning: '__stdcall' calling convention is not supported for this target [-Wignored-attributes]
<U+FEFF>extern "C" __declspec(dllexport) int __stdcall CountLettersInString(wchar_t* str)
^
1 warning and 1 error generated.
I'm using Unity 2020.1.8f1 on OS X 10.15.7.
Is there anyway I'm able to customize the compiler's arguments? Specifically so I can add -fdeclspec to the clang++ invocation.
Note that compiling this native code with the project won't avoid the performance costs of marshaling for p/invoke. That will still be necessary. Compiling with the project just provides a quick way to compile the native code.
I would recommend that you compile this native code separately as a library, that way you can use the specific compiler flags that you need.
Regardless of the performance benefits, how do we get the c++ to compile? The documented function decoration, as used by the OP does not compile for me either. With the same error.
Hi Thanks for the reply.
Quoting from the link above;
This significantly decreases the performance overhead of a P/Invoke call.
Am I misunderstanding something?
Yes, the performance improvement is not due to the lack of marshaling for the p/invoke call. All of that marshaling will happen no matter how native code is built.
The performance improvement is due to the fact that the native linker must link the method statically, rather than dynamically, so with link time optimization enabled, the linker can optimize across that function call. You can get this same benefit by compiling the native code separately into a static library.
