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
<[email protected]> wrote:
>
>> On Sep 13, 2016, at 05:50, Jack Howarth <[email protected]>
>> wrote:
>>
>> On Fri, Sep 9, 2016 at 1:06 AM, Jeremy Huddleston Sequoia
>> <[email protected]> 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
> [email protected]
> https://lists.macosforge.org/mailman/listinfo/xquartz-dev
>
_______________________________________________
Xquartz-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/xquartz-dev
