On Wed, Sep 14, 2016 at 3:23 PM, Jack Howarth <howarth.mailing.li...@gmail.com> wrote: > 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. >
One thing that might be worth trying (which I haven't puzzled out yet) is changing the symbols... # nm libXm.4.dylib | grep vendorShell 00000000002023f0 D _vendorShellClassRec 0000000000202510 D _vendorShellWidgetClass from 'D' to 'd' with the appropriate invocation of __attribute__((weak_import)). So far I haven't found the proper place to insert that to get the symbol converted into a weak_import. >> >> 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
