libXt and LessTif

2002-01-26
2002-03-07
  • Martin Costabel

    Martin Costabel - 2002-01-26

    Programs using the lesstif Motif libraries (like xmgrace or nedit) crash with XFree86-4.2.0 with the error message

    Error: attempt to add non-widget child "DropSiteManager" to parent "xmgrace" which supports only widgets

    This error message is mentioned in the lesstif FAQ as being caused (on Linux) by a wrong linking order between libXm and libXt when compiling the binary in question. On Darwin, it is not caused by the compile time linking order, but is a runtime error that did not appear with XFree86-4.1.0.

    On Darwin with XFree86-4.2.0, it turns out that the error is caused by compiling libXt.6.0.dylib with twolevel_namespace as is done automatically now. It goes away when the -flat_namespace flag is used in compiling libXt.

    Now the -flat_namespace flag for the X libs had been in use for a while in the CVS tree, but has been abandoned by purpose already some months ago. The reason why the problem was only now detected has to do with the recent arrival of XFree-4.2.0 in the Fink community.

    Now my question is: What is the advantage of compiling the X libs with twolevel_namespace? Is it OK to compile them all with -flat_namespace or is it better to leave the others at twolevel and to compile only libXt with flat_namespace?

    --
    Martin

     
    • Torrey T. Lyons

      Torrey T. Lyons - 2002-01-26

      Everything on Mac OS X 10.1+ should be compiled with twolevel_namespace. There are advantages in launch speed as well as avoiding problems similar to this one with changes to libraries in the future. I suspect that the Linux FAQ is correct. If you use twolevel_namespace and the proper link ordering, after rebuild lesstif and the X clients in question they should work okay.

      Why does this problem show up at runtime? The twolevel_namespace libXt is slightly different in that it automatically pulls in libX11, libSM, and libICE. My guess is that libSM or libICE define some of the same symbols that are in libXm. Because the X clients using the lesstif libraries were not built using twolevel-namespace, these new duplicate symbols can cause the wrong version of the same symbol to be used at runtime. When everything is rebuilt with twolevel_namespace there may be duplicate symbol warnings, but these are not a problem so long as you ensure with your link ordering that the proper version of the symbol is the one being used. (The warning tells you this.)

       
      • Martin Costabel

        Martin Costabel - 2002-01-26

        Why don't you want to believe me?

        Changing the link order does NOT help.

        However:
        1. xfree86-4.2.0 compiled with default settings: Crash of every binary using libXm.
        2. Same xfree86-4.2.0, but libXt.6.0.dylib recompiled with -flat_namespace: No crash.
        Same binary, not recompiled.

        Just try it yourself, or have a look at the Fink mailing lists of the last 3 days.

         
    • Torrey T. Lyons

      Torrey T. Lyons - 2002-01-27

      >Why don't you want to believe me?
      >
      >Changing the link order does NOT help.

      I didn't realize from your previous message that you had tried rebuilding everything with twolevel_namespace, including libXm. I will certainly give this a try and see if I can make heads or tails of what is going wrong.

      I think the basic facts are that:

      1. It is definitely possible and best to use twolevel_namespace everywhere, although we apparently don't know how to do this yet.

      2. It may be that the way libXt is linked now is broken in a subtle way. Reverting to flat_namespace is a quick and dirty solution, but not the right way for the future.

      I am a little puzzled why you say that this just showed up in the Fink world. This change has been in the top of the XFree86 CVS tree for many months. If someone uses Fink to build XFree86 doesn't it just grab a known working snapshot from the tree? Since recent versions of Fink have included more recent versions of the X server than this change to the libraries, I would assume they would have also got the library and other changes. I ask, because it is good to know for future reference if Fink is only using/testing a part of the top of the tree code. (This is what we do with the XDarwin updates.)

       
      • Martin Costabel

        Martin Costabel - 2002-01-27

        > I didn't realize from your previous message that you had tried rebuilding
        > everything with twolevel_namespace, including libXm.

        Yes, I did, by hand, because lesstif insisted on using -flat_namespace, but it didn't change anything. OTOH I found some suspicious-looking lines in the compile log of nedit that seem to indicate that ld does not always respect library load order. Similar lines can be found in the xfree compile log, BTW.

        > cc -O2 -no-cpp-precomp -I/usr/X11R6/include  -I/sw/include nc.o
        > ../util/libNUtil.a -L/sw/lib -lXm -L/usr/X11R6/lib -lXpm -lXext
        > -lXt -lSM -lICE -lX11 -o nc
        > /usr/bin/ld: warning suggest use of -bind_at_load, as lazy
        > binding may result in errors or different symbols being used
        > symbol _vendorShellClassRec used from dynamic library /usr/X11R6/lib/libXt.dylib
        > (Vendor.o) not from earlier dynamic library /sw/lib/libXm.2.dylib(Vendor.lo)
        > symbol _vendorShellWidgetClass used from dynamic library /usr/X11R6/lib/libXt.dy
        > lib(Vendor.o) not from earlier dynamic library /sw/lib/libXm.2.dylib(Vendor.lo)

        Why does every library and her grandmother have to declare these two symbols, anyway?

        > I am a little puzzled why you say that this just showed up
        > in the Fink world.

        Fink until last week used to have an xfree86-base package with sources from about August 2001. The servers package was built from more recent sources. (Fink is still picking up pieces after ChrisP's disappearing act :-)) Now everything is at 4.2.0.

        I myself had used the xfree86 cvs HEAD sources, but apart from geomview hadn't used any binary linked with LessTif. And geomview just failed without any error message, because it is started from a wrapper script. It works now, too, with flat_namespace libXt.

         
    • Martin Costabel

      Martin Costabel - 2002-01-27

      The best solution of this problem has been found by Dave Morrison: Recompile all binaries that use LessTif with the -force_flat_namespace link flag.
      This works with whatever flag was used for the compilation of libXt and libXm.

       
    • Torrey T. Lyons

      Torrey T. Lyons - 2002-01-27

      I had forgotten about -force_flat_namespace, but that is a much better solution. This way only the  X clients that use LessTif have to take the flat namespace hit instead of every X client that uses libXt.

      >OTOH I found some suspicious-looking lines in the
      >compile log of nedit that seem to indicate that
      >ld does not always respect library load order.
      >Similar lines can be found in the xfree compile
      >log, BTW.
      ...
      > /usr/bin/ld: warning suggest use of -bind_at_load, as lazy
      > binding may result in errors or different symbols being used
      > symbol _vendorShellClassRec used from dynamic library /usr/X11R6/lib/libXt.dylib
      > (Vendor.o) not from earlier dynamic library /sw/lib/libXm.2.dylib(Vendor.lo)
      > symbol _vendorShellWidgetClass used from dynamic library /usr/X11R6/lib/libXt.dy
      > lib(Vendor.o) not from earlier dynamic library /sw/lib/libXm.2.dylib(Vendor.lo)

      The nature of the Mac OS X dynamic linker is such that it does not necessarily respect the library order specified at link time if there are duplicate symbols. This is one of the problems that twolevel_namespace is intended to solve. From "man ld":

      The static link editor simulates dynamic linking as if all the undefined symbols are to be bound  at program launch time.  The dynamic linker actually binds undefined symbols as they are encountered during execution instead of at program  launch.  However, the static link editor always produces the same linking as the dynamic linker as long as none of the dynamic shared libraries define the same symbol. Different linking can occur only when there is more than one definition  of a symbol and the library modules that contain the definitions for that symbol do not define and  reference exactly the same symbols.  In this case, even different executions of the same program can  produce different linking because the dynamic linker binds undefined functions as they are called, and this affects the order in which  undefined symbols are bound.

      The warnings you get about duplicate symbols in the XFree86 build logs are innocuous because the different libraries are referencing exactly the same things. Lesstif, however, is apparently trying to use libXt, but swap out some of the functions that it calls from underneath it. Twolevel_namespace is much more robust to duplicate symbols and just figures that although libXm defines some of the same symbols, it knows which ones libXt wants to use. (This is generally the right behavior as it guards against accidental confusion of duplicate symbols.)

      Other solutions besides -force_flat_namespace might be to use -bind_at_load as suggested by the warning or to link in the static version of libXt into libXm.

       
      • Martin Costabel

        Martin Costabel - 2002-01-27

        > Lesstif,
        > however, is apparently trying to use libXt, but swap out some
        > of the functions that it calls from underneath it.
        > Twolevel_namespace is much more robust to
        duplicate symbols
        > and just figures that although libXm defines some of the same
        > symbols, it knows which ones libXt wants to use. (This is generally
        > the right behavior as it guards against accidental
        > confusion of duplicate symbols.)

        Except that it appears not to work as intended...

        > Other solutions besides -force_flat_namespace might be to
        > use -bind_at_load

        That's one of the things we tried first, but it didn't make any difference. You'd even still get the advice about using -bind_at_load while you are actually using it.

         
    • tom wible

      tom wible - 2002-02-08

      i've been trying 2 compile ddd, which requires lesstif, but configure --host=ppc(is there a more specific host?) can't seem 2 find Xt.6:-(  and fink seems 2 have a problem 2:

      checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
      checking for dnet_ntoa in -ldnet... no
      checking for dnet_ntoa in -ldnet_stub... no
      checking for gethostbyname... yes
      checking for connect... yes
      checking for remove... yes
      checking for shmat... yes
      checking for IceConnectionNumber in -lICE... yes
      checking whether gethostname() is available... yes
      checking for Xt Revision Number 6... no
      checking for Xt Revision Number 5... no
      configure: error: You must have X11 Revision 5 or higher to compile Lesstif
      ### ./configure failed, exit code 1
      Failed: compiling lesstif-0.93.0-2 failed

      any clues would b appreciated;-)

       
    • tom wible

      tom wible - 2002-02-11

      i looked into the configure script & discovered it looking 4 XtSpecificationRelease, which should b in Intrinsic.h...but 4 some reason, it's empty:-(

      [tigger:X11R6/include/X11] tomw% ll Intrinsic*
      -r--r--r--  1 tomw  admin  0 Jan 19 14:53 Intrinsic.h

      wtf??? so i ftp'd that .h from a linux box, but it doesn't help:-(

       
    • tom wible

      tom wible - 2002-02-12

      turns out my xdarwin install was bad: most of the X11 include were empty:-( reinstalled both from the installer & manually fixed it...
      but now ddd barfs:

      c++ -DHAVE_CONFIG_H -I. -I. -I. -I./.. -isystem /usr/X11R6/include    -DNDEBUG -O2 -g -W -Wall -mminimal-toc  -trigraphs  -c stringify.C
      /bin/sh ./libtool --mode=link c++  -DNDEBUG -O2 -g -W -Wall -mminimal-toc  -trigraphs   -o stringify  stringify.o 
      c++ -DNDEBUG -O2 -g -W -Wall -mminimal-toc -trigraphs -o stringify stringify.o
      + cc -DHAVE_CONFIG_H -I. -I. -I. -I./.. -isystem /usr/X11R6/include -g -c -g ./ctest.c -o ctest.o
      cpp-precomp: could not open '/usr/X11R6/include'
      make[2]: *** [ctest.o] Error 1
      make[1]: *** [ctest.o] Error 2
      make: *** [all-recursive] Error 1
      [tigger:/sw/src/ddd-3.3.1] root# ll /usr/X11R6/include
      total 0
      drwxr-xr-x   6 root  admin   264 Jan 19 14:53 .
      drwxr-xr-x   9 root  admin   262 Feb 12 14:56 ..
      drwxr-xr-x  28 root  admin   908 Jan 19 14:53 DPS
      drwxr-xr-x  15 root  admin   466 Jan 19 14:53 GL
      drwxr-xr-x  63 root  admin  2098 Jan 19 14:54 X11
      drwxr-xr-x   4 root  admin   264 Jan 19 14:53 freetype2
      [tigger:/sw/src/ddd-3.3.1] root# ll /usr/X11R6/

      if it's ! 1 thing it's another;-{

       
    • Dennis Keller

      Dennis Keller - 2002-03-07

      There is a thread over at xdarwin on this very subject.

      http://www.xdarwin.org/forum/read.php?f=1&i=1091&t=1091

      I have the same trouble in building
      Nedit (Mac OS 10.1.3, Xfree 4.2). I have
      the lesstif libraries. I have even tried
      to compile and link a simple X Window
      editor (source from a Motif Book) and get the
      same run-time error.

      "Error:attempt to add non-widget child "DropSiteManager" to parent
      "nedit" which support only widgets"

      There definitely seems to be an oversight
      with the build of XFree 4.2 and possibly
      with LessTif as well (for Mac OS 10.1.x).

      I had NEdit built (running) with static libraries
      months ago with XFree 4.1 ( I think I
      was running Mac OS 10.0.x at that time).
      The makefile at nedit.org for Mac OS X
      did not work (X Tools?).

      This flat_namespace reference, however, is
      beyond me at this point-in-time.  I don't have
      enough knowledge to build XFree 4.2 from scratch
      or Lesstif for that matter.   I included this thread
      at xdarwin.org as well for a cross reference.

      P.S. Thanks to all the people who worked on XonX.
              Excellent Work from Great People!

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks