When will my programs have more than one file after compile?
hi,
I am compiling a lot of programs (basic practice) but what i noticed is that every file i have compiled to date is only one exectuible like a.out. When/How doe s a program i write have mutiple file components to it? Like .dlls or .so files?
I am compiling a lot of programs (basic practice) but what i noticed is that every file i have compiled to date is only one exectuible like a.out. When/How doe s a program i write have mutiple file components to it? Like .dlls or .so files?
.so are shared object files (dll files in windows) which can be accessed programs which needs them.
If you want, you can make each .cpp file as a object file (.o extension) with "-c" option in g++. After all source files are COMPILED, or in another words created .o files, them are LINKED together with "g++ file.o file2.o...."
If you want, you can make each .cpp file as a object file (.o extension) with "-c" option in g++. After all source files are COMPILED, or in another words created .o files, them are LINKED together with "g++ file.o file2.o...."
The .dll extension stands for Dynamic Link Library. To put it into perspective, it's just an external library that your program uses to run. If you take certain programs to another machine, it's possible that it needs 1-2 of these libraries just to run. I've run into this issue with a friend who had an older compiler and I had to share my .dlls with him. You can also create your own .dll files to be used with any application. These then need to be distributed with the program to ensure the program will work as intended.
I don't believe there is any settings in the compiler that will create all dependencies in the directory of the program. You can add different dependencies depending on what you're creating as well, but I believe the only files a compiler will generate is the makefile, object file, executable file, and two or three more. The rest would be up to you to create or place in the correct spot.
Hope this helps.
I don't believe there is any settings in the compiler that will create all dependencies in the directory of the program. You can add different dependencies depending on what you're creating as well, but I believe the only files a compiler will generate is the makefile, object file, executable file, and two or three more. The rest would be up to you to create or place in the correct spot.
Hope this helps.
I actually ran into this problem just yesterday. I installed Fallout New Vegas, which flat out crashed the moment I was about to play. The problem ended up being a missing Direct X DLL that is no longer provided by the latest version, but was still required to play the game.
You may also want to consider that a lot of programs keep track of data like layout preferences, keyboard binds etc which go into a separate file.
You may also want to consider that a lot of programs keep track of data like layout preferences, keyboard binds etc which go into a separate file.
Those files, typically a .dat file, are either going to be generated by the program, or will be included as a "default." A lot of professional programs have moved away from .dat and .ini files since they're easily modifiable.
In fact, the advantages of the DLL just can make a similar program sharing some function, the DLL files in to run the program must be finished before loading. So, you can't use DLL realize the dynamic function. However, you can use a virtual function. In short, generally software is not need the DLL.
Actually, DLL's are software. They're libraries for your program. I've only run across a few that were actually hardware DLL's. The only issue with a DLL is that different versions can exist, so that even having the DLL isn't always enough. An older version might be missing certain functions, while a newer one could possibly have a function named differently, or overall the entire library could have been rewritten changing the behavior of the code. I prefer static libraries, no need for an external dependency.
A DLL that contains Driver Libraries for hardware I/O applications. More specifically, the most recent example I saw was at work for our touch screens. It has a DLL for a Scanner and a Card Swiper.
Topic archived. No new replies allowed.