I have a Windows 10 64 bit system with MATLAB 2013b installed on it. Now I am using SDK 7.1 compiler to compile a c ++ program. This works fine in that it has created the "XXX.mexw64" file. But when I run that file, I receive the error message: Invalid MEX file: The specified module could not be found. What could be wrong and where?
I have tried reinstalling SDK compiler with all combinations of Visual studio packages as shown in various sites.
I have used dependency walker program to find what is missing, and I find that hundreds and hundreds of files are missing. I can't possibly replace ALL of them can I?
The MEX file created finally (this was successful) called "uhdinterface.mexw64" should run finally, shouldn't it?
The "Specified module could not be found" message is MATLAB's fairly cryptic way of telling you it can't find a required dll on your path.
Dependency Walker will always show many files that can't be found, but the important ones are the top level dll's. Figure out which top level dll isn't on your path (that's your system PATH environment variable, not your MATLAB path) and add it via
setenv('PATH',[getenv('PATH')';C:\Path\to\your\dll']).
The reason your mex file compiled is because it was linked correctly (the necessary libraries were found at compile/link time), but it still relies on some of them to execute at runtime.
Related
Intro
I have a CMake-based C++ project. Until now I build and ran the project via CLion. Everything worked fine until I tried to run the .exe-file directly (not via CLion).
Problem
When I navigate to the cmake build directory in order to start my program via the executable file, it fails with the following message in the popup: Cannot continue the code execution because libgcc_s so-1.dll was not found. Reinstalling the program may resolve the issue.
I have the following questions
If I interpret the error message correctly, then this dll is missing on my computer. So I ask myself, why does my program still work when I start it via the development environment (CLion), although the error message expressly states that the source code requires this dll?
Is it the fault of my application/source code that the error appears or rather the current state of my computer? If the former, how can I prevent this error from appearing for other users?
What is the best way to fix this error? It's obvious that I need to download this dll, but where is the best place to put it (which directory and environment variable to use on Window)?
Which source is trustworthy to download this dll? I don't want to download any malware under this dll-name.
Optional: What kind of library is that? What functionalities does it offer?
Additional information
I use CMake as my build tool, CLion as the IDE and MinGW as the compiler.
What I have did so far?
I made sure it still works through the IDE.
I found this dll does not exist in the MinGW installation folder.
I searched the web for more information. Unfortunately, there are only pages unknown to me that only offer the download of this dll. That doesn't satisfy me.
I found the cause of my problem: I had two MingGW installations on my machine. Once the installation that comes with CLion and a separate one. The latter did not have the required dll. However, CLion used its own installation, which in turn owns the DLL. So the solution was to remove the separate installation and include the path to the CLion installation's bin/ directory in the PATH environment variable.
This file is part of MinGW-w64 when using SEH as exception model (as opposed to Dwarf or SJLJ). You need to distribute the .dll files your .exe file(s) depend on in the same folder as the .exe file(s).
If you don't have that file, then you probably have been using libraries compiled with different versions of GCC/MinGW(-w64). I recommend building everything with the same compiler to ensure stable binaries.
Tools like Dependency Walker can help you figure out which .dll files your .exe file depends on.
Or use the command line tool copypedeps -r from https://github.com/brechtsanders/pedeps to copy the .exe files along with it's dependencies.
I'm trying to get into C++-extensions for python, with boost/python.
I've downloaded boost 1_73 and installed it by calling bootstrap and then b2 --with-python
In Visual Studio, i've included the compiler include path (the boost directory) and linker library paths (/stage/lib/) that the output of b2 tells me to.
Now I get the compiler error LNK1104 cannot open file 'boost_python37-vc141-mt-x64-1_73.lib'. I can't find any information about this specific error. For everything similar there is only the suggestion to add the above mentioned paths.
The code I'm trying to compile is just the hello world example supplied with boost.
Any ideas?
First check that file exists somewhere in your filesystem. If it doesn't, you may have accidentally built it against a different version (i.e. not 141) of the VC runtime. (This has happened to me when I've had multiple runtimes installed.)
If you do have the file, then you just need to ensure that the path is in the link settings section of your project config.
So I have a sample code (everything in c++) that I was able to compile into dll using visual studio 2019 (everything is compiled in 64bit). I have a test code that loads the compiled dll during runtime. However, as soon as I refer to another library(opencv in this case), I would get an error on the load module (126, I assume it means it couldn't find the dll file or something).
Things I've tried so far:
Adding library path and include path and all the dlls from opencv to
my dll doesn't cause any error. but as soon as I add "#include
"opencv2/opencv.hpp" " I get 126 (the dll still builds fine).
I added the same dynamic linkage to the load module (already static
linked to the same library), still no dice.
Update: After checking with process monitor I found out the OpenCV module cannot be found, which is quite bizarre as I have specified the locations under Additional library directory and include directory (I used the one under vcpkg/installed). The process monitor shows that of all the places the load module was looking for the opencv dll, only the vcpkg location was not looked at.
update2:
I took out all the linker to the opencv dll and the issue didn't show up on the process monitor, however, I'm still getting the code 126 .
update3:
Did a quick file search, didn't even have the dll files to begin with. Downloaded the required dll and left them in the root folder of my load module, problem solved. I want my three hours back.
Did a quick file search, didn't even have the dll files to begin with. Downloaded the required dll and left them in the root folder of my load module, problem solved. I want my three hours back.
I have environment where both VisualStudio 2005 and VisualStudio 2013 are installed. And I have strange situation with some of the projects. I compile such projects with VS2013 and when I try to launch them through Explorer or command line I get an error - "The program can't start because MSVCR80.dll is missing ...". Why msvcr80 when I compile with msvcr120?
What I tried:
Put msvc*80.dll to directory with executable. I got runtime error "R6034. An application has made an attempt to load the C runtime library incorrectly..."
Checked binary dependencies with Dependency Walker. I saw that binary has dependencies to VS2013 runtime, and there is no mention about msvcr80.dll
Launched binary with empty PATH. I gave no positive effect.
Launched binary on another 'clean' pc. And it worked all right with vs2013 runtime.
How can this be?
Thank you for all, you was right. I just forgot, that I have installed old version of my product. It was launched in background and used old versions of libraries. So when I ran my new application it tried to use libraries that already had beed loaded. In another way Dependecy walker didn't check already loaded libraries and looked only in PATH.
MSDN link about DLL loading - https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms682586(v=vs.85).aspx
I've recently downloaded Assimp and I've run into some troubles.
I've linked the libraries and I can get the program to compile and it runs fine in Release mode; however, the Debug .exe hits me with this error:
The application was unable to start correctly (0xc0150002). Click OK to close the application.
Some more details:
I'm using VS2010 with Target Machine set to x86.
I am using the 32bit debug dll (Assimp32d.dll) that was provided, and I've tried setting runtime libraries to /MT, /MTd, /MD, and /MDd with no luck.
I read from other similar threads that I should run Dependency Walker on the .exe, but I'm not sure what the output means. I'll paste it here if this helps you guys.
Error: The Side-by-Side configuration information for "c:\users\-----\documents\visual studio 2010\projects\AssimpTest\debug\ASSIMP32D.DLL" contains errors. The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail (14001).
Error: At least one required implicit or forwarded dependency was not found.
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Rather than rebuilding the libraries, I downloaded a different set of libraries (it was the SDK installer) and the debug dll's from that are working perfectly.
Just in case anyone has the same problem with the same software, this was the exact name of the installer that worked for me: assimp-sdk-3.0-setup.exe
I ran into the same problem when trying to run a 64-bit project in Debug mode when using Assimp 3.0.
What I did was go to assimp/workspaces/vc9, open assimp.sln in Visual Studio 10, convert the project, then rebuild the 32 and 64-bit dll.
Mind you, you've got to install boost for that as well, and edit the project properties so it points to the boost directory for includes.
There's probably a way to do it using CMake as well, but I found the whole process too cumbersome to bother with in the first place.
My solution was just to link the debug build to the release .dll files. No more issues, and I wasn't that interested in debugging the Assimp library anyway!
I faced the same issue, later on I downloaded the "assimp-sdk-3.0-setup.exe" file & installed it as a standard windows application.
I pointed Visual Studio Solution Include & Lib directories to respective folders from newly installed location, copied DLL to my application location. The problem was resolved. Hope this helps someone.
Cheers.