Re: Help needed with strange compiler/linker behavior (boost, Green Hills)
On Feb 21, 4:02 pm, "Brian Neal" <bgn...@gmail.com> wrote:
We experienced the following bizarre compiler/linker problem; it is so
strange I can't really put a good title on this thread, nor do I know
how to google this, sorry. Just bear with me and allow me to explain.
I'm hoping some people out there may help us figure out what is going
on here.
I'm afraid my answer is very implementation specific, and not
really on topic for this group, but maybe the moderators will
let it through because of it's historical content.
We have a large and complex C++ application that is targeted for one
of the real-time Linux variants. We used g++ as our compiler. It uses
some boost libraries. We are now porting it to the Green Hills
Integrity real-time OS environment and tool set.
[...]
Finally we get to the the weird part. In the Multi IDE we single click
on one of our source files whose object code gets infected with the
code for nth_as_str(), and then click on the compile button. It
compiles. Now we introduce a syntax error in the boost file
date_generators.cpp (located way over in another directory), and
recompile *our* file only. The compiler suddenly reports the syntax
error in date_generators.cpp. WHAT??? We didn't tell it to compile
that file. Scons is apparently doing the same thing.
So now I think maybe someone is doing a #include on
date_generators.cpp somewhere. So I use scons to tell me the
dependency tree and include tree for our file. Nope,
date_generators.cpp is not on the list, although date_generators.hpp
is. So we rename date_generators.cpp thinking now the compiler will
complain it can't find it if it is indeed trying to #include it
somehow...but no, now it compiles our file just fine and does not put
the code for nth_as_str() into our object file. We can even get a link
if we repeat this process on the other files.
This sounds a bit like CFront (the very first implementation of
templates). Except that CFront only did the include at link
time (and I think, but I'm not sure, that it passed some options
to the compiler to prevent it from generating code for anything
but template instantiations). For compatibility reasons, EDG
has definitly supported this mode in the past, and given their
reputation for supporting just about everything that anyone has
ever done, I would be very surprised if they didn't support it
today. The normal model when working with CFront was that a
header either defined and declared templates, or it defined and
declared non-templates, and that the correspondingly named
source file followed suite. Unlike "modern" implementations,
the header file did NOT include the function definitions for the
templates; these were in a normal source file. CFront would
then pick up this source file at link time (using the include
path), and compile a small dummy source which triggered the
desired instantiations. Most compilers which normally support
the more recent explicit inclusion model (sometimes called the
Borland model) will do this implicit inclusion at compile time,
however, if they try to support the CFront model. (And most do,
if they've ever been based on CFront.)
EDG has definitly supported the CFront model in the past, and
I'm almost sure it still does so, although this is not the only
model they support (far from it), and not their preferred model.
Still, which models are available, and which one you get by
default, depends on how the EDG front end has been integrated
into the compiler; EDG cannot force their customers to always do
the right thing.
In this case, I'd very definitly restudy the compiler
documentation, especially with regards to options concerning the
template instantiation model. I believe that Green Hills has
used the CFront front end in the past, and have every reason to
support that model. It shouldn't be the only model they support,
however; IMHO, it shouldn't even be the default, today.
If that doesn't turn up anything, then I think you're stuck with
splitting the template parts of the header out into a separate
header, says date_generators_temp.hpp, and including that from
date_generators.hpp. Since there won't be a
date_generators_temp.cpp, the compiler won't find it, and you'll
be OK.
We worked around the problem by renaming the directory our home built
boost date_time library is in so the compiler would not find
date_generators.cpp (more on this below). Needless to say, we don't
understand all this and have several wild theories, none of which we
can confirm. Here are some of the theories:
[...]
- Another wild theory is that the GHS compiler is being overly
aggressive and seeking out .cpp files for matching .hpp files to do
inlining or some other optimization. But in general, the compiler
seems pretty conservative given the default switch settings and that
seems like science fiction given other compilers we are familiar with.
Or is it? We certainly haven't turned on optimizations yet.
Nothing to do with optimization, but you're probably not far
from the truth. This is more or less the way CFront (and thus
earlier versions of Green Hills) worked, and you're probably
getting some sort of compatibility mode.
- This only seems to happen when we have both the boost root and our
own boost date time library (we named them with similar path names)
accessible in the set of -I include paths. However it is still a great
leap to believe a compiler, when looking for date_generators.hpp is
going to go looking on it's own for date_generators.cpp if it happens
to be in the set of -I include paths. Or is it?
That's the way templates originally worked. You didn't put the
implementation in the header, nor explicitly include it; the
compiler found it "by magic".
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]