I cannot run Falkon, it complains about missing MSVCR120.dll STEPS TO REPRODUCE 1. have a machine with Windows 10 (Pro for Workstations) 2. do standard Falkon install via https://download.kde.org/stable/falkon/3.1/Falkon.Installer.3.1.0.exe 3. try to run falkon.exe OBSERVED RESULT a dialogue window says that the code cannot be run because MSVCR120.dll cannot be found (I have Czech locale, so the text above is just a rough translation) EXPECTED RESULT Falkon runs SOFTWARE/OS VERSIONS Windows: 10, 32 bit ADDITIONAL INFORMATION After some googling for solution, I've tried to install "Microsoft Visual C++ 2015-2019 Redistributable)" but this didn't help.
Same problem here with a 64 bit Windows 10 installation.
I could resolve the problem here. It was to install "Microsoft Visual C++ 2013 Resdistributable (X64) 12.0.30501". I also installed the (X86) version as well to be sure (running 64-bit Windows 10). After that Falkon startet as desired. @kavol: I would like to know if this helps You to get Falkon running on Your system. If it does, I would be pleased if You could close the case. Best regards Stephan
(In reply to Stephan from comment #2) > I could resolve the problem here. It was to install "Microsoft Visual C++ > 2013 Resdistributable (X64) 12.0.30501". I also installed the (X86) version > as well to be sure (running 64-bit Windows 10). > After that Falkon startet as desired. > > @kavol: I would like to know if this helps You to get Falkon running on Your > system. well, yes, using the older version 2013 helps, thanks ... > If it does, I would be pleased if You could close the case. ... however, I'd prefer not to close this until the Falkon download webpage informs about the dependency (and possibly also where to get it, as finding something at Microsoft site is not that straightforward)
I confirm the issue. I also confirm the solution of installing Microsoft Visual C++ 2013 Redistributable. Even though I have one machine without the 2013 version where Falkon works (it has 2005, 2008, 2010, 2012 and 2015, but installing both 2012 and 2015 did not suffice). Despite a mistaken article I found on the Internet, the "12" in the filename does not represent 2012, but version 12, which is 2013. Please upgrade this ticket's Importance to either major or grave. As a point of comparison, Debian policy makes unenforced absolute dependencies grave bugs.