OpenMotif is broken.  libXt.6.dylib was provided as a workaround to try and not break existing applications that rely on OpenMotif's broken behavior.  I suggest you try and fix OpenMotif

Thank you for your reply.

How it is OpenMotif broken? It has worked for many years on many platforms.
If you can point me in the direction of the error, I can try to recompile motif and try to fix the error. OpenMotif is still maintained and I can try to push the changes upstream.

I don't quite understand the remark regarding the libXt.6.dylib workaround. You mean it is no longer provided, and this now causes the problem to manifest itself?
Isn't libXt.6.dylib part of XQuartz?
Is it related to flat namespace problem?

By the way - address sanitation in clang is supposed to slow down the program two times. This is only enabled in the beta version of XQuartz?

There are many Motif based programs, and if XQuartz does not work with Motif, a good % of old Unix software will no longer run (DDD, Nedit, grace, xpdf, Siemens NX, XEphem, ...)

See https://echelog.com/logs/browse/macports/1452121200 and do some other google searches for vendorShellClassRec and vendorShellWidgetClass.

Also note that I fixed the issue in libXaw and libXaw3d (eg: https://lists.x.org/archives/xorg-devel/2016-January/048467.html), but OpenMotif looks like it needs a bit more massaging to fix properly.

[08:24:00] <howarth> jeremyhu_, it appears that any package which links executables against motif needs to link the flat-namespace libXt
[08:25:00] <howarth> so 'require_active_variants xorg-libXt flat_namespace' needs to be added to any port that depends on openmotif
[08:25:24] <howarth> and builds executables (rather than shared libs)
[08:25:58] <jeremyhu_> nope
[08:27:01] <jeremyhu_> You just need it it the openmotif port because it will enforce the requirement for you.
[08:27:08] <jeremyhu_> The bug is with openmotif.
[08:28:30] <howarth> have they really tightened up the require_active_variants in MacPorts?
[08:28:49] <howarth> my prior experiences with pymol was that it was rather loose in enforcement
[08:29:27] <jeremyhu_> not sure what you mean by that.  If someone tries to install openmotif and the libXt isn't +flat_namespace, the install will fail.
[08:32:11] <howarth> require_active_variants tcl "" corefoundation
[08:32:11] <howarth> require_active_variants tk "" quartz
[08:32:38] <jeremyhu_> howarth: FWIW, you should spend your effort trying to fix openmotif instead.
[08:32:41] <howarth> doesn't force the replacement of the existing tcl/tk ports that are installed when building pymol
[08:32:59] <jeremyhu_> See http://pastebin.com/vdaq1gwD as a suggested starting point.  It looks like it needs additional work though because nedit doesn't launch with it.
[08:35:45] <jeremyhu_> howarth: A quick look through looks like there are a bunch of vendorShellClassRec references that I need to get pointed at _XmVendorShellClassRec instead.

Thank you very much, I will try to make this change to my own version of Motif to see if that will help.
http://pastebin.com/vdaq1gwD
If not, I will try to include my own copy of Xt with the application.

Or we will go back to virtual machines. So sad, after all this effort, and it runs so well on Snow Leopard.

You can continue to link against the libXt.6.dylib instead of the libXt.7.dylib until OpenMotif fixes the bug.

Thanks for the tip!

Motif 2.3.8 includes the fix for Xt flat namespace modification in XQuartz, so Motif applications should run again without the need to link specific Xt library.
http://bugs.motifzone.com/show_bug.cgi?id=1655