ITEM: M8913L

prob w/static consrtuctors on link


prob w/static consrtuctors on link


        AIX 3.2.5

        Forced to compiler with a 3-party compiler that isn't recognizing
C++ static objects defined outside of main.  The customer says he has
heard there is a way to pass these objects to the linker, and would like
the appropriate option to do so.


The customer is using Micofocus compiler with C++, and it is not
creating the static objects at run time.  He called Microfocus, but
they told him they did not support C++.

Told customer we would get back with him, and check on ways to get those
static objects created.


Discovered the following paragraph in Item H9352L.

Using the Cobol compiler to perform the final link,
the C++ starup code is not being utilized.  XLC++ requires that the
C++ startup module /usr/lpp/xlC/lib/crt0.o is used.  If not, the
static constructors and destructors are not called on program startup
and exit, and therefore the C++ portions of the application will not
work; this is illustrated by the segmentation fault that is
experiencing.  *-->  There is no way (currently) to combine MF Cobol and XL
C++ if the C++ code has static constructors and destructors. \<--*

Might want to double-check to make sure this has not been changed.


Told customer about the above paragraph concerning static objects 
constructors.  He still thinks there should be a way to do this.  I
think that he needs to speak with a specialist  to
give him a confident, sure answer.


D:  Customer wanted an easy way to get the C++ code munched; since the
MF cobol compiler is used to do the final link, munch is not
automatically invoked, and this is the difficulty.

A:  I suggested the customer take all of their C++ code and pretend to
build a shared object.  Take this object, relink it to remove the
shared object attributes, and hand the result to the cobol compiler.

To do this, use the /usr/lpp/xlC/bin/makeC++SharedLib script to build
a shared object from _all_ C++ code.  This script invokes munch,
includes all named objects, and properly constructs an object file.
Then, use a command like

   ld -o tmp.o shr.o -bnso -r

to get a non-shared version of the object module.  Assume for this
example that shr.o is the output of makeC++SharedLib.  Pass the tmp.o
object to the cobol compiler, using the C++ startup code
/usr/lpp/xlC/lib/crt0.o, and link in the cobol.  The result should be
a valid application.

N:  Customer understood the steps, and will try this approach.


Action: Customer called in and needed help creating a shared library.
        Customer should compile all object code and then run the script
        /usr/lpp/xlC/bin/makeC++SharedLib.  This will create a 
        shared library.


D: Customer is having some problem with the compiler.  A test case of this form:

\#include \
\#include \

struct  _foo
{        int     i;
        int     j;
} foo;

typedef const   unsigned int mystructype;

static  mystructype     staticStruct[] = { 24, XtOffsetOf(struct _foo, j)};

{        cout \<\< staticStruct[0] \<\< endl;
        cout \<\< staticStruct[1] \<\< endl;
        cout \<\< XtOffsetOf(struct _foo, j) \<\< endl;

        return( 0 );
is not working on xlC  He gets a 0 for the static data structure
value for XtOffsetOf, but a correct value of 4 (in this example) from the
XtOffsetOf in a function.  The data structure is not initialized correctly
by the compiler.

A: Have tested this code on a 2.1 compiler; will have to install xlC 1.x
and test it.


D: Customer still cannot produce a binary that triggers the static
constructors and desctructors.

A:  Will research using the cobol compiler to build an application.


D:  Went over compile and link commands; can't get his system to
produce the same (expected) results as I can locally.


D:  Discovered that the makeC++SharedLib approach is a dead-end.  The
constructor/ destructor data structure created my munch for
applications is not the same as that created for shared objects, due
to some priority information.  Therefore, using the output of xlC -v
as a guide, it's necessary to invoke munch manually on the object
modules of interest.  For example, a command of the form

/usr/lpp/xlC/exe/munch -o munchstuff.C -t munchstuff file1.o \\
   file2.o ... /usr/lpp/xlC/lib/libC.a /usr/lib/libc.a

will generate in the source file munchstuff.C a list of the available
static construtors and destructors for objects file1.o, file2.o, etc.
This file must then be compiled (xlC -c munchstuff.C) and included in
the final link for the application.  For cobol, for example, the
command might be something like

cob -x -o main /usr/lpp/xlC/lib/crt0.o main.o file1.o ... \\
   munchstuff.o -lC -lm

This includes the correct startup module, and the
constructor/destructor list from munch.

An additional consideration is the use of archives.  Since archives
often contain unneeded object modules, and munch will generate a list
of symbols based on _all_ available modules, the -qtwolink option
combined with the -v option for xlC can be useful in determining the
steps necessary to automate the munch/link process for any given

Support Line: prob w/static consrtuctors on link ITEM: M8913L
Dated: March 1996 Category: N/A
This HTML file was generated 99/06/24~13:30:39
Comments or suggestions? Contact us