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
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.
So I've reached Chapter 6 of C++ Primer 5th edition. Section 6.1.3. covers separate compilation and compiling and linking multiple source files. It then goes on to show system prompts (e.g. $ CC factMain.cc fact.cc where $ is the system prompt and CC is compiler name) that you would use in order to produce an executable file, showing the compiler where the files are.
It then talks about compiling separately to get an object file, and then linking these to form an executable.
Now I could be wrong, but is this necessary in Xcode? The system prompts stuff and the like. When you make a project, you have a target, right? And that comes with a product, an executable. To add source files to this, don't you just right-click and add .cpp files and .h header files as necessary? Or is there something else I need to do, in a similar manner discussed in the book, to get separate compilation and linking.
Thanks in advance for all the help! =D
I don't know XCode at all, but IDEs are usually doing it the same way. They interpret your project file into series of separate source files that get compiled separately, and then run a linker to link it. All this happens without programmer interaction (IDEs are automatizing it to help and speed up the programming), but a good programer should know that he doesn't need IDE to compile a program - he can just run the compiler directly. In short - if you use your IDE you don't need to do it - but it's whats happening underneath.
I think this should be a simple question, but I can't find the answer.
I am having an issue with loading a ruby c++ extension that links with precompiled .a library.
I think the issue is that I complied the extension using g++ , but I think the .a library was compiled using xlC.
I am assuming that would be a problem, right?
How can I confirm this? Is there a way to tell which compiler created each object file?
I tried looking at obj dump, but I could not find any thing that would directly tell me if the two objects were created with different compilers or not.
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?
I have recently started learning C++ and coming from a Ruby environment I have found it very hard to structure a project in a way that it still compiles correctly, I have been using Code::Blocks which is brilliant but a downside is that when I add a new header file or c++ source file, it will generate some code and even though it is only a mere 3 or 4 lines, I do not know what these lines do. First of all I would like to ask this question:
What do these lines do?
#ifndef TEXTGAME_H_INCLUDED
#define TEXTGAME_H_INCLUDED
#endif // TEXTGAME_H_INCLUDED
My second question is, do I need to #include both the .h file and the .cpp file, and in which order.
My third question is where can I find the GNU GCC Compiler that, I beleive, was packaged with Code::Blocks and how do I use it without Code::Blocks? I would rather develop in a notepad++ sort of way because that is what I'm used to in Ruby but since C++ is compiled, you may think differently (please give advice and views on that as well)
Thanks in advance, ell.
EDIT: I'm on Windows XP & thanks for the lighting fast replies!
To answer your questions:
The lines are include guards. They prevent the header file being included more than once in any given translation unit. If it was included multiple times, you would probably get multiple definition errors.
Header files are #included in .cpp files and in other headers. .cpp files are not normally #included.
The C++ compiler that comes with Code::Blocks is called MinGW GCC, and can be found in the bin directory of the MinGW installation. To find it, do a Windows search via explorer for 'g++'. To use it, you will need to put the directory it is in on your search path. Note the version of the compiler that ships with Code::Blocks is quite old - you can get a much more recent version from here.
That's an inclusion guard, to prevent a .h file from being included twice. Besides saving time, this is often in fact required to avoid defining things twice.
You should include only the .h. The .c file will be linked to your program in some form. For small programs, you can just pass all the .c files to gcc, but larger programs will involve intermediate .o files or even libraries (static or dynamic).
You can definitely work without an IDE. There are many ways to install the gcc compiler on Windows, including Cygwin and MinGW. I think you are correct that Code::Blocks comes with a gcc executable, but I don't know where it is or what version.
Those lines make it so that if a file is #included twice, everything will continue to work. That in turn lets you treat header-file dependencies as a simple directed graph, which is definitely easiest.
You don't #include .cpp files. (Well, not unless you're an evil programmer. Don't do it!)
I'll let others (or google!) tell you about gcc, but it might help if you were to describe what platform you're using.
All of your questions have been answered by others, except this:
I would rather develop in a notepad++
sort of way because that is what I'm
used to in Ruby but since C++ is
compiled, you may think differently
(please give advice and views on that
as well)
I think this is a very bad idea. A fully fledged IDE with an integrated debugger, jump to symbol definitions, refactoring capabilities, a profiler, intellisense and more is practically a must for any real world project.
And the absolute best is Visual Studio* with Visual Assist X**. Code::Blocks pales in comparison ;)
* If you study in a university you can usually get it for free through MSDNAA; otherwise there the Visual Studio Express edition whicih is free
** 30 days evaluation period