xorg-libXt-1.1.4_0 links shared libs with -flat_namespace on Yosemite

[jhowarth@…]

% otool -hv /opt/local/lib/libXt.6.dylib
/opt/local/lib/libXt.6.dylib:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    17       1872 DYLDLINK NO_REEXPORTED_DYLIBS

reveals that xorg-libXt-1.1.4_0 built on Yosemite is linking its shared libraries with "-flat_namespace" as seen from the missing TWOLEVEL flag expected from "-undefined dynamic_lookup".

[larryv (Lawrence Velázquez)]

Again with the Libtool MACOSX_DEPLOYMENT_TARGET bug. I’ll prepare a patch in a bit.

[larryv (Lawrence Velázquez)]

Turns out that fixing MACOSX_DEPLOYMENT_TARGET detection doesn’t change the linkage. It appears to be intentional. See configure, line 19172:

case $host_os in
    darwin*)
        OS_CFLAGS="-Wl,-flat_namespace"
	;;
    *)
        OS_CFLAGS=
        ;;
esac

This seems to be an upstream issue, although Jeremy is upstream.

[jhowarth@…]

This change is 7 years old....

​https://gitorious.org/xorg/libxt/commit/4e7031510d05471e77ff48355b23fc8e4302648c

[jeremyhu (Jeremy Huddleston Sequoia)]

I have no idea why Ben did that, and I seriously doubt he'd remember if I asked him. If you don't flatten the namespace, what happens?

[howarth.at.macports@…]

This is the earliest explanation I can find of why -flat_namespace was being used on libXt...

​http://lists.apple.com/archives/x11-users/2003/Mar/msg00210.html

Considering this is to solve issues with a libXm from 11 years back that probably bears little resemblance to how the current open motif builds libXm on darwin, I would suggest reverting the change and just watching for regressions from things like nedit or grace that use libXm.

[howarth.at.macports@…]

If the usage of -flat_namesapce is reverted in xorg-libXt's configure, the change does indeed break motif programs...

% nedit

UTF8 locale not supported.
Error: Shell widget nedit has zero width and/or height

% xmgrace
Warning: Widget must be a VendorShell.
Warning: Fatal Error: 
_XmGetDefaultDisplay cannot be used prior to VendorS.Initialize, returns NULL

Oops! Got SIGSYS

Please use "Help/Comments" to report the bug.
Abort

% molmol

MOLMOL 2K.2 

Version 2.1-2.6: Copyright (c) 1994-98 by
    Institut fuer Molekularbiologie und Biophysik, ETH Zurich
    Spectrospin AG, Faellanden, Switzerland

Version 2K.2: Custom version by Reto Koradi, 1999-2003

using Motif/OpenGL
Warning: Widget must be a VendorShell.
Error: attempt to add non-widget child "dsm" to parent "molmol" which supports only widgets

It might be worthwhile revisting this issue in case there is an actual fix to openmotif for darwin as it seems this hack may exist solely for libXm's benefit.

[howarth.at.macports@…]

Interestingly, removal of the -flat_namespace in the linkage of libXt cause momol to crash in the same manner as when -lXm isn't placed before -lXt on the linkage...

#18181

So the origin of these crashes are the two name conflicts (_vendorShellWidgetClass, _vendorShellClassRec ) between libXm and the /opt/local/lib/libXt.

[jeremyhu (Jeremy Huddleston Sequoia)]

Ok, then I suggest we remove the -flat_namesapce from libXt and just audit linkage for this unfortunate collision.

[howarth.at.macports@…]

Unfortunately removing -flat_namespace is going to nuke anything that uses openmotif. Also, even if we manage to tweak the linkages for packages built against openmotif to not crash, we will break all existing motif based binaries for darwin out there. At the very least, we need to demonstrate that a workaround does exist to allow the macports packages currently using openmotif to keep working.

[howarth.at.macports@…]

I just checked and molmol links -lXm before -lXt so that doesn't prevent the removal of -flat_namespace from the linkage from breaking the program at runtime.

[jeremyhu (Jeremy Huddleston Sequoia)]

What about updating openmotif and lesstif to not provide the symbols themselves but instead re-export the symbols from libXt?

Similar to what is discussed in ​https://www.mail-archive.com/lesstif@hungry.com/msg01446.html but with better binary compatibility.

[jeremyhu (Jeremy Huddleston Sequoia)]

xorg-libXt.patch

[jeremyhu (Jeremy Huddleston Sequoia)]

Actually no, that re-exporting won't work because libXt's is not acceptable.

[jeremyhu (Jeremy Huddleston Sequoia)]

I think the only reasonable thing to do is just fix libXt and make sure that motif dependent projects link in the correct order. As referenced by that link, many other platforms have been having the same issue for quite some time, so I suspect most projects (aside from nedit apparently) link in the expected order.

[howarth.at.macports@…]

As I said before, these packages are already linking -lXm and -lXt in the correct order and that is insufficient to inhibit the crashes when libXt is rebuilt with -undefined dynamic_lookup

