When I compile my project with the option to exclude runtime packages (to do a static library linking) everything goes fine.
But when I run my application on a C++ Builder "virgin" (no packages installed) it won't start and shows the following error:
The program can't start because CC32110MT.DLL is missing from your computer...
The CC32110MT.DLL is signed as a Embarcadero RAD Studio C++ Multi-thread RTL (WIN/VCL MT)
Any ideas of how to fix this other than copy the DLL to the target system?
In C++Builder, you have to disable both the Dynamic RTL and Runtime Packages in order to produce a fully statically-linked executable (in Delphi, there is no Dynamic RTL). You have only disabled the latter, but not the former yet.
Related
I'm using Visual studio 2013 and I'm want to compile my project for linux (with MONO).
Is this possible to use VS2013 (with or without mono plugin) to compile my project to MONO file?
Yes, you'll be fine to use VS to build a .NET project that can run against Mono.
You'll be fine with the stock csc compiler and MSBuild (as both csc and the Mono compiler generate CIL all the same) just make sure that your project references Mono's assemblies rather than .NET's where there are breaking differences (e.g. System.Windows.Forms, etc). If you're doing ASP.NET or Console applications you should be fine without doing anything special.
As long as you use the versions of the DLLs that come from nuget instead of the references that are added by default by Visual Studio you should be fine, provided you recompile everything with xbuild.
At the moment there are some minor differences in the CIL that is outputted by msbuild and what the mono VM can run.
Just run xbuild in the root directory of your solution or project. It will detect the .sln/.proj file and build everything.
I use API to make a programs. It runs pretty well on Windows 7 (with debug file .exe), but it doesn't when I run it on Windows XP. Are there any ways to solve this problem?
I suppose you are using Visual C++, according the the message you get.
Your project is set up (by default) to link the Microsoft C++ Runtime Librairy dynamically, so it saves up space in your final executable, but you need the dynamic linked libraries to be in your system or in your executable's folder.
To solve this in Visual C++, without any afford from who are executing the program in their machines, you can change how MSVC link their runtime library to your executable, that is, if you set it to be linked statically, all the dependencies will be linked inside your final .exe, with no need of additional .dlls.
To change this option, refer to /MD, /MT, /LD (Use Run-Time Library) - MSDN.
Or in short: Project Properties>Configuration Properties>C/C++>Code Generation>Runtime Library
If in debug mode, use /MTd, otherwise use /MT.
I wrote a program in C++ using Visual Studio 2010
But when I run it on some computers with WinXP it says
"Cannot start because MSVCP100.dll wasn't found"
How do I prevent such dependencies on dlls that do not come with windows?
Thank you.
you cannot prevent this dependency, as it's the core runtime library of Visual C++. Instead, include the Visual C++ 2010 Redistributable package with your application (usually a separate link is enough since most people have it installed already)
However, if in fact your program cannot start because a dll with D at the end such as MSVCP100D.dll then you need to build your program in release mode, which by default switches the run time to a non-debug version. You need to be careful to nut out any other included static and dynamic libraries you're including in your project to make sure all debug or all release versions match for your builds.
If you are having trouble finding which sub-projects are referencing the debug versions, you can download and run depends.exe and browse through the exe file to see.
Sorry for the late respones, but yes you can prevent this dependency, just go to solution property of yopur project, go to C/C++ > Code Generator and in Runtime Library change it from MDd to MTd, will include statically the dependent libraries, and not in run time, like this avoid Run time errors while try to run the Dll.
I have an application which use CUDA. I am using runtime API and CUDA toolkit 3.2. Application has a dependency on cudart32_32_7.dll. However, there is also cudart32_32_12.dll. The issue is, I do not know how to determine which dll is linked from cudart.lib during the application build. I need to identify dependency dynamically somehow, because I need to include all dependencies into the deployment package. I would like to avoid hard coding dependency path ...
Just put the .dll or .exe of your project into this software: Dependency walker. It will show on what other .dlls yours project depends on. There you'll find either cudart32_32_7.dll or cudart32_32_12.dll.
Alternatively, if you're making a binary project. Just compile it and run the binary (.exe) on a different machine that doesn't have CUDA installed. An error message will come asking for either cudart32_32_7.dll or cudart32_32_12.dll.
I have a mex64 dll compiled on my machine. I used Matlab 2009b with VS2008 Pro to compile the dll. The dll works fine on my Matlab installation.
I want a colleague to use the dll so I sent it to him and he gets the following error message when trying to use the dll:
??? Invalid MEX-file 'filename.mexw64': The specified module could not be found.
My current assumption is that this is caused because he uses an older Matlab version or missing a dll that I have. I ran dependency checker and asked him to check that he has all the listed dlls.
I am still waiting for him to confirm his Matlab version.
What other reasons can cause this and can the Matlab version make a difference? (I mean R2009a when I have R2009B and not a huge version diff)
The other person has Matlab R2009a. Shouldn't the mex just work if I compile it on my computer and deliver it to him?
Does this only leave a missing dependent dll?
The issue is strange, but I can confirm it exists.
Using pre-built libraries for matlab that are correctly installed and in the path, I sometimes get the same error. If I type in the function name at the command-line, the function is visible and will auto-complete. However, the function will not initialize until I 'cd' into the directory with the .mexw64 library file.
>> AndorInitialize('')
Invalid MEX-file 'C:\Program
Files\MATLAB\R2011b\toolbox\andor\AndorInitialize.mexw64': The
specified module could not be found.
>> path
MATLABPATH
C:\Program Files\MATLAB\R2011b\toolbox\andor
C:\Program Files\MATLAB\R2011b\toolbox\andor\camera files
C:\Program Files\MATLAB\R2011b\toolbox\andor\m files
... etc
It turns out this is due to missing dependencies, which shouldn't be missing. To resolve the issue, use dependency walker (free, lightweight) to identify what's missing. The mathworks explains this.
http://www.mathworks.com/support/solutions/en/data/1-2RQL4L/
In my case, two DLL's weren't showing up properly, even though they were on my system and in the path. I copied the DLL's into the windows/system32 folder and the library functions now work correctly. What's particularly strange is that the same library worked on my computer a few days ago (prior to the moving the DLL's).
In general, MEX files should work across different versions of Matlab; in particular, they should be forward-compatible. You're right; sounds like a dll problem.
If you built it with Visual Studio, it may be linked to the Visual C++ Runtime. This is a set of libraries that is not installed on Windows by default. The "redistributable" for it can be downloaded here; having your coworker install that could resolve the problem. If that doesn't work, you can use Dependency Walker to check for other unsatisfied DLL dependencies.
Normally, configuring Matlab's "mex -setup" to use the Lcc compiler that's distributed with Matlab could be a way around this, but it's not supported for 64-bit Windows AFAIK.
Also, are you sure he has the 64-bit version of Windows?
Another possible source of the problem could be that you compiled in debug mode. The Visual C++ redistributables only support release mode.
The Dll was a wrapper for MySql access. We ended up using Matlab's ODBC and the MySql Connector.