Re: [boost] [serialization][tru64cxx]assertionfailedatextended type info.cpp

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:
>>
>> http://nf.apac.edu.au/facilities/software/CXX/ugutmpl.htm
>>
>> 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 
static objects.

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 
instantiation models.

Markus