Export of CRT functions causing linker to fail against code compiled with /CLR

[kwende]

I'm going to give the debug flags, but this same issue happens in release mode.

We have a static library (we'll call it "Library A") being built without /clr and with /MDd that links in the storage API. We build the storage API using .\vcpkg.exe install azure-storage-blobs-cpp:x64-windows (so all CRT linking should be dynamic).

We then have a dynamic C++/CLR library (call it "Library B") built with /clr and /MDd that links in Library A.

So, in summary: Library B links in Library A that links in the storage API built with dynamic CRT options.

However, Library B fails to build because of dozens of LNK2005 errors, all seemingly related to the CRT. An example:

I'm uncertain why CRT functions are being exported by the storage API, but they are. In fact, if you examine the .def files generated during the build of the Azure C++ libraries, you see the CRT functions are included in it. After some examination, it seems as though "CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS" is being used, might this be the cause? Regardless, it seems as though the export of these functions is causing issues with the build options we require for our libraries.

What can I do to link in the Azure storage C++ libraries when CRT functions appear multiply defined as they are?

[kwende]

Indeed, moments after posting this I happened upon another SO post where someone (a maintainer of another library) happened upon the same issue w/ a consumer here: https://stackoverflow.com/a/53424589/10498104.

Would it be insurmountable to turn off CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS?

[Jinming-Hu]

Hi @kwende , this library has been deprecated in favor of https://github.com/Azure/azure-sdk-for-cpp/tree/main/sdk/storage. Please switch to the new library.