RE: explicit template specialization in GCC 3.3

["Dana, Eric" <Eric_Dana at bmc dot com>]

Eddie,

  Since linking is order specific, try either:

    a.) g++  -g -O2   -o mmafm main.o templatei.o ../libefont/libefont.a \
             ../liblcdf/liblcdf.a -lm

    b.) try this is 'a' fails:
        g++  -g -O2   -o mmafm main.o ../libefont/libefont.a \
             ../liblcdf/liblcdf.a templatei.o -lm

--Eric Dana--



> -----Original Message-----
> From: Eddie Kohler [mailto:kohler@icir.org]
> Sent: Thursday, June 05, 2003 12:16 PM
> To: gcc@gcc.gnu.org
> Subject: explicit template specialization in GCC 3.3
> 
> Hi all,
> 
> I rely on a mix of implicit and explicit C++ template specialization,
> which
> GCC 3.3 seems to have broken (on Linux x86 and Mac OS X). Source code
> organization is as follows:
> 
>     In a library directory:
>     Library header files	Template class definitions, inline member
> 				function definitions
>     Library source files	Non-inline member function definitions,
> 				some conventional class definitions
> 	-> compiled into libwhatever.a (WITHOUT -fno-implicit-templates)
> 
>     In a main directory:
>     Main source files		#include "library header files"
>     'templatei.cc'		#include "library header files"
> 				#include "library source files"
> 				// explicitly instantiate all templates
> 				// needed by library + main source files
> 				template class T1<C1>;
> 				template class T2<C2>; ...
> 	-> compiled (again, without -fno-implicit-templates) and linked
> 	   with libwhatever.a
> 
> With GCC <3.3 this works fine, and my reading of the standard says that it
> is valid. GCC 3.3, however, complains at link time:
> 
> g++  -g -O2   -o mmafm  templatei.o main.o ../libefont/libefont.a
> ../liblcdf/liblcdf.a -lm
> main.o: In function `__static_initialization_and_destruction_0':
> /home/kohler/mminstance-1.20/mmafm/main.cc:60: undefined reference to
> `Vector<int>::~Vector [in-charge]()'
> ../libefont/libefont.a(psres.o): In function
> `Efont::PsresDatabase::~PsresDatabase [not-in-charge]()':
> /home/kohler/mminstance-1.20/libefont/psres.cc:39: undefined reference to
> `Vector<int>::~Vector [in-charge]()'
> ../libefont/libefont.a(psres.o): In function
> `Efont::PsresDatabase::~PsresDatabase [in-charge]()':
> /home/kohler/mminstance-1.20/libefont/psres.cc:39: undefined reference to
> `Vector<int>::~Vector [in-charge]()'
> ../libefont/libefont.a(psres.o): In function
> `Efont::PsresDatabaseSection::PsresDatabaseSection[not-in-
> charge](PermString)':
> /home/kohler/mminstance-1.20/libefont/../include/lcdf/string.hh:178:
> undefined reference to `Vector<int>::~Vector [in-charge]()'
> ...
> 
> But if I link 'templatei.o' in with the library 'libefont.a', instead of
> with the main program, everything links fine.
> 
> I've tried and failed to create a minimal test case that demonstrates this
> behavior. This tarball is all I've got:
> 	http://www.lcdf.org/type/mminstance-1.20.tar.gz
> 
> I would appreciate some advice.
> 
>   1. Is this method of template instantiation invalid?
>   2. If it's valid, is GCC 3.3's behavior a known bug?
>   3. If it's not a known bug, any pointers on how I could create a minimal
>      test case?
> 
> Thanks,
> Eddie Kohler