/usr/bin/clang -I/opt/local/include -Os -DBUILD_UNTESTED_NEDIT nedit.o file.o menu.o window.o selection.o search.o undo.o shift.o help.o preferences.o tags.o userCmds.o shell.o regularExp.o macro.o text.o textSel.o textDisp.o textBuf.o textDrag.o server.o highlight.o highlightData.o interpret.o parse.o smartIndent.o regexConvert.o rbTree.o windowTitle.o calltips.o server_common.o rangeset.o linkdate.o ../Microline/XmL/libXmL.a \
	 ../Xlt/libXlt.a ../util/libNUtil.a -bind_at_load -L/opt/local/lib -Wl,-headerpad_max_install_names -lXm -lXp -lXpm -lXext -lXt -lSM -lICE -lX11 -o nedit

/usr/bin/clang -pipe -O1 -arch x86_64 -I.. -I. -I../T1lib/t1lib -I../Xbae -I/opt/local/include -I/opt/local/include main.o plotone.o files.o ssdata.o utils.o drawticks.o nonlfit.o lmdif.o as274c.o fit.o fourier.o graphs.o graphutils.o setutils.o regionutils.o objutils.o computils.o defaults.o params.o draw.o dlmodule.o pars.o missing.o  iofilters.o dates.o t1fonts.o device.o dummydrv.o mfdrv.o mifdrv.o psdrv.o pdfdrv.o svgdrv.o gd.o rstdrv.o humlik.o mathstuff.o Tab.o motifutils.o compwin.o comwin.o eblockwin.o editpwin.o events.o featext.o fileswin.o plotwin.o graphappwin.o helpwin.o hotwin.o locatewin.o miscwin.o monwin.o nonlwin.o printwin.o ptswin.o regionwin.o setwin.o strwin.o setappwin.o tickwin.o worldwin.o fontwin.o xutil.o x11drv.o xmgrace.o -o xmgrace -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -L/opt/local/lib   ../Xbae/Xbae/libXbae.a -lXm -lXpm -lXp -lXmu -lXt -lXext -lX11  -lSM -lICE  ../cephes/libcephes.a   ../T1lib/libt1.a -lpdf -ljpeg -lpng -lz -lm  

/usr/bin/clang -o molmol -I../../tools/include -I../../sg/include -I../../include -DMAXINT=INT_MAX -I/opt/local/include -I../.. -O -Wall MolMol.o MolInit.o ../../lib/libcip.a ../../lib/libcmd.a ../../lib/libui.a ../../lib/libgraph.a ../../lib/libio.a ../../lib/libpu.a ../../lib/libcalc.a ../../lib/libprim.a ../../lib/libdata.a ../../lib/libattr.a ../../lib/libfileio.a ../../lib/libos.a ../../sg/lib/libsg.a ../../tools/lib/libtools.a /opt/local/lib/libtiff.dylib /opt/local/lib/libjpeg.dylib /opt/local/lib/libpng.dylib /usr/lib/libz.dylib -L/usr/lib -L/opt/local/lib -lX11 -lXm -lGLU -lGL /System/Library/Frameworks/OpenGL.framework/Libraries/libGL.dylib /opt/local/lib/libGLw.dylib -lXmu -lXt -lXp -lXpm -lX11 -lXext -lSM -lICE -lm -lc -lmx

My understanding from those archived discussions is that linkage order is insufficient to work around this issue. So the question becomes, do we want to totally abandon motif by making this change in the absence of any proven breakage from over the last 11 years of using -flat_namespace in this case?

[howarth.at.macports@…]

My concern is that there still is critical legacy motif software in use. Most NMR users still use NMRDraw (​http://spin.niddk.nih.gov/NMRPipe/doc1/figs/tutorial-006.gif) from NMRPipe (​http://spin.niddk.nih.gov/NMRPipe/). If you make this change to libXt, all that motif software will be rendered unusable on the Mac once this change makes its way into the next Xquartz release.

[jeremyhu (Jeremy Huddleston Sequoia)]

What about just renaming the symbol in lesstif and openmotif and providing a macro to let clients find the new name?

[howarth.at.macports@…]

Replying to jeremyhu@…:

What about just renaming the symbol in lesstif and openmotif and providing a macro to let clients find the new name?

Unfortunately, I think they are tangled up together, If you create a patch that renames all of the instances of VendorShellClassRec and VendorShellRec to OMVendorShellClassRec and OMVendorShellRec, the build of motif fails at...

/bin/sh ../../libtool  --tag=CC   --mode=compile /usr/bin/clang -DHAVE_CONFIG_H -I. -I../../include -I.. -I./.. -DXMBINDDIR_FALLBACK=\"/opt/local/lib/X11/bindings\" -DINCDIR=\"/opt/local/include/X11\" -DLIBDIR=\"/opt/local/lib/X11\" -I/opt/local/include  -I/opt/local/include -I/opt/local/include  -pipe -Os -arch x86_64 -Wall -g -fno-strict-aliasing -Wno-unused -Wno-comment -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/libpng16 -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/libpng16 -I/opt/local/include    -MT DragC.lo -MD -MP -MF .deps/DragC.Tpo -c -o DragC.lo DragC.c
libtool: compile:  /usr/bin/clang -DHAVE_CONFIG_H -I. -I../../include -I.. -I./.. -DXMBINDDIR_FALLBACK=\"/opt/local/lib/X11/bindings\" -DINCDIR=\"/opt/local/include/X11\" -DLIBDIR=\"/opt/local/lib/X11\" -I/opt/local/include -I/opt/local/include -I/opt/local/include -pipe -Os -arch x86_64 -Wall -g -fno-strict-aliasing -Wno-unused -Wno-comment -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/libpng16 -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/libpng16 -I/opt/local/include -MT DragC.lo -MD -MP -MF .deps/DragC.Tpo -c DragC.c  -fno-common -DPIC -o .libs/DragC.o
In file included from DragC.c:51:
../Xm/VendorSP.h:48:13: error: unknown type name 'OMVendorShellClassRec'; did you mean 'VendorShellClassRec'?
externalref OMVendorShellClassRec  OMvendorShellClassRec;
            ^~~~~~~~~~~~~~~~~~~~~
            VendorShellClassRec
/opt/local/include/X11/VendorP.h:82:3: note: 'VendorShellClassRec' declared here
} VendorShellClassRec;
  ^
