From: mathog@seqaxp.bio.caltech.edu
Sent: Wednesday, January 19, 2000 6:49 PM
To: Info-VAX@Mvb.Saic.Com
Subject: Re: xaw3d,x11kit undefined symbol

In article <862tas$3hn@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu writes:
>I'm trying to port the current Xterm (the one in use on Linux).  This
>requires Xaw of a more recent vintage than the one packaged with Xterm021
>(to pick up XtGravity in treep.h and other things).  I'm trying to use
>Xaw3D from the X11KIT distribution.  I can get everything to compile, just
>a few residual informationals and warnings, but link results in: 
>
>LINK-W-NUDFSYMS, 13 undefined symbols:
>%LINK-I-UDFSYM,         SCROLLBARWIDGETCLASS
>%LINK-I-UDFSYM,         SIMPLEMENUWIDGETCLASS
>%LINK-I-UDFSYM,         SMEBSBOBJECTCLASS
>%LINK-I-UDFSYM,         SMELINEOBJECTCLASS
>%LINK-I-UDFSYM,         XMUPRINTDEFAULTERRORMESSAGE
>%LINK-I-UDFSYM,         _XA_COMPOUND_TEXT
>%LINK-I-UDFSYM,         _XA_LENGTH
>%LINK-I-UDFSYM,         _XA_LIST_LENGTH
>%LINK-I-UDFSYM,         _XA_TARGETS
>%LINK-I-UDFSYM,         _XA_TEXT

Here's the story.  The problem comes up because of the way ATOMS.C in XMU
is compiled by X11KIT in order that a shared library can be built.  Here's a
demonstration: 

$ cc/share atoms.c
Type    Symbol Name                         Flags  Value  Psindx    P3     P4
--------------------------------------------------------------------------------
SYM  _XA_ATOM_PAIR                           lrgs      0      8      0      0
<snip>
SYM  _XA_TEXT                                lrgs      0     1B      0      0
SYM  _XA_TIMESTAMP                           lrgs      0     1C      0      0
SYM  _XA_USER                                lrgs      0     1D      0      0
SYM  XMUGETATOMNAME                          prgs     60      3    140      1
SYM  XMUINTERNATOM                           prgs     A0      3     60      1
SYM  XMUINTERNSTRINGS                        prgs     30      3    160      1
SYM  XMUMAKEATOM                             prgs      0      3      0      1
SYM  XMUNAMEOFATOM                           prgs     C0      3     50      1

$ cc/extern=common/share atoms.c
$ symbols atoms.obj
Type    Symbol Name                         Flags  Value  Psindx    P3     P4
--------------------------------------------------------------------------------
SYM  XMUGETATOMNAME                          prgs     60      3    140      1
SYM  XMUINTERNATOM                           prgs     A0      3     60      1
SYM  XMUINTERNSTRINGS                        prgs     30      3    160      1
SYM  XMUMAKEATOM                             prgs      0      3      0      1
SYM  XMUNAMEOFATOM                           prgs     C0      3     50      1

That is, adding /extern=common kills the _XA_ symbols.  If memory serves
this means that the .opt file used to link the shared executable must have
added to it lines like:

SYMBOL_VECTOR = (_XA_TEXT=PSECT)

It would be really convenient if there was an _automatic_ way to tell the
compiler/linker combination to produce the right set of .opt files so that a
shared image could be produced more easily.  For instance, the compiler 
certainly can detect that the _XA_* variables need special treatment. A new
qualifier, something along the lines of the _really useful_ /prototype
qualifier could be added which would allow a shared library to be built
something like this: 

$ write ofil: "GSMATCH=lequal,1,1000"
$ cc/share/extern=common/make_share_opt module1.c
$ cc/share/extern=common/make_share_opt module2.c
$! etc.
$ cc/share/extern=common/make_share_opt moduleN.c
$ library/create/object all.olb *.obj
$ append/new module*.opt all_of_them.opt
$ open/append ofil: all_of_them.opt
$ write ofil: "GSMATCH=lequal,1,1000"
$ close ofil:
$ @place_lines_in_correct_order all_of_them.opt
$ link/share=all.exe all_of_them.opt/opt

This would be much better than the method I used last time when I worked on
Xforms.  That was partially automated, using SYMBOLS to create some of the
SYMBOL_VECTOR statements (those for functions), but it still required a lot of
manual labor to detect the global variables which needed their own PSECT
statement, as above.

Regards,

David Mathog
mathog@seqaxp.bio.caltech.edu
Manager, sequence analysis facility, biology division, Caltech 
