c++/4244: Explicit template instantiation in library files broken

derrick@caltech.edu derrick@caltech.edu
Wed Sep 5 22:26:00 GMT 2001

>Number:         4244
>Category:       c++
>Synopsis:       Explicit template instantiation in library files broken
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 05 22:26:00 PDT 2001
>Originator:     derrick@caltech.edu
>Release:        Apple Computer, Inc. version gcc-926, based on gcc version 2.95.2 19991024 (release)
Mac OS X (10.0.4; Darwin 1.3.7)
I'm not really sure if this is the right place for this, since gcc-2.95.2 for Mac OS X has been tremendously hacked and since this might turn out to be a binutils issue.  Please tell me where to forward the matter if this is the wrong place.

Anyway, it seems that one cannot put explicit template instantiations into library files and get them to link properly.  For example, if we create the following files:
template<int N>
class A {
  int f();

#include "explicitinst.h"

template<int N>
int A<N>::f() { return N; }

template class A<1>;

#include "explicitinst.h"

int main() {
  A<1> a1;


and then run the following commands
c++ -c explicitinst.cc explicitinstmain.cc
ar cr libexplicitinst.a explicitinst.o
ranlib libexplicitinst.a
then ranlib immediately tells us something is wrong:
ranlib: warning for library: libexplicitinst.a the table of contents is empty (no object file members in the library define global symbols)
and as expected the final link refuses to work:
c++ -o explicitinstmain explicitinstmain.o -L. -lexplicitinst
/usr/bin/ld: warning empty table of contents: ./libexplicitinst.a (can't load from it)
/usr/bin/ld: Undefined symbols:
Everything works fine if we link the actual object file:
c++ -o explicitinstmain explicitinstmain.o explicitinst.o

Derrick Bass

PS: I've not been able to get the latest snapshots to bootstrap, so I can't tell if the problem goes away with gcc-3.1. 

PPS: If anyone can tell me a workaround, it would be most appreciated (the problem is occurring in a rather large library and the .a files have dozens of .o files, so linking  the .o files explicitly would be a bit painful).
See description

More information about the Gcc-bugs mailing list