I'm building a project on XCode 3.2.6 gcc 4.2 which uses the boost graph library (1.45). The build results in an annoying warning:
/include/boost/concept/detail/concept_def.hpp:34:1: warning: "BOOST_concept" redefined
concept_def.hpp does not appear to contain any protection to prevent this sort of multiple definition and the boost graph library seems to be constructed so as to ensure it is included multiple times. In my case the include sequences are:
One definition:
/include/boost/concept/detail/concept_def.hpp:34
/include/boost/graph/buffer_concepts.hpp:9,
/include/boost/graph/graph_concepts.hpp:21,
/include/boost/graph/detail/adjacency_list.hpp:31,
Another definition:
/include/boost/concept/detail/concept_def.hpp:34
/include/boost/graph/graph_concepts.hpp:25,
/include/boost/graph/detail/adjacency_list.hpp:31,
While this is only a warning I find it hard to believe this was released with boost and hence expect I am doing something wrong.
Any ideas?
Thanks,
Barrie
Error only seems to happen on XCode, all of our other platforms (linux gcc4, msvc2010) build fine.
Here is our workaround:
boost/concept/detail/concept_def.hpp:12
#ifdef BOOST_concept
# undef BOOST_concept
#endif
PS:
In case you are wondering why we don't put an #ifndef guard around the whole file then know that for some strange reason this does not work!
The issue posted in the page is the same one we encountered. Following is our solution based on the concention
add #include in the end of a hpp file if is included in the beginning of the file.
we added the include concept_undef.hpp in the end of buffer_concepts.hpp accordingly and it does solve the compiling error.
Related
I am investigating using precompiled headers to reduce our compile times.
I have read the documentaiton on the subject here: https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html, where I read the following:
Only one precompiled header can be used in a particular compilation.
On the project whose build time I would like to improve, there are often very Long lists of includes. The above leads me to Think that to get the most performance improvements, I would have to make a collection of common includes, put them into a single Header file, compile and include that Header file.
On the other hand, I prefer to list my dependancies in particular file explicitly, so I would be inclined to include first the precompiled Header, followed by the Manual list of actual Header files.
I have two questions related to this:
Is my analysis and approach correct? Have I interpreted the statement correctly?
Doing this, I will use this file (say stdafx.h) in many places, thereby including files I don't need. I would like to explicitly list my dependencies however, for code documentation purposes.
Where I to do something like the following:
#ifdef USE_PRECOMPILED_HEADERS
#include "stdafx.h"
#else
#include "dep1.h"
#include "dep2.h"
#endif
I could periodically run a build without pre-compiled headers to check if all my dependencis are listed. This is a bit clunky however. Does anyone have a better solution?
If anyone has Information to help us obtain better results in our Investigation, I am happy to hear them.
Yes, your observation is absolutely fine!
You "would have to make a collection of common includes, put them into a single Header file, compile and include that Header file". This common header file is generally named as stdafx.h (although you can name it anything you want!)
I am afraid I don't really understand this part of the question.
EDIT :
Do you also want the standard headers (like iostream, map, vector, etc.) to be included as dependencies in the code documentation?
Generally this must be a NO. Hence, you must include only those header files in stdafx.h which are not under your control (i.e., [1] standard language includes [2] includes from dependent modules (mostly exposed interface headers)). Rest all includes (whose source is in the current project/module) must be explicitly included in each header file wherever required, and not put in the pre-compiled stdafx.h.
The above leads me to Think that to get the most Performance
improvements, I would have to make a collection of common
includes, put them into a single Header file, compile and
include that Header file.
Yes, this observation is correct: You put most (all?) includes in one single header file, which is then precompiled.
Which, in turn, means that...
any compilation without the aid of that header being precompiled will take ages;
you are relying on naming conventions or other means (documentation?) to make the information link between things referenced in your individual translation unit and their declaration.
I don't much like precompiled headers for those reasons...
I get a weird error when I attempt to compile some code I'm writing. I have several Fortran modules that I use for linear algebra computations; I don't want to make an application have to use all of them, so I wrote a wrapper module around them:
module linear_algebra_mod
use sparse_matrix_mod
use csr_matrix_mod
(etc.)
so that the end user can write use linear_algebra_mod to get all of them. However, I get the following error when I compile the linear algebra module:
gfortran -c sparse_matrix_mod.f90
gfortran -c csr_matrix_mod.f90
gfortran -c linear_algebra_mod.f90
linear_algebra_mod.f90:5.8:
use csr_matrix_mod
1
Internal Error at (1):
free_pi_tree(): Unresolved fixup
This was brought up in bug reports here and here but I wasn't able to glean from those what I should do.
To muddy the waters even further, when I instead use the csr_matrix module first, like so:
module linear_algebra_mod
use csr_matrix_mod
use sparse_matrix_mod
the error disappears.
In case this background information is helpful: the sparse_matrix module defines an abstract data type which the csr_matrix module extends and actually implements.
Internal compiler errors are always an indication of a bug in the compiler. Check if you have the latest version of the compiler, and if you do, file a bug report (you may have a look at the open bugs section to see if it has been reported by someone else already, but it is better to have a bug reported twice than to have one not reported at all, so don't worry too much about possibly filing a duplicate bug report).
The project I'm working on recently made a big effort to cleanup the code by turning on all the strictest GCC warnings and iterating until it compiled. Now, for instance, compilation fails if I declare a variable and don't use it.
After my latest development task there I see that there is a header file included somewhere that is now unnecessary. Is there any good way to find other such header files (and in such a way reduce dependencies) other than trying to remove a header file and seeing if anything breaks?
I am using GCC 4.3.2 on Linux.
No, there's no way to get gcc to fail if a header isn't required. Included headers can contain pretty much anything, so it is assumed that whoever included them had good reason to do so. Imagine the following somewhat pathological case:
int some_function(int x) {
#include "function_body.h"
return x;
}
It's certainly not good form, but it would still compile if you removed the include. So, an automatic checker might declare it "unnecessary," even though the behavior is presumably different when the function body is actually there.
Sometimes I need to use a gcc for cross-platform work, and sometimes gcc really amuses me with its warnings. For example:
#pragma once in a main file
This is very informative warning, but I really don't know what a 'main file' IS in terminology of gcc and WHY it must not contain #pragma once :). So, does any documentation exist that covers all gcc warnings and errors (mostly warnings, errors are trivial) with some comments on them?
The objective of '#pragma once' is to prevent a header from being reincluded. If you have it in a source file (usually a '.c' file), you won't be reading that twice (normally - I do know of a source file that reincludes itself [and I don't like it]; it does not use or want #pragma once, though!). So, a 'main file' in this context is one listed on the command line, for instance, rather than a header.
As to the subject matter of the question - the GCC manual does not seem to have a comprehensive list. I don't know whether there actually is one.
I am trying to save space in my executable and I noticed that several functions are being added into my object files, even though I never call them (the code is from a library).
Is there a way to tell gcc to remove these functions automatically or do I need to remove them manually?
If you are compiling into object files (not executables), then a compiler will never remove any non-static functions, since it's always possible you will link the object file against another object file that will call that function. So your first step should be declaring as many functions as possible static.
Secondly, the only way for a compiler to remove any unused functions would be to statically link your executable. In that case, there is at least the possibility that a program might come along and figure out what functions are used and which ones are not used.
The catch is, I don't believe that gcc actually does this type of cross-module optimization. Your best bet is the -Os flag to optimize for code size, but even then, if you have an object file abc.o which has some unused non-static functions and you link statically against some executable def.exe, I don't believe that gcc will go and strip out the code for the unused functions.
If you truly desperately need this to be done, I think you might have to actually #include the files together so that after the preprocessor pass, it results in a single .c file being compiled. With gcc compiling a single monstrous jumbo source file, you stand the best chance of unused functions being eliminated.
Have you looked into calling gcc with -Os (optimize for size.) I'm not sure if it strips unreached code, but it would be simple enough to test. You could also, after getting your executable back, 'strip' it. I'm sure there's a gcc command-line arg to do the same thing - is it --dead_strip?
In addition to -Os to optimize for size, this link may be of help.
Since I asked this question, GCC 4.5 was released which includes an option to combine all files so it looks like it is just 1 gigantic source file. Using that option, it is possible to easily strip out the unused functions.
More details here
IIRC the linker by default does what you want ins some specific cases. The short of it is that library files contain a bunch of object files and only referenced files are linked in. If you can figure out how to get GCC to emit each function into it's own object file and then build this into a library you should get what you are looking.
I only know of one compiler that can actually do this: here (look at the -lib flag)