I'm reciving a very odd error. I'm compiling a code which parses JSON data from a url using libcurl. After trial and error I've gotten it compiled without error. However, when trying to run the code I get a system error, saying libcurl-x64.dll was not found.
Picture of error here
I'm not exactly sure what is finding what, here. My windows system cannot find libcurl-x64.dll or is it my gcc compiler? Nevertheless, a quick system search shows the location of it. I didn't use it for anything. What exactly do I need to do with libcurl-x64.dll so that my system can find it? It only pertains to this one parsing program I'm doing, every other cpp/exe file and project works fine. System specs: Windows 10, Dev C++ IDE, mingw g++ compiler.
Here is the location of my supposedly missing file:
FilePath1
FilePath2
The search order of DLLs for desktop Windows applications is as follows:
The directory from which the application loaded.
The system directory. (e.g. \Windows\System32 or \Windows\SysWOW64)
The Windows directory. (e.g. \Windows)
The current directory.
The directories that are listed in the PATH environment variable.
You need to make sure the missing DLL is reachable via one of the above locations.
The best for a quick test is to copy it to the same location where your application (.exe) is located.
It has nothing to do with your compiler. On any OS that supports dynamic
libaries (DLLs on Windows, shared libraries on Linux, etc.), if a program has
been linked to some dynamic library at linktime then, at runtime, the OS
program loader must be able to find that dynamic library in
one of the places where it looks for dynamic libraries by default, or in one
of the places that you specify at runtime in some OS-dependent manner.
This is the nature of dynamic libraries.
In the case of Windows, it means that to run a program you have linked with
libcurl-x64.dll the program loader will try to locate libcurl-x64.dll
using the Search Path Used by Windows to Locate a DLL,
in order to load it into your program's process. If it fails to find libcurl-x64.dll in any of those places
then the program will fail to start, with the error you observed.
Related
I have an application in C++ that is using Qt framework and I want to cross compile it into a portable program for Windows. Since I don't have any computer or virtual box with Windows operating system (and I also don't have enough space on my disk to change that), I'm trying to use MinGW to cross compile. I've installed MinGW from the ArchLinux packages and the other required libraries from the AUR.
However, everytime I try to compile the program, it would link to api-ms-win-core-winrt-l1-1-0.dll and api-ms-win-core-synch-l1-2-0.dll. Windows users then complain about seeing error messages like
The procedure entry point CreateEventW could not be located in the dynamic link library api-ms-win-core-synch-l1-2-0.dll
or error message
The program can't start because api-ms-win-core-winrt-l1-1-0.dll is missing from your computer
My understanding is that these are windows-internal apis and that I shouldn't be linking to them. Can someone tell my why does MinGW link to these libraries and can I tell it to stop linking to these?
I wrote a c++ program and converted it to a .exe file with the hopes to let it run on windows without needing to install a compiler. I ran well on my main computer (which has a compiler so it ran as expected) but did not run on another device. The error message shown was "libgcc_s_dw2-1.dll was not found"
How can I run a c++ program (or .exe file) from a flashdrive or other medium on any windows machine without extra installation.
C++ programs require additional c++ standard and runtime libraries to run. Most linker links to these libraries dynamically. That is some dll are required for running the program. You can run the program from a portable flash drive by copying those dll to the same folder as the application.
Alternatively, some linkers also have option to statically link, that is incorporate the code in dll ( kind of ) to your binary exe.
So you can either find out what all dll is required and copy them to your local folder ( maybe use something like dependancy walker or this newer one, i haven't actually used the newer alternative). Or use static linking like shown in this answer.
I'm having a strange problem with LoadLibrary on Windows. First some background. This application depends on Qt, and Qt is split into several libraries. I am trying to upgrade versions of Qt, but without breaking anyone. The newer Qt library is backwards compatible with the old one. That means that an application built with the older version can run if it loads the newer version. The opposite is not true -- an application built with the newer version will have missing symbols if the older one is loaded.
The Qt DLLs are in version specific directories (say c:\qt\qt-4.5.2\lib and c:\qt\qt-4.8.1\lib as examples). There is also a common directory that most developers have in their PATH that contains the "current" version of all the third party libraries we use (call it c:\common\lib). This is where the Qt libraries would normally be found when running an application.
I put the new Qt version libraries in the common location, and everything seemed to be working OK, except for one case. The application in question is split into multiple libraries, some of which are loaded by calling LoadLibrary(). Some of these runtime loaded DLLs depend on Qt libraries. In one case, the loaded DLL depends on QtXml, which itself depends on QtCore.
Here's where it gets weird. An application depends on QtCore and also loads a library that depends on QtXml. The application and library were built linking with the old version of Qt. If this application is run with just the common directory in the PATH, everything works because the new Qt version DLLs are loaded from the common directory. However, if the PATH contains the directory where the old Qt version DLLs are stored before the common directory, then loading the runtime DLL fails with missing symbols.
(This situation arises when doing automated unit testing, with scripts explicitly setting the PATH to use the specific library version.)
As near as I can figure, the application is loading the old version of QtCore.dll and the runtime loaded DLL is (somehow) loading the new version of QtXml.dll, which fails because the already loaded QtCore doesn't have the symbols it needs.
But this seems impossible, since the PATH is something like c:\qt\qt-4.5.2\lib;c:\common\lib (plus other unrelated paths). If I remove the newer QtXml from the common lib directory (not replace it with the old version, just remove it), then LoadLibrary() succeeds, because it loads the 4.5.2 version of all the Qt libraries. But that's not a good long term solution, since running without the Qt specific version directory in the PATH (common) will fail to find QtXml.
How could this be? How could LoadLibrary() (or whatever it calls recursively to resolve the library's dependencies) load a library from later in the PATH? I cannot find anything that would indicate that the common library directory is given special consideration (it's not a set DLL directory). It's not mentioned in the build process, it's just something developers have in their PATH for convenience.
btw, a similar situation exists on Linux with LD_LIBRARY_PATH and dlopen(), and it works just fine there. This is something Windows is doing differently that I don't understand. Does anyone have any insight into what could be going wrong?
LoadLibrary has lots of surprising behaviors. Make sure you fully grok all of the Remarks for it in MSDN.
If there's already a library loaded (any version) with the same name, LoadLibrary just returns a handle to the already-loaded DLL. That may be coming into play in your scenario.
Next, if you've specified a relative path or just a file name, LoadLibrary applies arcane search rules. Your PATH variable is typically the last place to search. It's likely that some other rule is finding the "wrong" DLL before it even gets to checking the PATH. A good guideline is to always use an absolute path the file you want to load to be sure that its search rules don't grab the wrong file. A common security flaw is to not control where LoadLibrary searches, and an attacker convinces your application to load a doctored DLL.
And, finally, it's possible for an installer to apply DLL redirection that can override what you ask for and where it might be found. I'm not sure if this is common for Qt DLLs or not, but you might want to check your registry.
I've occasionally used ProcMon from SysInternals to observe a program while it's loading DLLs. You can see each place it checks, which may give you a clue as to why it's finding the wrong version.
I want to create a program that could work on any computer without the source code, How is that possible? and does it make any difference if I used OpenGL in the Program?
You cannot code a program in C++ that would work on any computer without giving your source code to be compiled.
For example, you could perhaps code in C++ a program, and compile it and build an executable which works on Windows x86-64, but that executable won't work on Linux (or MacOSX), and it won't work on ARM (e.g. Android phones) unless you consider using emulators
If you are developing your code with Visual C++ you may need to consider two options:
Make sure you link all libraries statically.
Install on the target computers along with your program Microsoft Visual C++ Redistributable Package corresponding to the Visual C++ version you use like the one at http://www.microsoft.com/download/en/details.aspx?id=5555. Some installer generating software will make it for you automatically.
Normally you would link your object file with some sort of a platform dependent loader. This loader loads your object and does all the stuff to start it from memory. Normally you can tell your compiler to link your object file and compile a blob. OpenGL is a powerful API and is usually distributed as a.dynamic linked library and is linked at runtime to your program. If I remember you just have to make sure the dll is where you want it and load the dll in your program from start.
Your C++ program is compiled and linked into an executable before it is run. You should be able to find that executable in a Debug or Release subfolder of the folder containing your project.
OpenGL, if you're not using GLUT or similar libraries, should just come with Windows and pose no additional problems. If you do use GLUT, it's enough to bundle the .dll file with your application.
In any case, the source code won't be necessary.
I want to create a program that could work on any computer without the source code, How is that possible? and does it make any difference if I used OpenGL in the Program?
By compiling and linking it into an executable. As long as you're not using some interpreted language (like Python, Ruby or such) you're presented with an executable inevitably. The biggest problem you may/will run into is dependencies on libraries. However those are linked into a binary as well. So what you're going to ship will be just a .exe; and some .dll maybe. Usually you'd wrap this in a installer package for deployment to the end user. Installers are created with something like the "NullSoft Installer System" (NSIS).
OpenGL itself is just a API, provided by a system library. So you don't ship OpenGL with your program, but expect the user to have it installed on the system (which will be the case if he installed the graphics drivers).
I'm doing a very small windows application consisting of just a single executable. As the program will reside on a SD card I want the application to be as self contained as possible, and I'd rather not have an installer. I'd want the user to be able to simply copy the executable to the SD card and be able to run it straight away without fiddling with anything extra. The problem then becomes the fact that my program is compiled with VS 2008 which requires versions of the CRT which I can't guarantee is installed. I'm linking statically to the CRT, which I incorrectly thought would circumvent this problem. I've been thinking of tracking down some older VS version, but I have a feeling this is the incorrect path. I want the program to run on a fresh install of windows xp and above.
Grateful for any help.
Linking statically to the CRT using /MT or /MTd (for debug) should do exactly what you need.
The fact that it isn't suggest that there is still something that depends on the dynamic library. That would be the case if you has some additional DLLs which are not compiled with the static CRT.
you can use the dependency walker (depends.exe) to figure out exactly which dlls use which and who still depends on the dynamic CRT or in any other DLL.
Another approach is to run your exe from the debugger and see which DLLs are being loaded in the output window. Which depends.exe gives you only the dlls loaded on the startup, this can give you some additional dependencies that are loaded only on runtime.
If you want the link against the DLL version of the CRT libraries and you want to avoid installing anything then you need to copy every member of the CRT assembly into the same folder as your executable. It may not be the way that Microsoft pushes you towards but it is valid and it does work.
In your Visual Studio 2008 install directory your should find a folder: VC\redist\x86\Microsoft.VC90.CRT. If you copy the complete contents of that folder (including the manifest file) to the same directory as your executable then you should be able to run the executable from that location.