Conference turris::c_plus_plus

3415.0. "partner problem with templates" by HYDRA::DONSBACH (Jeff Donsbach, Software Partner Engineering, DTN 297-6862) Wed Jan 29 1997 14:06

    The following long question/problem was sent in by a partner.
    Has anyone seen this problem before, and more importantly know
    if there is a solution?
    
    Jeff D.
    ------ partner's problem below -------
    
    Digital,
    
      I'm currently porting our apps to a DEC alpha running OSF1 V3.2.
    We're using the C++ compiler V5.5-004. 
    
    I'm having some troubles at link time with some of our template files.
    I've set
    up our C++ command line to use a 'central' repository for the template
    files. 
    Here's a sample compile command:
    
           cxx  -call_shared -ieee -ptr /tmp/cxx_repository -DDEC  
    -D__UNIX__    -g 
    -DEXPRESS_APP -DEXPRESS_GUI  -I../src 
    -I/usr/rogue -I/usr/express -I/usr/express/include 
    -I/usr/express/include/avs/yacl  -I/results/include/c++/dec
    -I/usr/include/X11 
    -I/usr/include/Xm -I/usr/express/motif_ui/ui -I. 
    -I/results/sources/src/exp_apps/src/output/dec -I/results/include  -c 
    ../src/main.cpp
    
    I use the same C++ options for ALL our compiles. I also use the same
    flags at link time, as we use 'cxx' to do the link, not an explicit call
    to 'ld'.
    
    At link time, the linker is finding all of our template .o files just
    fine. However, we are getting one undefined symbol that shouldn't be
    undefined. I'll try to explain.
    
    Here's one of the offending template files
    'CurveListIterator__TP4Well.cxx':
    
    #include <stdlib.h>
    #include <stddef.h>
    #include <stdio.h>
    #include <math.h>
    #include <assert.h>
    #include "rtypes.h"
    #include "rge.h"
    #include "rgamsg.h"
    #include "cheknull.h"
    #include "map.h"
    #include "colors.h"
    #include "expobj.h"
    #include "pov.h"
    #include "cntds.h"
    typedef CurveListIterator<Well * > __dummy_;
    
    One of the include files (cntds.h) includes another include file
    'kwsys.h'. The
    file kwsys.h contains the variable that is undefined at link time:
    
    typedef enum {TG_UNKNOWN=0, TG_KEYWORD,  TG_REAL, TG_STRING,
    TG_INTEGER,
                  TG_RANGE,   TG_OPERATOR, TG_EOF,  TG_ERROR, TG_INCLUDE,
    	      TG_LAST
    } tgtype;
    
    static char* token_type_str[TG_LAST+1] =
    {"UNKNOWN", "KEYWORD",  "REAL", "STRING", "INTEGER",
     "INTEGER RANGE",   "OPERATOR", "END-OF-FILE",  "READ-ERROR",
    "INCLUDE", 
    "LAST"};
    
    The variable 'token_type_str' is the variable that is undefined at link
    time. If I do an 'nm' command on the template .o file, I get:
    
    CurveListIterator__TP4Well.o:      token_type_str                   | 
    0000000000000088 | U | 0000000000000088
    
    
    Yet when I do an 'nm' command on other .o non-template files (that
    include the 
    same include files as the generated template file), I get:
    
    libdatasrc.a[cntdgprs.o]: token_type_str                   |
    0000000000015488 | d | 0000000000000088
    
    
    I don't know why the generated template file compiles differently than
    a 'normal' C++ file. If I compile the generated template file with our
    normal compile command,'nm' shows:
    
    CurveListIterator__TP4Well.o:        token_type_str                   | 
    0000000000001408 | d | 0000000000000088
    
    
    I've used the '-v' option to show me the actual compile command of the
    template files, and it is:
    
    /usr/lib/cmplrs/cxx/gemc_cxx -Xpreplatinum
    -Xirf/tmp/cxx_repository/alphaaaiCga 
    -signed -member_alignment -g2 -O2 -fptm su -cp
    p -show header -show source -readonly_strings -ansi_alias
    -weak_volatile 
    -ptr/tmp/cxx_repository -ptsuf.cxx.CXX.C.cc.CC.cpp.c
    -D_IEEE_FP -DDEC -I../src -I/usr/rogue -I/usr/express/include 
    -I/results/include/c++/dec -I/usr/include/X11 -I/usr/include/Xm
    -I. -I/results/sources/src/libraries/src/rge/dec -I/results/include
    -Xsd../src/ 
    -MD/tmp/cxx_repository/alphaaaiCga.o.d -XtrmCu
    rveListIterator__TP4Well -Xreq -o /tmp/cxx_repository/alphaaaiCga.o 
    /tmp/cxx_repository/CurveListIterator__TP4Well.cxx
    
    I took this command, and stripped out the options one by one, and the
    compiled 
    .o file
    would still show  token_type_str as undefined. 
    
    What is wrong here? Is it my compile options, or is it the compiler's
    problem?
    
    Thanks
    

>    I'm having some troubles at link time with some of our template files.
            
>    At link time, the linker is finding all of our template .o files just
>    fine. However, we are getting one undefined symbol that shouldn't be
>    undefined.
    
>    static char* token_type_str[TG_LAST+1] =
>    {"UNKNOWN", "KEYWORD",  "REAL", "STRING", "INTEGER",
>     "INTEGER RANGE",   "OPERATOR", "END-OF-FILE",  "READ-ERROR",
>    "INCLUDE", 
>    "LAST"};
>    
>    The variable 'token_type_str' is the variable that is undefined at link
>    time. If I do an 'nm' command on the template .o file, I get:
>    
>    CurveListIterator__TP4Well.o:      token_type_str                   | 
>    0000000000000088 | U | 0000000000000088
>    
>    
>    Yet when I do an 'nm' command on other .o non-template files (that
>    include the 
>    same include files as the generated template file), I get:
>    
>    libdatasrc.a[cntdgprs.o]: token_type_str                   |
>    0000000000015488 | d | 0000000000000088
        
        There are some things to keep in mind when using "static"
        declarations with templates.  On the OpenVMS side the
        documentation says (section 5.1  Automatic Instantiation
        Quick Start)
        
        	�   Use of static data and functions in template
        	    files is not supported.
        
        	    Because template declaration and definition files are
        	    header files, you must treat them as such. In template
        	    request mode, DEC C++ considers any references to static
        	    functions and data items as external references, and this
        	    consideration leads to unresolved symbols at link time.
        
        You may be running into the Digital UNIX version of this.
        
        Dan

The "Using DEC C++ for Digital Unix Systems" document says the same
thing at the same subsection.

The customer probably doesn't need/want the array declared "static", 
because EVERY .o whose .c includes 'kwsys.h' will have a copy of the
array [8*12 = 96 bytes] and the string literals [~ 100 bytes].