[Xquartz-dev] XQuartz 2.7.10_rc1

Jeremy Huddleston Sequoia jeremyhu at gmail.com
Tue Sep 13 13:12:14 PDT 2016


> On Sep 13, 2016, at 05:50, Jack Howarth <howarth.mailing.lists at gmail.com> wrote:
> 
> On Fri, Sep 9, 2016 at 1:06 AM, Jeremy Huddleston Sequoia
> <jeremyhu at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4465 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/xquartz-dev/attachments/20160913/0410683d/attachment.p7s>


More information about the Xquartz-dev mailing list