I've been trying to get SFML 2.1 working on my linux mint 15 install on my laptop, and that's when I found I should compile it from the source. So after fumbling through the tutorial on compiling SFML using cmake, I'm finally able to get some code working. But now I'm curious...what did I just do?
When I think of compiling, I think of compiling c++ code into object files, and then linking the object files into an executable. But I don't really understand what it means to compile something like SFML. When I think of a library, I think of a bunch of functions and objects that are made available to me through header files and source files created by another programmer, not necessarily something that needs to be compiled. My knowledge on the compilation and linking process is rather limited, so that might be my biggest issue at this point.
So what does it mean to "compile" a library?
EDIT: After looking at this particular question: How does the compilation/linking process work?
I noticed two bits of info that may further refine my question.
Linking: the linker takes the object files produced by the compiler
and produces either a library or an executable file.
and
The linker is what produces the final compilation output from the
object files the compiler produced. This output can be either a shared
(or dynamic) library (and while the name is similar, they haven't got
much in common with static libraries mentioned earlier) or an
executable.
So perhaps my real question is what does it mean to compile a dynamic library? What am I accomplishing by doing this?
Related
I have inherited a code project that contains several individual libraries of code that compile separately and then are linked in the compiled tools. It's supposed to be a Chinese menu of what each tool wants. This all written on Linux, in C++, with Qt. There are several issues with the current design, but I'm learning to deal.
This latest issue has me really dumbfounded. The main library is the Utilities. It contains a handful of classes and it compiles into a .a library file. Another library is our DatabaseInterfaces. It has class files that refer to header files from Utilities (they are all shared) but the CPP files are not included in DatabaseInterfaces. DatabaseInterfaces also compiles into a .a library. Finally, we have a CMDPrompt tool that imports both the Utilities.a and DatabaseInterfaces.a libraries. CMDPrompt does not compile. Instead, I get several errors indicating that I have an undefined reference for one of the objects in Utilities.
After several different attempts to fix this, I finally directly included the CPP file in the CMDPrompt.pro. It worked or at least it is now finding new undefined references for other classes in Utilities. This confirms to me that somehow the projects are not linking correctly. I would have expected that because the Utilities library is linked in I would have gotten all of the H/CPP goodness with it. I suspect the problem is that the DatabaseInterfaces library is compiling against the H files only and needs the same Utilities.a library. I tried adding that LIB into the DatabaseInterfaces.pro, but it didn't have any effect.
I am not a C++ programmer by training and while I believe I understand the main points of the linking process, I am obviously missing something. Here are my questions. Given the relationship between the different libraries, how should the linker work? Why is the DatabaseInterfaces.a compiling at all with just the H files? What is the best way to resolve this issue?
You need to link the libraries in the right order - it sounds like Utilities.a needs to be linked last. I don't know how you do that in Qt but that's what you need to achieve.
I have edited out a lot of my original situation to try keep things simple; it can be seen in the revisions.
Basically I have been following a tutorial in which a game engine is being created.
Most of the code has been separated into its own CodeLite project and successfully compiled into a static library (libbengine.a using mingw32 via TDM-GCC-32).
(For the record, the code compiled fine before separation)
Back in the main game code (main.cpp, etc) the compiler knows the relevant include and lib directories and compilation can at least locate the necessary headers and lib.
However, I get this error: undefined reference to '__glewCreateProgram'
Any ideas as to what is getting lost in translation (so-to-speak)?
I have been reading around all over the place; researching compilation, static libraries, ar.exe, but am having no luck (I am still looking).
If you want any more pertinent information, I will happily provide it; for now I shan't clog up the post any further.
Cheers
To give a basic idea of the error in CodeLite:
Main project linker settings:
bengine project linker settings (compiled as static lib.a):
It seems the problem was solely with linking order. As can be seen in the second image in my question (Main linker setting) - "Bengine" should have been at the top of the list, not the bottom.
This may be mingw32 specific; I am not sure.
Well, after all those hours, I feel somewhat foolish...
At least I have learned some things along the way.
In answer to one of my recent questions, it was suggested that I use a function in boost to solve my problem. This is my first time using boost so I added the following .hpp file
#include <boost/algorithm/string.hpp>
and function call
boost::replace_all(marketPrices, "\\:", "-COLON-");
to my source file, then ran make to build my application using g++ as normal.
At this point I realized I had not added any new library to the link step in my makefile and fully expected the link step to fail. To my surprise it did not fail - not only that but the code ran exactly as it should have done without any complaint.
This surprises me to say the least - how did g++ know what to link to and why did it automatically do so? Or am I missing something fundamental with the way the boost libraries operate? I know that boost uses a lot of templating and this is an aspect of C++ that I am not overly familiar with so I am wondering if perhaps this has something to do with what I am seeing.
Some of the boost libraries are header-only meaning that there is no binary to link against. Other libraries like boost::thread will require you to add a new lib to the linker.
I've recently been using GtkD with the D programming language to create native applications. I've downloaded all the necessary files and got everything running so i can now compile and produce sample apps.
My question is that in some of the guides it tells you to compile GtkD on the platform you are using but what is the point? Once compiled you end up with a single lib file on Windows (GtkD.lib) and three lib files on Linux (ending in *.a). What are these files for and how are they used? Like i said everything seems to be working without doing anything with these files.
I'm guessing you can statically link these? but what's that for? To avoid compiling the GtkD source each time? I did actually try that using the pragma('lib', 'GtkD.lib') statement but it didn't seem to do anything.
Can anyone shine any light on this or explain why these files are needed?
Yes it's to avoid compiling the GtkD source each time.
Try to use pragma(lib, "GtkD"); rather than pragma('lib', 'GtkD.lib');
It works for me.
source files that are imported aren't compiled, they are only parsed for the symbol names and function signatures (and the templates)
creating libs is to avoid needing to recompile the entire library each time you need to rebuild and the compiler can then only use the .di files for the imports
this stems from the olden days where compiling took ages, and now it can be used to keep a library closed source
As a background, I am a developer of an opensource project, a c++ library called openframeworks, that is a wrapper for different libraries, like opengl, quicktime, freeImage, etc. In the next release, we've added a c++ library called POCO, which is similar to boost in some ways in that it's an alternative for java foundation library type functionality.
I've just noticed, that in this latest release where I've added the POCO library as a statically linked library, the .obj files that are produced during the act of compilation are really massive - for example, several .obj files for really small .cpp files are 2mb each. The overall compiled .obj files are about 12mb or so. On the flip side, the exes that are produced are small - 300k to 1mb.
In comparison, the same library compiled in code::blocks produces .obj files that are roughly the same size at the exe - they are all fairly small.
Is there something happening with linking, and the .obj process in visual studio that I don't understand? for example, is it doing some kind of smart prelinking, or other thing, that's adding to the .obj size? I've experimented a bit with settings, such as incremental linking, etc, and not seen any changes.
thanks in advance for any ideas to try or insights !
-zach
note: thanks much! I just tried, dumpbin, which says "anonymous object" and doesn't return info about the object. this might be the reason why....
note 2, after checking out the above link, removing LTCG (link time code generation - /GL) the .obj files are much smaller and dumpbin understands them. thanks again !!
I am not a Visual Studio expert by any stretch of imagination, having hardly used it, but I believe Visual Studio employs link-time optimizations, which can make the resulting code run faster, but can cost a lot of space in the libraries. Also, it may be (I don't know the internals) that debugging information isn't stripped until the actual linking phase.
I'm sure someone's going to come with a better/more detailed answer anyway.
Possibly the difference is debug information.
The compiler outputs the debug information into the .obj, but the linker does not put that data into the .exe or .dll. It is either discarded or put into a .pdb.
In any case use the Visual Studio DUMPBIN utility on the .obj files to see what's in them.
Object files need to contain sufficient information for linking. In C++, this is name-based. Two object files refer to the same object (data/function/class) if they use the same name. This implies that all object files must contain names for all objects that might be referenced by other object files. The executable however will need the names visible from outside the library. In case of a DLL, this means only the names exported. The saving is twofold: there are less names, and those names are present only once in the DLL.
Modern C++ libraries will use namespaces. These namespaces mean that object names become longer, as they include the names of the encapsulating namespaces too.
The compiled library obj files will be huge because they must contain all of the functions, classes and template that your end users might eventually use.
Executables which link to your library will be smaller because they will include only the compiled code that they require to run. This will usually be a tiny subset of the library.