> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
