Template instantiation and multiple binaries in same directory

Question

Forte C++ 5.3
Solaris 8 w/Recommended Patch Cluster: Mar 20/03
Several ACE [see http://www.cs.wustl.edu/~schmidt/ACE.html] Makefiles direct the creation of multiple binary executables in the same directory. My build [i.e. GNU make] of ACE test programs results in successful creation of only the first of the multiple binaries. All binaries after the first have link errors. The link errors seem to be caused by the linker's failure to pick up template instantiations the were already created when the first binary was compiled and linked.
The $64000 question seems to be: Why does Forte's link line include the appropriate file from the template repository in the first case but not in subsequent cases? The first of the executables, MCast_Fragment_Test, links correctly because the linker picks up the singleton_ instantiation from the template repository - you can see this with the "-verbose=template" switch. However, the second of the test executables, RMCast_Reassembly_Test, fails to link because the same singleton_ instantiation [i.e. the same file] is not picked up:
% export ACE_ROOT=/tools/pkg/ace/ace5.3.1-sunc++/ACE_wrappers
% cd $ACE_ROOT/tests/RMCast
% gmake CCFLAGS="-verbose=template -fast -O3" exceptions=1
shared_libs=1 static_libs=1 threads=1 distrib=1
CC -verbose=template -fast -O3 -I..
-DACE_HAS_EXPLICIT_TEMPLATE_INSTANTIATION
-I/tools/pkg/ace/ace5.3.1-sunc++/ACE_wrappers
-DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ -c
-o .obj/RMCast_Fragment_Test.o RMCast_Fragment_Test.cpp
o o o
"../test_config.h", line 314: Information: Instantiating
ACE_Singleton<ACE_Test_Output, ACE_Null_Mutex>::singleton_.
ccfe: Information: Invoking:
"/tools/forte_c++/SUNWspro/bin/../WS6U2/bin/CC
-ptd/tmp/03764.TEMPLATE_FILE.s
-ptc/tmp/03764.TEMPLATE_FILE.ir
-o $ACE_ROOT/tests/RMCast/.obj/SunWS_cache/CC_obj_z/\
temp.shuriken.3767.zr7WQNsTBFiWx9j3KXv3.o
-verbose=template -fast -O3 -I..
-DACE_HAS_EXPLICIT_TEMPLATE_INSTANTIATION -I$ACE_ROOT
-DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ -c ".
o o o
CC -verbose=template -fast -O3 -I..
-DACE_HAS_EXPLICIT_TEMPLATE_INSTANTIATION
-I$ACE_ROOT -DACE_HAS_EXCEPTIONS -D__ACE_INLINE
-mt -xildoff -L$ACE_ROOT/ace -L./
-o RMCast_Fragment_Test .obj/RMCast_Fragment_Test.o
-lACE_RMCast -lACE -lsocket -ldl -lnsl -lgen -lposix4
CClink: Information: Invoking:
"/tools/forte_c++/SUNWspro/bin/../WS6U2/bin/CC
-ptl -verbose=template -fast -O3 -I..
-DACE_HAS_EXPLICIT_TEMPLATE_INSTANTIATION
-I/tools/pkg/ace/ace5.3.1-sunc++/ACE_wrappers
-DACE_HAS_EXCEPTIONS
-D__ACE_INLINE__ -mt -xildoff
-L/tools/pkg/ace/ace5.3.1-sunc++/ACE_wrappers/ace
-L./
$ACE_ROOT/tests/RMCast/.obj/SunWS_cache/CC_obj_N/ND6YV9mCPjF6W_mdb9HD.o
$ACE_ROOT/tests/RMCast/.obj/SunWS_cache/CC_obj_W/Wo599T9ON0ragDRfBzx1.o
$ACE_ROOT/tests/RMCast/.obj/SunWS_cache/CC_obj_0/0K1qNfk0TfJC_d7Uf0Iy.o
### SUCCESS: The following object file contains the 'singleton_'
### definition. Look for blahblah.zr7WQNsTBFiWx9j3KXv3.o, above.
$ACE_ROOT/tests/RMCast/.obj/SunWS_cache/CC_obj_z/zr7WQNsTBFiWx9j3KXv3.o
$ACE_ROOT/tests/RMCast/.obj/SunWS_cache/CC_obj_L/LLYlbLynG-qBErnxnavz.o
$ACE_ROOT/tests/RMCast/.obj/SunWS_cache/CC_obj_2/2nXCDDGsUTu5P0ypRsj6.o
.obj/RMCast_Fragment_Test.o -lACE_RMCast -lACE -lsocket -ldl -lnsl
-lgen -lposix4 -o RMCast_Fragment_Test ".
CC -verbose=template -fast -O3 -I..
-DACE_HAS_EXPLICIT_TEMPLATE_INSTANTIATION
-I$ACE_ROOT -DACE_HAS_EXCEPTIONS -D__ACE_INLINE__
-c -o .obj/RMCast_Reassembly_Test.o RMCast_Reassembly_Test.cpp
CC -verbose=template -fast -O3 -I..
-DACE_HAS_EXPLICIT_TEMPLATE_INSTANTIATION
-I$ACE_ROOT -DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ -mt -xildoff
-L$ACE_ROOT/ace -L./
-o RMCast_Reassembly_Test .obj/RMCast_Reassembly_Test.o
-lACE_RMCast -lACE -lsocket -ldl -lnsl -lgen -lposix4
CClink: Information:
Invoking: "/tools/forte_c++/SUNWspro/bin/../WS6U2/bin/CC -ptl
-verbose=template -fast -O3 -I..
-DACE_HAS_EXPLICIT_TEMPLATE_INSTANTIATION
-I$ACE_ROOT -DACE_HAS_EXCEPTIONS -D__ACE_INLINE__ -mt -xildoff
-L$ACE_ROOT/ace -L./
$ACE_ROOT/tests/RMCast/.obj/SunWS_cache/CC_obj_N/ND6YV9mCPjF6W_mdb9HD.o
$ACE_ROOT/tests/RMCast/.obj/SunWS_cache/CC_obj_W/Wo599T9ON0ragDRfBzx1.o
$ACE_ROOT/tests/RMCast/.obj/SunWS_cache/CC_obj_0/0K1qNfk0TfJC_d7Uf0Iy.o
$ACE_ROOT/tests/RMCast/.obj/SunWS_cache/CC_obj_L/LLYlbLynG-qBErnxnavz.o
$ACE_ROOT/tests/RMCast/.obj/SunWS_cache/CC_obj_2/2nXCDDGsUTu5P0ypRsj6.o
### FAILURE: No blahblah/CC_obj_z/zr7WQNsTBFiWx9j3KXv3.o among the
### above object files pulled from the template repository.
.obj/RMCast_Reassembly_Test.o -lACE_RMCast -lACE -lsocket -ldl -lnsl
-lgen -lposix4 -o RMCast_Reassembly_Test ".
Undefined first referenced
symbol in file
ACE_Singleton<ACE_Test_Output,ACE_Null_Mutex>::singleton_
$ACE_ROOT/tests/RMCast/.obj/SunWS_cache/CC_obj_L/LLYlbLynG-
qBErnxnavz.o
[Hint: static member
ACE_Singleton<ACE_Test_Output,ACE_Null_Mutex>::singleton_ must be
defined in the program]
ld: fatal: Symbol referencing errors. No output written to
RMCast_Reassembly_Test
gmake: *** [RMCast_Reassembly_Test] Error 1
FYI - A manual relink of RMCast_Reassembly_Test while explicitly
specifying
$ACE_ROOT/tests/RMCast/.obj/SunWS_cache/CC_obj_z/zr7WQNsTBFiWx9j3KXv3.
o successfully created the executable.
Additional Info: If I swap RMCast_Fragment_Test with RMCast_Reassembly_Test in the build order, i.e.:
BIN = RMCast_Fragment_Test \
RMCast_Reassembly_Test \
becomes
BIN = RMCast_Reassembly_Test \
RMCast_Fragment_Test \
then RMCast_Reassembly_Test links correctly, but RMCast_Fragment_Test
doesn't.
Generalization: In all cases, the first binary links successfully
while subsequent binaries fail to link successfully.
Regards,
... Dave

Answer 1

Thank you for your reply, but it raises some questions:
(1) There are people doing regular builds of ACE [see http://tao.doc.wustl.edu/scoreboard/ace.html] using Solaris-8/Forte, but my particular issue is not one that they see. They use the same Makefiles, so why do they not experience the same problem?
(2) You acknowledge that my observations are consistent with expected behaviour, but who expects that behaviour? Does Sun not accept that this behaviour amounts to a bug?
(3) Your suggested workarounds are appreciated, but there may be additional options. The more I know about the template related mechanisms employed by the compiler and linker, the better I am able to identify alternative workarounds. For example, after linking a binary, could I touch(1) one or more files in the template repository to positively effect the outcome for building the next binary?
Regards,
... Dave