I used MySQL Connector C 6.1 api in C.
I linked all the header files, libraries etc in the Code blocks IDE and when I try to compile the program,it works and I am able to run the program. But when I copy the .exe file to another computer, a warning comes saying that libmysql.dll is missing. When I copy that libmysql.dll file along with the program,it works fine. But how to avoid that? Is there a way to make it run without copying .dll file?
If your program depends on a .dll (which stands for dynamic link library) then there is no way to run without that .dll being present on the system. This is because there is code in the library that your program depends on. An alternative would be to build your program with a static version of the library, a .lib file.
Related
The title basically says it all. It might be a dumb question (which probably is) because I am entirely new to programming. I wonder how the desktop apps we use are made of mostly .dll files when you check their program files, but not even a single source code file? Is there any way to open them, or how can I turn my code file into .dll?
Thats exactly what DLL files are. DLL files are libraries which contain code that is called by the 'main' source code, which is compiled into '.exe' files.
You not being able to see such code is intended by its owner, unless the source itself is released alongside the compiled software. A project may integrate .dll files already developed by someone else instead of developing them from scratch.
As to how to turn your code into a .dll, it would depend on the language you are developing in.
More detailed answers at: What exactly are DLL files, and how do they work?
Short answer: The DLL files are "compiled".
Compiled files no longer rely on their source code. Once compiled they can be executed by the operating system directly.
DLL files are not "scripts". In languages like HTML, Javascript and PHP, the files are interpreted at run time by the browser's HTML or Java engine or the PHP engine on a server. Thus you can also read them since they are not yet compiled. But in the case of a DLL file, the original source code files have been compiled (interpreted and converted) and the result is an executable Library which is used by another program to accomplish whatever tasks are in them.
It is possible to "decompile" them with a decompiler, but that will not give you the original source code, any more than a "jpg" will give you the original layered Photoshop file. All you have is the Result.
We know that when linking a static library, the linker copies the relevant code from .a file to the executable binary file. And when linking a dynamic library, the linker just copies the addresses of functions it found in .lib file (under Windows) into the binary file, and the functions themselves are not copied. At runtime, the OS loads the dll, and the program runs the code according to the addresses. The question is, could I use the .lib file and dll to link the dynamic library statically? The linker reads addresses from the .lib, and then copies relevant code from the dll to binary file. It should work, right?
I have no clue whether your idea could work, but do note that -- on Windows, with Visual Studio at least -- a static library is something very different from a DLL.
With VS, a static library is basically just an object file container, that is, you have a .lib file, but that .lib file is just a container for all the .obj files that the compiler produced for the project.
The important thing here is that the .objcode in the static library hasn't gone through the linking stage yet, no linker has been involved.
Whereas the DLL is (finally) produced by the linker (from object files).
So the question here is really one of toolchain support, since the DLL is already a linker output, I doubt you could get the linker to re-link its PE code directly into the executable.
If you want to link the .dll at build time instead of run time yes, it can be done using the .lib file that corresponds to the .dll. The exact method depends on what you are using to build your application.
In Visual Studio you start by adding the .lib file in Linker->Input on the project properties.
While this is static linking it does not copy the .dll code into your executable; you still need the .dll to run the application.
Additionally, if the .dll is something you developed and/or have the source code, it can be modified/rebuild as a static library and linked into your executable (so you will not have a separate .dll file).
I am trying to compile a simple ANSI C program which requires GTK header files.
I know how to link the source code with gtk.h when compiling with GCC.
My question is how come applications such as gedit (GTK lib) is running on my system considering that GTK header files are missing? Presumably Gedit was compiled on a system which did have the GTK library. But why does Gedit not require header files on my system during execution?
As a Java programmer to compile a program the class files always have to be packaged with the main executable. Also I would need the JVM installed on the target system.
Thank you for your helpful responses.
But why does Gedit not require header files on my system during
execution?
Header files are only needed in the preprocessing phase. Once the preprocessor is done with them the compiler never even sees them. Obviously, the target system doesn't need them either for execution (the same way .c files aren't needed).
You're probably thinking of libraries, and you're right. Indeed: if a program is dynamically linked and the target environment doesn't have the necessary libraries, in the right places, with the right versions it won't run. One way to ensure it will run on most systems is to statically link stuff, but this will also bloat your executable and make poorer use of memory.
Also I would need the JVM installed on the target system.
Well, for C nothing like that is needed since once you compile it you get native code. Native code is very different from the intermediate stuff (bytecode) you get from java. There's no need for anything like an interpreter: you just feed it your binary stuff to the CPU and it does its thing.
Everything the executable needs from the header files is built into the executable when it's compiled. In C, header files are just included literally in the source file when referenced and then compiled.
I'm trying to compile a program in C on a Windows 7 machine using MinGW. Now I have to admit I don't have a lot of C experience to begin with and this is compounded by not being a very adept Windows user.
The program came with a make file, but it is getting stuck because I get the error:
cannot find -lsndfile
I found that sndfile is a sound library for reading .wav files and the like. I downloaded the library from http://www.mega-nerd.com/libsndfile and ran the setup executable it comes with. This put some header files and other junk in the Programs folder on C drive.
I copied the header files into the include folder under the MinGW directory, which reduced a lot of earlier errors down to one you see above. I think I need to put a .dll file somewhere, but not sure where.
I can provide more detail if needed, since I'm not quite sure where the problem lies.
Thanks for the help.
You have to put the linkable library files (either .a, .lib or .dll) along with the other ones (which come by default with MinGW).
Typically, when I create a program (I have only made a few very simple ones so far) I compile the program into a standalone EXE. Most programs that are distributed nowadays have many exes, dlls, and other files that are installed when you first download the program. Is this wrong to be compiling my programs into standalone EXEs? What are some advantages/disadvantages to a standalone vs multifile program?
The only possible thing I can think of is for updating and fixes, because then instead of having to download a 100MB file and overwrite all user settings data, etc. you can simply download maybe a 400kb file that only replaces the files that need to be fixed.
DLL files are library files. If you are not using any functions from a library, then the DLL files will not be included with your program. Having multiple EXE files are generally a way to break a larger program down into smaller, more maintainable units.
If you're just getting started, this is not something you'll need to worry about just yet. One day, when you're working on a larger project that involves using other pre-built components, you'll dig around in your build folder and notice that you also have some DLL files and other resources.