1 error generated.

because the typdef for these two are in coming from the X11 headers...

#ifndef  _XtVendorPrivate_h
#define _XtVendorPrivate_h

#include <X11/Vendor.h>

/* New fields for the VendorShell widget class record */

_XFUNCPROTOBEGIN

typedef struct {
    XtPointer       extension;          /* pointer to extension record      */
} VendorShellClassPart;

typedef struct _VendorShellClassRec {
        CoreClassPart      core_class;
        CompositeClassPart composite_class;
        ShellClassPart  shell_class;
        WMShellClassPart   wm_shell_class;
        VendorShellClassPart vendor_shell_class;
} VendorShellClassRec;

externalref VendorShellClassRec vendorShellClassRec;

/* New fields for the vendor shell widget. */

typedef struct {
        int             vendor_specific;
} VendorShellPart;

typedef  struct {
        CorePart        core;
        CompositePart   composite;
        ShellPart       shell;
        WMShellPart     wm;
        VendorShellPart vendor;
} VendorShellRec, *VendorShellWidget;

_XFUNCPROTOEND

#endif  /* _XtVendorPrivate_h */

If detangling this mess was easy to do, someone would have done it long ago. Note that in the lesstif link you sent me the user proposed renaming and the lesstif developer shot that idea down immediately.

[jeremyhu (Jeremy Huddleston Sequoia)]

Well then maybe we just fix libXt and create a xorg-libXt-flat-namespace subport which installs to some sub-prefix for the specific use of motif and child projects instead of other libXt clients.

[howarth.at.macports@…]

What do you plan to do about XQuartz where there is no such option of libXt variants? I am more concerned about the standalone software floating out there which will be broken by such a change.

[howarth.at.macports@…]

Also if you do move the current flat_namespace version of xorg-libXt into a variant, this should be only done in concert with insuring that port really does honor the Portfile field require_active_variants. Port will need to honor this field so that if...

require_active_variants xorg-libXt flat_namespace

is present in a Portfile it will install the proper xorg-libXt- flat_namespace variant during builds of packages that use openmotif.

[jeremyhu (Jeremy Huddleston Sequoia)]

I suggest *NOT* doing a variant becasue we then don't know what we have. I suggest using a subport (so there could be two copies on disk).

[jeremyhu (Jeremy Huddleston Sequoia)]

Also, it looks like you don't have debug symbols for your MacPorts code. For the relevant ports, I suggest that you set the optimize flags to '-O0 -g3' and build from source with -k. Also, ensure that installed libraries aren't stripped. You should then have dSYMs and source available for the MacPorts libraries

[jeremyhu (Jeremy Huddleston Sequoia)]

Wrong ticket for that last one, sorry...

[jeremyhu (Jeremy Huddleston Sequoia)]

I gave in and went with the variant approach. I don't have any better suggestions.

[EJFielding (Eric Fielding)]

After migrating to El Capitan (10.11.6) and reinstalling all my ports, I could not get my Motif programs to run, including "nedit" installed with MacPorts. It turned out that I somehow had the "xorg-libXt @1.1.5_1" port variant active. I just had to activate the "xorg-libXt @1.1.5_1+flat_namespace" variant that was already installed but inactive and now all my Motif programs run. Thought I should describe this here in case someone else has a similar problem.

[lrebull]

I'm running OS 10.11.6, and just updated to XQuartz 2.7.10 this morning. Now I get that same error with nedit: "Error: Shell widget nedit has zero width and/or height".. Sorry to be dense, and I did read everything above .. how did you "activate the "xorg-libXt @1.1.5_1+flat_namespace" variant that was already installed but inactive"??

[jeremyhu (Jeremy Huddleston Sequoia)]

sudo port -v -f deactivate xorg-libXt
sudo port -v install xorg-libXt +flat_namespace