| Title: | C++ |
| Notice: | Read 1.* and use keywords (e.g. SHOW KEY/FULL KIT_CXX_VAX_VMS) |
| Moderator: | DECCXX::AMARTIN |
| Created: | Fri Nov 06 1987 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3604 |
| Total number of notes: | 18242 |
A customer of mine is using templates and is getting unresolved symbols at link time. The problem occurs when a source file gets compiled (a.C), it generates a bunch of template instantiated objects in ./cxx_repository, which don't get archived into the library like a.o does. So, a.o gets into the archive library and the instantiated objects in ./cxx_repository don't; then, at link time there are unresolved symbols. Any ideas on how to best approach this? TIA, -Keith Austin [Posted by WWW Notes gateway]
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3502.1 | DECC::FOLTAN | Wed Mar 19 1997 09:35 | 11 | ||
Look in the "Using DEC C++ for Digital UNIX Systems" guide. Chapter 5 on Templates, section 5.2.9 describes in detail how to build libraries and applications that use templates. Pay particular attention to section 5.2.9.1.1 and the description of the -Hf command line option. I think this is what you will eventually want. Lois | |||||
| 3502.2 | Similar problem / ? | ASIC::DEEGAN | Wed Mar 26 1997 01:40 | 12 | |
Well this works fine if you have only the library being compiled
in the area.
I'm working on a tool suite, where both the library and a program
which both use templates are compiled. If I do what the manual
sugguests I end up with .o's for template instances which shouldn't be
in the library and cause unresolved symbols.
Wouldn't it be nice if building shared libraries workd like building
the executable and pulled the appropriate templates instances into the
.so's? Is this possible, is this planned?
| |||||