openmotif apps (xpdf, grace) fail to run in Leopard

[someuser12]

This is a similar problem to #18114.

I'm trying to run xpdf on a fresh install of Mac OS X 10.5 with Xquartz 2.3.2 and a fresh install of MacPorts 1.7.0.

xpdf builds fine, but when I try to run it I get the following error message:

Warning: Widget must be a VendorShell.
Error: attempt to add non-widget child "dsm" to parent "xpdf" which supports only widgets

The same problem happens on another system where xpdf @3.02_2 built several month ago is running fine but a new build of xpdf @3.02_4 fails with the same error message.

This message might be caused by problems with openmotif (see ​http://www.faqs.org/faqs/motif-faq/part9/section-29.html, but here there is seemingly no problem of library order on the link command line).

[kernelblaha@…]

Cc Me!

[someuser12]

Cc Me!

[furio.mf@…]

Cc Me!

[someuser12]

Same problem with xdvi (xdvi from port texlive_base version 2007_5 fails to run with error message 'Error: attempt to add non-widget child "dsm" to parent "xdvi" which supports only widgets').

[gahs@…]

CC me too.

I was able to recover proper xpdf functioning by backing off to slightly earlier versions of openmotif and xpdf:

  sudo port deactivate openmotif
  sudo port activate openmotif@2.3.1-1_0
  sudo port deactivate xpdf
  sudo port activate xpdf@3.02_2

Now xpdf works again for me. Luckily I had these earlier versions still installed (but not "active"), so it was easy to revert temporarily.

[raphael@…]

Cc Me!

[sergio.roa@…]

Cc Me!

[0xced (Cédric Luthi)]

Cc Me!

[0xced (Cédric Luthi)]

Cc Me!

[0xced (Cédric Luthi)]

The workaround explained by Raphael in #18114 seems to also work for xpdf.

[sergio.roa@…]

Replying to cedric.luthi@…:

The workaround explained by Raphael in #18114 seems to also work for xpdf.

i tried without success :(

[ghosthound]

Replying to macosx12345@…:

This is a similar problem to #18114.

I'm trying to run xpdf on a fresh install of Mac OS X 10.5 with Xquartz 2.3.2 and a fresh install of MacPorts 1.7.0.

xpdf builds fine, but when I try to run it I get the following error message:

Warning: Widget must be a VendorShell.
Error: attempt to add non-widget child "dsm" to parent "xpdf" which supports only widgets

The same problem happens on another system where xpdf @3.02_2 built several month ago is running fine but a new build of xpdf @3.02_4 fails with the same error message.

This message might be caused by problems with openmotif (see ​http://www.faqs.org/faqs/motif-faq/part9/section-29.html, but here there is seemingly no problem of library order on the link command line).

I agree, the link order appears to be okay.

The problem seems to be triggered in xpdf/XPDFViewer.cc a line 1676:

pageNumText = XmCreateTextField(toolBar, "pageNum", args, n);

and occurs in libXt (libXt-1.0.5/src/Create.c in _XtCreateWidget()):

if (!ext

!ext->accepts_objects) {

params[1] = XtName(parent); num_params = 2; XtAppErrorMsg(XtWidgetToApplicationContext(parent),

"nonWidget", XtNxtCreateWidget,XtCXtToolkitError,

"attempt to add non-widget child \"%s\" to parent \"%s\" which supports only widgets",

params, &num_params);

}

If someone has more time to hunt this out (and/or more familiarity w/ X11 stuff, mine is horribly rusty) that'd be great, esp. as it seems to apply to multiple ports using OpenMotif.

[ghosthound]

cc'ing our x11 master

[jeremyhu (Jeremy Huddleston Sequoia)]

Can you please run the following for me? There may be some rogue libs or binaries still linking against the system X11 libs instead of the MacPorts ones:

cd /opt/local/lib
for f in *dylib; do otool -L $f | grep -q /usr/X11 && echo $f; done

cd /opt/local/bin
for f in *; do otool -L $f | grep -q /usr/X11 && echo $f; done

[ghosthound]

Replying to jeremyhu@…:

Can you please run the following for me? There may be some rogue libs or binaries still linking against the system X11 libs instead of the MacPorts ones:

cd /opt/local/lib
for f in *dylib; do otool -L $f | grep -q /usr/X11 && echo $f; done

cd /opt/local/bin
for f in *; do otool -L $f | grep -q /usr/X11 && echo $f; done

No output (i.e. nothing dragging in /usr/X11).

[jeremyhu (Jeremy Huddleston Sequoia)]

interesting... when built using lesstif instead of openmotif, xpdf fails with:

~/src/macports-trunk/dports/graphics/xpdf $ xpdf
Error: No paper information available - using defaults
Error: No display font for 'Courier'
Error: No display font for 'Courier-Bold'
Error: No display font for 'Courier-BoldOblique'
Error: No display font for 'Courier-Oblique'
Error: No display font for 'Helvetica'
Error: No display font for 'Helvetica-Bold'
Error: No display font for 'Helvetica-BoldOblique'
Error: No display font for 'Helvetica-Oblique'
Error: No display font for 'Symbol'
Error: No display font for 'Times-Bold'
Error: No display font for 'Times-BoldItalic'
Error: No display font for 'Times-Italic'
Error: No display font for 'Times-Roman'
Error: No display font for 'ZapfDingbats'
Warning: XmManager ClassInitialize: XmeTraitSet failed

Warning: 
    Name: xpdf
    Class: XmDisplay
    Display.c:_XmGetDropSiteManagerObject(549) called without an XmDisplay

Warning: 
    Name: xpdf
    Class: XmDisplay
    Display.c:_XmGetDropSiteManagerObject(549) called without an XmDisplay

Warning: 
    Name: xpdf
    Class: XmDisplay
    Display.c:_XmGetDropSiteManagerObject(549) called without an XmDisplay

Warning: 
    Name: xpdf
    Class: XmDisplay
    Display.c:_XmGetDropSiteManagerObject(549) called without an XmDisplay

Warning: 
    Name: xpdf
    Class: XmDisplay
    Display.c:_XmGetDropSiteManagerObject(549) called without an XmDisplay

Warning: 
    Name: xpdf
    Class: XmDisplay
    Display.c:_XmGetDropSiteManagerObject(549) called without an XmDisplay

Warning: 
    Name: xpdf
    Class: XmDisplay
    Display.c:_XmGetDropSiteManagerObject(549) called without an XmDisplay

Warning: 
    Name: xpdf
    Class: XmDisplay
    Display.c:_XmGetDropSiteManagerObject(549) called without an XmDisplay

Bus error

Thread 0 Crashed:
0   libXm.2.dylib                 	0x0026de58 XmDropSiteRegister + 88
1   libXm.2.dylib                 	0x002d3dac initialize + 844
2   libXt.6.dylib                 	0x0037e1e4 CallInitialize + 228
3   libXt.6.dylib                 	0x0037e894 xtCreate + 612
4   libXt.6.dylib                 	0x0037ee58 _XtCreateWidget + 696
5   libXt.6.dylib                 	0x0037ef14 XtCreateWidget + 164
6   libXm.2.dylib                 	0x002cc664 XmCreateTextField + 68
7   xpdf                          	0x00093210 XPDFViewer::initToolbar(_WidgetRec*) + 1104
8   xpdf                          	0x00098a6c XPDFViewer::initWindow(int) + 684
9   xpdf                          	0x000992d0 XPDFViewer::XPDFViewer(XPDFApp*, GString*, int, GString*, int, GString*, GString*) + 96
10  xpdf                          	0x0008c854 XPDFApp::open(GString*, int, GString*, GString*) + 84
11  xpdf                          	0x0009ca2c main + 2300
12  xpdf                          	0x000021d0 start + 64

[gahs@…]

Cc Me!

[rob.kalescky@…]

Cc Me!

[cjdeloye@…]

Replying to macosx12345@…:

I experienced the same problem on OS X 10.4.11 (both PPC and i386) trying to use xmgrace (port: grace) AFTER upgrading to macports v. 1.70 and doing a "port upgrade outdated".

The problem seems to come in from two name conflicts (_vendorShellWidgetClass, _vendorShellClassRec ) between libXm and the /opt/local/lib/libXt. My setup default is to use /usr/X11R6 not the /opt/local Xorg version of X11, so the linking against the Xorg libraries was unexpected. The linking error I get when doing a 'port -v build openmotif' is

/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning multiple definitions of symbol _vendorShellWidgetClass
/opt/local/lib/libXm.dylib(VendorS.o) definition of _vendorShellWidgetClass
/opt/local/lib/libXt.dylib(Vendor.o) definition of _vendorShellWidgetClass
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning multiple definitions of symbol _vendorShellClassRec
/opt/local/lib/libXm.dylib(VendorS.o) definition of _vendorShellClassRec
/opt/local/lib/libXt.dylib(Vendor.o) definition of _vendorShellClassRec

After experimenting, I could get openmotif to compile and successfully ran its demo binaries in /opt/local/share/Xm when forcing linking openmotif against the OS X system version of X11. The problem I was running into was that the default linker flag order appears to be '-L/opt/local/lib -L/usr/X11R6/lib', which drags in the macports Xorg libraries instead of the system X11 libs.

Thus, a temporary solution to this problem (albeit temporary and inelegant and which may not work on OS X 10.5 since the system X11 implementation is different) is to modify the openmotif Portfile to ensure that the /usr/X11R6/ branch is looked at before /opt/local by the compiler and linker. Applying the following patch to the Portfile (which also removes the Xorg dependencies from the openmotif port) accomplishes this and produced a working openmotif package for me.

To get xmgrace to work, similar changes to the configure.ldflags and configure.cppflags in the grace Portfile were made.

--- Portfile.org        2009-03-05 17:00:33.000000000 -0600
+++ Portfile    2009-03-05 17:06:29.000000000 -0600
@@ -33,12 +33,6 @@
        port:jpeg \
        port:libpng \
        port:libiconv \
-       port:xorg-libsm \
-       port:xorg-libXext \
-       port:Xft2 \
-       port:xorg-libXmu \
-       port:xorg-libXp \
-       port:xorg-libXt
 
 patchfiles      patch-demos-programs-peridoc-Makefile.in.diff \
                 patch-lib-Mrm-Makefile.in.diff
@@ -50,14 +44,14 @@
 
 # This block helps us link correctly and setup our pc files correctly when we are
 # +system_x11 and x11prefix is somewhere non-standard
-if { ![file exists ${prefix}/lib/pkgconfig/x11.pc] && ![file exists ${x11prefix}/lib/pkgconfig/x11.pc] } {
+#if { ![file exists ${prefix}/lib/pkgconfig/x11.pc] && ![file exists ${x11prefix}/lib/pkgconfig/x11.pc] } {
     # AC_X_PATH blindly asks xmkmf where X11 is, and it always uses /usr/X11R6.
     # These next three lines should cause AC_X_PATH to let us setup our CPPFLAGS
     # and LDFLAGS without interference
     configure.args-append --x-include=${prefix}/include --x-lib=${prefix}/lib
-    configure.cppflags-append -I${x11prefix}/include
-    configure.ldflags-append  -L${x11prefix}/lib
-}
+    configure.cppflags -I${x11prefix}/include -I${prefix}/include
+    configure.ldflags  -L${x11prefix}/lib -L${prefix}/lib
+#}
 
 configure.args  --mandir=${prefix}/share/man   \
                 --enable-xft   \

[jeremyhu (Jeremy Huddleston Sequoia)]

Fixed in r47999 (it accidently snuck in with the xorg-server-devel push, sorry for any confusion there). Basically, we need a flat namespace for libXt to behave.

[someuser12]

Replying to jeremyhu@…:

Fixed in r47999

Many thanks! It works for me = it allows to run xpdf and xdvi (and presumably xmgrace) just after upgrading xorg-libXt (no need to recompile the applications themselves).

[(none)]

Milestone Port Bugs deleted