ITEM: M8913L

prob w/static consrtuctors on link

Question:

prob w/static consrtuctors on link

Response:

ENV:
        AIX 3.2.5

DESCRIPTION:
        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.

Response:

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.

Response:

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.

Response:

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.

Response:

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.

Response:

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.

Response:

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)};

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

        return( 0 );
}
is not working on xlC 1.1.2.45.  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.

Response:

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.

Response:

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

Response:

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
application.




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