Building from source, getting the procedure entry point ?mutable_grad@AutogradMeta could not be located in the dynamic link library error

I’m trying to build libtorch in debug configuration with /MTd. the release works just fine but the debug has been giving me headaches ever since. In my latest attempt I managed to get it to build just fine, and get rid of the damning 0xc0000142 error that I was getting.
But now for some weird reasons that I can not fathom I get this linker like error at runtime!:

The procedure entry point ?mutable_grad@AutogradMeta@autograd@torch@@UEAAAEAVTensor@at@@XY could not be located in the dynamic link library

What am I missing here? Whats wrong?
I could really use and greatly appreciate some help in this
Thank you all in advance

@peterjc123 Can you help?

Have you copied the DLLs to the directory of your target executable?

Hi, you are right, torch_cpu.dll was missing and hence I was getting this error.
When I rebuilt everything I went back to square one! :pensive:
That is I’m back at solving what is causing this :
which pressing on the retry ultimately shows the infamous 0xc0000142 (DLL initialization failed):
Do you by any chance know how I can dig deeper and find the culprit?
To give you an idea of how I went about making /MD into MT, first of all, I simply ran cmake-gui
and then under CMakegroup changed all MD flags to /MT like this :

and then I went ahead and added this ugly hack to nearly all CMake files that without this hack would issue a build error (because of md vs mt mismatch) :

# -- MT 
foreach(CompilerFlag ${CompilerFlags})
  string(REPLACE "/MD" "/MT" ${CompilerFlag} "${${CompilerFlag}}")

This seemingly fixed the building process, but somewhere in there, there must be a mismatch happening, that causes c10.dll to fail. This doesn’t happen in release mode, only the debug has this issue and I’m clueless as to how to go about fixing it.
Previously I had generated a VS project with everything in their defaults and then changed the properties through VisualStudio (i.e. changed all MDs to MTs from project properties) and managed to build just fine. but then again the debug would behave the same way at runtime. This was why I tried changing the cmake and see if it makes a change and obviously, it does not.

What could have caused this? a mismatch between the C++ versions? (they are built as C++14 but my own project uses C++17. if this was the case, why wouldn’t release have any issues then? if it’s not this, then what else could be wrong? where should I dig in next?

Update 1:

Looking at the DLLs built with MD and MT respectively, I can see couple of differences.
The import table and export tables are different:
C10.dll (MDd) / C10.dll (MTd)

Exports(684 vs 676):


In case its of any use, here are the full logs for each of them :
C10.dll.txt info (MDd) :
C10.dll.txt info (MTd) :

For comparison, in release configureation for example, despite the differences between the MD and MTbuilds, the exports are the same :

Update 2:

I rebuilt the c10.dll separately and the MT version’s export now matches the MD’s but the exception still happens! :pensive:
What could be the cause here?

Update 3:

I guess I might have found out the cause of all this. its because the shared_lib is on! it doesn’t issue any warnings/ apparent errors in release mode, but it doesn’t mean it’s fine either. the debug obviously fails because of this so release ought to have some issues as well.
building statically has the issue that I get maximum size related error, so I need to find a way to exclude some libs I guess, not sure if that’s possible but will try my best and see how this goes.
For the refs this, and this and this may be useful to others as well.

I’ll be working on this and see what I can do, but I could really use a helping hand in this. any kind of tips is greatly appreciated.
Thank you very much in advance