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