>>>>> On Fri, 30 Mar 2001 01:05:14 EST, "Chris Nash" <[EMAIL PROTECTED]> said:
Chris> I'm new to the list, but I hope someone can help me with a problem I'm
Chris> having building lesstif. More specifically, lesstif builds fine, but I
Chris> am having problems getting applications to run with it.
Chris> I've recently been getting X11R6 and Lesstif to work on a BeOS R5 x86
Chris> system using gcc 2.9.1. X seems to be working quite well at this point,
Chris> and since the current libtool is beginning to support BeOS targets,
Chris> building lesstif is also quite easy with only minor modifications of
Chris> the configure script. However I am having little success with
Chris> applications - mwm works, but any other application that opens a window
Chris> isn't working. This includes most of the test suite for lesstif. I am
Chris> getting the runtime error about "attempting to add non-widget
Chris> DropSiteManager to a parent that supports only widgets".
Chris> I read in the archive this is usually evidence of a link dependency
Chris> problem, but the link order is certainly correct (-lXm -lXt -lX11).
Chris> Linking with either static and dynamic libraries in BeOS does have a
Chris> few idiosyncrasies. Since the link order on the command line is right,
Chris> I need a little more information to help me locate why the problem
Chris> occurs and to see if there is a suitable workaround, and whether some
Chris> combination of static and dynamic libraries in either X or lesstif will
Chris> solve it. Of course I'd much rather have an all .so solution, but right
Chris> now, any solution would do.
Chris> Could anyone give me a clue as to which symbols I need to be examining
Chris> in the linker to see if they are coming from the right place
Chris> (presumably the executable needs to find something in libXm.so which
Chris> for some reason it is linking elsewhere)? Any help would be much
Chris> appreciated right now, I seem to have spent most of the past two weeks
Chris> doing make distclean and ../lesstiff-0.92.6/configure with the same
Chris> results every time!
The linking order problems are caused by these two symbols:
vendorShellClassRec
vendorShellWidgetClass
which are defined *AND* referenced in both -lXm and -lXt. Somehow you have to
convince the linker to use the -lXm definitions to satisfy the references in
both -lXm and -lXt. The -lXt definitions should not be used.
For typical elf-based dynamic loaders (Linux, Solaris etc), this is done by
passing '-lXm -lXt' to the linker, which adds them both as SO_NEEDED sections
to the executable. At runtime, the dynamic loader collects symbols from each
SO_NEEDED section in the order it finds them, discarding symbols it already
knows, and then fixes the references in all the loaded libraries using that
combined symbol table.
For typical static linkers, it is also done by specifying '-lXm -lXt' to the
linker. In this case, the linker extracts some .o's from -lXm which contain
user-referenced symbols and eventually ends up extracting -lXm:Vendor.o due to
internal references in -lXm. It then does the same for -lXt, but doesn't need
to extract -lXt:Vendor.o because it doesn't define anything that is still
undefined.
__Martin
