From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2006-03-14 05:46:23
Joaquín Mª López Muñoz wrote:
> Hi again Markus,
> Joaquin M Lopez Munoz ha escrito:
>> Two static "instance" objects are created in each translation
>> unit, which is obviously a bug in the compiler.
>> I've been reading the following:
>> and looks like the bizarre template instantiation model
>> of Compaq C++ would allow us to:
> Now, rereading the document above, I realize that you're using
> the -timplicit_local template instantiation option, which "instantiate templates
> automatically, placing them in the output object with internal linkage", except
> for manually instantiated templates. My question is, why are you
> using such an option? Seems like the default -pt, as well as other options
> which guarantee external linkage, like -tused, -tall, etc. should work
> equally well. If you need to retain -timplicit_local for some reason, I
> can try to adjust the Jamfile for test_serialization so as to inhibit
> that option in this particular case.
Yes, I am aware that the current template instantiation model is not a good
choice, but IMO it's the best of the worst. :-(
Let me explain.
1. We need automatic instantiation. This rules out -nopt.
2. All instantiation models that somehow end up with placing automatically
instantiated templates into the output object with external linkage are
basically broken because you will get multiple defined symbols when
linking. (Well, they work as advertised, but are broken for our purpose.)
So this rules out -tused, -define_templates, and -tall.
3. We are now left with -pt, -tused_repository, -tall_repository, -tlocal,
-timplicit_local, and -tweak.
4. The first three (basically variations of -pt) sound just like what we
need. Except that compilation and link times explode. (You can use
-ttimestamp to tackle the compilation time issue, but this has its own
issues.) Except that storage usage explodes. Except that you have that
accursed template repository to take care off. (This can be done by
fiddling with boost.build and adding -ptr to the right spots, but every
time I tried this, as soon as static libraries are involved, the whole
thing just falls down in shambles. (You have to include the contents of the
repository into the static archive which easily busts every reasonable
command line length limit. And there were problems with updating the right
things in the archive, IIRC.)
5. So for all practical purposes we are left with -tlocal,
-timplicit_local, and -tweak.
6. -tlocal cannot be used because you end up with multiple instances of
7. -tweak sounds like The Right Thing, but one it was broken before V7.1
(and V6.5 is still mostly used), two it basically issues a warning for
every(!!!) weak symbol which can only be worked around and not really fixed
unless the Tru64 linker is fixed, three it forces you to used full symbol
preemption, and four it is not really tested.
8. So we have -timplicit_local left, which so far has been Good Enough. Up
to now I always have been able to add an explicit instantiation in the
right spot to fix the issue at hand, but this seems not to work now.
To make a long story short, I maybe should reconsider -pt or -tweak
regardless of what I wrote above, because the test passes with both
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk