Monogame: Rebuild libmojoshader_64.dll to statically link against runtime

[tomspilman]

Currently the libmojoshader_64.dll for is dynamically linked to the C runtime. This means when libmojoshader_64.dll is loaded it looks for MVSC120.dll installed on the system. If this version of the C runtime isn't installed you get a generic error like...

System.DllNotFoundException: Unable to load DLL 'libmojoshader_64.dll': The specified 
module could not be found. (Exception from HRESULT: 0x8007007E)

... confusing users into thinking libmojoshader_64.dll is missing when that isn't the problem at all. See https://github.com/mono/MonoGame/issues/4263 for more detail.

Instead we should rebuild libmojoshader_64.dll and have it statically link to the C runtime which avoids the dependency all together.

Three PRs are needed to complete this task. The code for the version of MojoShader used by MonoGame is here:

https://github.com/MonoGame/mojoshader

A PR should be submitted to that repo changing the C++ project to statically link as well as a PR updating the MonoGame dependencies:

https://github.com/MonoGame/MonoGame.Dependencies

And a final PR to the MonoGame repo updating the submodule reference.

[KonajuGames]

This applies to FreeType and FreeImage as well.

[tomspilman]

And also to the NVidia texture tools (NVTT.DLL).

[stromkos]

Please be cognizant of the licensing implications of static versus dynamic linking issues and distribution rights. The BSD, Apache, LGPL, FreeType and FreeImage proprietary open source licenses "should be" compatible with MS-PL and should be allowed. Anything GPL'ed would be excluded. I have not been able find any information on NVTT.DLL(The primary reason I bring this up.) NVidia has had a history of releasing restrictive software licenses that permit distribution only to computers with NVidia hardware installed.
I wish to reiterate that I have no knowledge of the licensing of the library in question.

Disclaimer: I am not a lawyer; Therefore, none of the previous comments should be construed as legal advice or counsel.

[tomspilman]

Please be cognizant of the licensing implications of static versus dynamic linking

We are aware.

In this case we are talking about static linking to the compiler's C runtime library which has no licensing concerns.

[mrhelmut]

This reminds me that I have rebuilt OpenAL with static linking, I still have to push these binaries to the dependencies repo'. For reference: https://github.com/MonoGame/MonoGame/issues/5381#issuecomment-270094420
Also made them available online: http://neurovoider.com/OpenAL-Soft_Windows_Binaries.zip

[Jjagg]

The priority for this shifted up since Microsoft doesn't offer the VC++ 2012 download anymore.

[devedse]

Is there any progress on this issue as this is still happening?

https://github.com/MonoGame/MonoGame/issues/6304
https://github.com/MonoGame/MonoGame/issues/4504
https://github.com/MonoGame/MonoGame/issues/5736
https://github.com/MonoGame/MonoGame/issues/5738

[willmotil]

It's getting annoying to keep answering this question on the forum and people keep recommending direct downloads when they should recommend installing the sdk's thru visual studio ect.

One cavet here i suspect is that these libs depend on the enviromental variables being set up in vs or the current ide somehow. if so then...

We need a way on install of monogame to tell visual studio installer that monogame needs the 2012 and 2013 optional sdk's installed from vs or make it check for dependency's or something like tell the user to install it from vs himself. I have no clue how to do that though. This same thing happens not only with free image but with open al.

Im just going to copy paste my reply here to someone on the forum

_Up to win 7 always included by default the x86 and or x64, 2012, 2013 c++ redistributables so you never had to install them into visual studio. However win10 dropped the default installation for them and decided to make them optional._

_Most people eventually install them with other apps before they get to monogame so it doesn't pop up or something not entirely sure._

_New installs are obviously the exception though._

_Monogame supports open gl and uses some third party dll's that were made before that happened so they just expect that these library's are installed but i guess they don't do any checking to request a install for them. Maybe no one knows how to do it or its not working._
_I think its open al (open gl audio) and freeimage libs that needs these redists specifically._

_These are visual studio redists as the programmer you really want vs installs done from vs so it works for all future library's api's ect that you may use, not just monogame. So just including them in the monogame download probably wouldn't be right._

Forum posts just shown here for frequency of how often this comes up.

http://community.monogame.net/t/monogame-noob-unable-to-load-freeimage/6255/6

http://community.monogame.net/t/resolved-beginner-issue-involving-font-loading-edit-broken-dll-dependencies-please-advise/8845

http://community.monogame.net/t/new-pc-fresh-install-issues/12056/9

http://community.monogame.net/t/solved-freeimage-dll-not-found/8221/26

http://community.monogame.net/t/solved-content-pipline-freeimage-build-error/10067

http://community.monogame.net/t/solved-monogame-pipeline-tool-does-not-build-images/9700

http://community.monogame.net/t/pipeline-tool-do-not-work-with-vs2017/8969

pretty sure i could find more but you get the point.

[mrhelmut]

I'm pretty surprised that freeimage isn't statically built with the runtime.

If I have the time to, I'll check the dependencies of every native libs we have to check if they can be rebuilt to link the runtime.

[willmotil]

I think it is. pretty sure it ends up in the monogame folder.

Maybe its just the pipline tool that is just not directly or properly referencing it?

I suppose if either the framework or pipeline /tool were not linked to the dll it would be a failing scenario.

I heavily suspect it has to do with the path linking. The vs 2012 or 13 redist is setting up environmental variables. When i had this problem i had the dll's in all the right places seemingly.

After installing the redist i could see at least one env variable, though i tried to redo it once or twice by uninstalling and manually setting up the environmental variables, i couldn't figure how to do it right. I suspect it sets up a couple of them.

I considered rebuilding mg and trying to check the references paths in the pipeline / tool as well to directly link to the monogame installed freeimage dll, but ya im not familiar at all with that and haven't built mg in a long time, so i just coped out...

So

Under the auspice, that it was working with local path calls, _as obviously installing a redist isn't going to magically make the pipeline and framework directly link to the free image dll_.

Figured installing the optional redist from vs would patch the env vars properly every were including vs and everything would just work from the local or relative (_dunno the proper term_) paths supplied by vs or the os.

Since doing that works.. the suspicion appears valid.

However its possible that a call in the dll requires a redist setup relative path but then apps would just fail for end users installing monogame apps which as far as i know isn't the case or the root cause.
The cavet here to ensure this works is that a fix actually runs on a newly installed os were the error should be present, without installing these redistributables 2012 2013. at all
(lots o these post are new laptops)