Using an Application without DLLs

[molma100]

Hello. I am making a program with Ogre3D and other libraries needed to make this an online game, but thats not important.

Lately Ive been using my project on different computers, and I noticed that my application cant run alone(without compiler) unless I have the required .dll files for that program.

Im wodnering if theres a way to setup the application where I dont have to add the DLLs directly to the .exe file.

The IDE im using is Code::Blocks and minGW is the compiler.
My OS(main OS) is Windows Vista 32 bit.

[shacktar]

It's all in how you link with the other libraries. If you statically link, then a DLL of that library is not necessary. If you dynamically link on the other hand, then your exe will need the DLL for execution. Ogre3D is open source so I would assume it has a static linking option. These "other libraries", however, could have proprietary code and, as such, may impose dynamic linking.

[molma100]

Alright, and Dynamic linking is using the Linker Options->Link files? or the Other Linker options?


what exactly do I use to link to my libraries?

[LB]

I think the problem here is that you're building the Debug version of your project instead of the Release version.

[molma100]

actually I am building the debug version. It would make a difference if it was in the release?

[LB]

The debug version uses DLLs and stuff for debugging purposes when you use your compiler's debugger. Building in Release means no debugging, meaning you can make it run on any machine, DLLs or not.

[molma100]

alright, and it doesnt matter how i setup my linker files?

[shacktar]

In terms of linking, it matters how the lib you're linking to was built. If that lib was built as part of a static library project then your exe won't depend on that library's DLL (at the expense of a bigger exe). If the library you're linking to was built as a DLL, then the .lib only contains stubs and thus your exe would depend on the library's DLL. It's a little confusing because the .lib associated with a static library project is different than the .lib associated with a DLL project. Anyway, try in release mode and let us know if you still have problems.

[molma100]

hmm... i think i know what youre talking about, but is there an obvious difference in filenames or any other way?

i noticed that my files have a suffix 'lib' in them and their extension is .a, for example: libOgreMain.dll.a

then theres others like libBulletCollision.a


would the '.dll.' part of the file mean something?


if so then is there a way to get around this problem? and yes there are DLL files and build executables that were needed for ogre to be built in the /bin directory

that being so then im guessing that im going to have to keep .dll files in my folder...


also one more question: how would i go about setting up a static library in my game, OR, how would I add the DLL file in the executable before-hand? Again, the compiler is MinGW, IDE is Code::Blocks, and OS is windows 32 bit

[acorn]

if your using codeblocks with ming there is quite a few dlls that you have a dependency on regardless if its debug or release. In fact thats one of the reasons why I went back to the vc compiler instead of codeblocks + ming because even the tiniest application on release mode needed like 5 dlls using the default compile options. You can likely change the compile options to make these dependencies go away but its not setup that way by default and its a royal pain for ever app you make.

[shacktar]

hmm... i think i know what youre talking about, but is there an obvious difference in filenames or any other way?

i noticed that my files have a suffix 'lib' in them and their extension is .a, for example: libOgreMain.dll.a

then theres others like libBulletCollision.a


would the '.dll.' part of the file mean something?

I use Visual Studio so I'm used to the Windows linking paradigm (.lib, .dll) so what I say here might not be entirely correct so if someone could correct me I would appreciate it. The .a files (archives) are part of the Unix linking paradigm where essentially .a files replace .libs and .so files (shared objects) replace dlls. The one difference, I think, is that you can be sure that an archive (.a) only contains a static library. The reason I'm unsure is your example "libOgreMain.dll.a" hints that it might be a library needed on top of a shared library (.dll or .so). However, everything I've read thus far points to archives being equivalent to static libraries so idk. This might be a by-product of everyones over-simplification of .lib files, though. To re-iterate, they may contain the full object code or they may not and thus need to be supplemented with a .dll (.so). Something tells me this "libOgreMain.dll.a" needs to be supplemented with a .so. If you're confused that's OK 'cause I think I've confused myself at this point :D

if so then is there a way to get around this problem?

If you have DLLs that are part of the OGRE library, then being dependant on their DLLs might be doing your program a favor. The reason I say this is if you statically linked with the OGRE library, then your exe might bloat to an unreasonable size. To get rid of a dependency on a DLL (when you know how the library was built) is to get a static version of the library and link with that. This might be something like "libOgreMain.a" as opposed to "libOgreMain.dll.a", but again, unsure.

also one more question: how would i go about setting up a static library in my game

This you would set up with your IDE. I haven't used Code::Blocks so here's a resource I found randomly
http://turrier.fr/tutoriels/c_05/create-and-use-a-static-library-with-c-or-c++.html

But, why would you set up a static library in your game? I would see this being useful if, say, you had a library for 2D/3D Vector and matrix math, a physics library, a rendering library (but you have OGRE), etc. and then you would link those into your main game code. Otherwise, I think you'd want your game to be a .exe and leave it at that.

OR, how would I add the DLL file in the executable before-hand?

A DLL file means dynamic linkage, hence a link with a .lib (or .a?) file that did not contain all the object code. The DLL file is necessary for running. To get rid of the DLL you need to find a static version of the library you linked with.

In terms of other DLLs that seem to just be randomly imposed on your exe, it might be like what acorn suggested, and you might have to switch IDEs for less restriction.