On Wed, Sep 14, 2016 at 1:53 PM, Jeremy Huddleston Sequoia <jerem...@gmail.com> wrote: > >> On Sep 14, 2016, at 09:51, Jack Howarth <howarth.mailing.li...@gmail.com> >> wrote: >> >> 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. > > Nope, that is exactly correct. Projects should NOT be linking against those > libraries. They are being shipped for runtime usage only. Parties that are > interested in using those instead of the ones we ship by default can copy > them into location or use DYLD_LIBRARY_PATH as suggested earlier. > > Any developer trying to link against those binaries should instead invest > time in fixing Motif. There's no reason anyone should be linking against > those directly.
I am pretty certain that there is no way to fix this that doesn't break the motif ABI with pre-existing binaries because the crux of the problem is a name-space collision with libXt. My understanding was that linux doesn't tickle this problem because their weak symbol handling allows the overlapping symbols from motif to dominate over those from libXt. > > As an alternative, I could just ship a separate Motif compatibility package > which lays those down in /opt/X11/lib, but I fear that doing so might cause > people to install it that don't really need it. > > >> 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 >> > > > > _______________________________________________ > 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
