Answer: [NOTE: This may not a problem any longer; I believe that AIX is now
delivered with shared Xm libraries. If you know the status of this, email
kenton@nojunk.rahul.net.]

Sakari Jalovaara wrote: There is a problem: Xm redefines VendorShell and the
AIX linker put _both_ Xm's and Xt's VendorShell into programs.  When an AIX
shared library is created as many references inside the library are resolved
as possible.  If the symbol vendorShellClassRec is defined in libXt and
referenced, say, from a function XtFoo() also in libXt, the "ld" run that
creates the shared library resolves the reference:

XtFoo() -> vendorShellClassRec

Then I create the Motif library that has its own vendorShellClassRec and an
XmBar() function that uses it; libXm will also contain a resolved reference to
vendorShellClassRec:

XmBar() -> vendorShellClassRec

Finally, I link a program that uses both XtFoo() and XmBar() and the program
will end up with _two_ independent "vendorShellClassRec"s:

XtFoo() -> vendorShellClassRec [Xt version]
XmBar() -> vendorShellClassRec [Xm version]

Instant schizo zaphod mode.  In reality, vendorShellClassRec is not referenced
from functions but from other widget class records.

I can't just pull Vendor.o out from the shared Xt (Vendor.o appears to define
the only external symbols redefined by libXm) because AIX shared libraries
apparently can't contain unresolved external references.  If I take out
Vendor.o I have to take out every other file that uses symbols defined there -
and then files that need those files, etc.  I tried it and ended up with three
or four object files in libXt and the res non-sharable.

I kludged around this by putting all of libXt (minus Vendor.o) into the shared
libXm.  It isn't a pretty solution but it works - and beats having a
statically linked two-megabyte "periodic" demo...