Jeremy, There is a major thinko in how you built XQuartz 2.7.10-rc2. The files...
$ otool -L /opt/X11/lib/flat_namespace/libXt.6.dylib /opt/X11/lib/flat_namespace/libXt.6.dylib: /opt/X11/lib/libXt.6.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/X11/lib/libSM.6.dylib (compatibility version 7.0.0, current version 7.1.0) /opt/X11/lib/libICE.6.dylib (compatibility version 10.0.0, current version 10.0.0) /opt/X11/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0) /opt/X11/lib/libxcb.1.dylib (compatibility version 3.0.0, current version 3.0.0) /opt/X11/lib/libXau.6.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/X11/lib/libXdmcp.6.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1) and $ otool -L /opt/X11/lib/flat_namespace/libXt.7.dylib /opt/X11/lib/flat_namespace/libXt.7.dylib: /opt/X11/lib/libXt.6.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/X11/lib/libSM.6.dylib (compatibility version 7.0.0, current version 7.1.0) /opt/X11/lib/libICE.6.dylib (compatibility version 10.0.0, current version 10.0.0) /opt/X11/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0) /opt/X11/lib/libxcb.1.dylib (compatibility version 3.0.0, current version 3.0.0) /opt/X11/lib/libXau.6.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/X11/lib/libXdmcp.6.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1) have the wrong install name path. So any binaries linked against those two flat-namespace shared libraries are going to load the two-level namespace ones instead. Jack On Tue, Sep 13, 2016 at 4:12 PM, Jeremy Huddleston Sequoia <jerem...@gmail.com> wrote: > >> On Sep 13, 2016, at 05:50, Jack Howarth <howarth.mailing.li...@gmail.com> >> wrote: >> >> On Fri, Sep 9, 2016 at 1:06 AM, Jeremy Huddleston Sequoia >> <jerem...@apple.com> wrote: >>> Hey all, >>> >>> I'd like to announce that XQuartz 2.7.10_rc1 is available. Full changes >>> since 2.7.9 can be seen in the release notes: >>> >>> https://www.xquartz.org/releases/XQuartz-2.7.10_rc1.html >>> >>> The main change since 2.7.10_beta2 is around the libXt compatibility hack >>> for Motif. Because of issues with applications that use both Motif and >>> libXaw, I've abandoned the previous approach of shipping >>> /opt/X11/lib/libXt.6.dylib as flat_namespace and /opt/X11/lib/libXt.7.dylib >>> as the two-level namespace version. Now, /opt/X11/lib/libXt.6.dylib is >>> two-level namespace, and /opt/X11/lib/libXt.7.dylib is provided as a >>> symlink to it for compatibility. This means that Motif based applications >>> will fail to launch by default unless this bug is fixed in Motif. >>> >>> As a workaround, we're shipping the flat namespace dylib hack at >>> /opt/X11/lib/flat_namespace/libXt.6.dylib. Users who require that version >>> have two options: >>> 1) Replace the two-level namespace version with it (sudo cp >>> /opt/X11/lib/flat_namespace/libXt.6.dylib /opt/X11/lib/libXt.6.dylib) >>> 2) Launch your Motif applications using >>> DYLD_LIBRARY_PATH=/opt/X11/lib/flat_namespace >> >> That really isn't a viable solution since using DYLD_LIBRARY_PATH will >> require users to disable rootless on 10.11 and later. > > No, that's certainly not the case. DYLD_LIBRARY_PATH is ignored for system > executables. There are no system executables that require Motif, so that's > not relevant. > >>> This should not be seen as a long-term solution. Hopefully someone will >>> step up to fix Motif to not require this hack. >> >> That is impossible to achieve. The underlying problem is a namespace >> conflict for at least one symbol in motif. Any proper fix for this >> would require motif to rename those symbols and break all legacy motif >> binaries. > > Nope. You can see the change that I made to libXaw and libXaw3d for this > purpose. It does not break binary compatibility for those libraries. > >>> Please give this a try and comment on the effectiveness of this approach if >>> you use Motif-based applications. >> >> Is the breakage in 2.7.9 *really* that bad? > > Yes. The issue is that the structs are actually sized differently and Motif > and libXaw were overrunning the allocated memory, causing memory corruption. > This fixes the problem correctly for clients of libXaw and libXaw3d. Motif > just needs a similar change. > >> It seems better to revert >> this change in 2.7.10 and leave things as they are in 2.7.9 relative >> to the motif support. At least legacy binaries still work there and if >> users rebuild rigorously against the two-level namespace >> libXt.7.dylib, there shouldn't be issues with newly built binaries. > > The solution in 2.7.9 was not working for legacy executables that were > including both libXt.6.dylib (through libXm.dylib) and libXt.7.dylib (through > libXaw.dylib or libXaw3d.dylib). An alternative would be to bump both libXt > and everything else that linked against it. That falls apart quite quickly. > > --- > > The solution as it is basically allows users to choose memory corruption and > OpenMotif compatibility (by using the ones in the flat_namespace > subdirectory) or security and reliability (by using what we ship by default). > > --Jeremy > > > > _______________________________________________ > Xquartz-dev mailing list > Xquartz-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/xquartz-dev > _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev