On Jan 6, 2016, at 20:56, Jack Howarth <howarth.mailing.lists@gmail.com> wrote:
Jeremy, Also, I assume that the so version bump was not done cosmetically to allow libXt to be rebuilt without -flat_namespace but involves real ABI changes to that library.
The only difference is that /opt/X11/lib/libXt.7.dylib is a proper 2-level namespace.
If that is the case, won't there be issues when executables and their associated libraries are built against the different so versions of libXt?
Yes, if they expect libXt to be linked with -flat_namespace, and they link against /opt/X11/lib/libXt.7.dylib, they will have problems. Those are bugs (in that 3rd party code) which are long overdue to be fixed.
More importantly, has any other distribution tried to use this newer libXt?
MacPorts has defaulted to not using -flat_namespace since October.
I see fedora rawhide is still on so version 6 as is debian sid. This seems like it might be a rather experimental change which hasn't been well field tested.
This issue has nothing to do with Linux. The -flat_namespace hack was specific to darwin.
Jack
On Wed, Jan 6, 2016 at 11:49 PM, Jack Howarth <howarth.mailing.lists@gmail.com> wrote:
Jeremy, Are you sure that it is safe to mix the newer libXt.7.dylib with binaries built against the older libXt.6.dylib? Initially I was able to run the previous copies of xmgrace and molmol built against the Xquartz 2.7.8's X11 libs and headers, however after logging out and back into my account, these binaries now fail with...
Error: Couldn't find per display information
When was the last time a major X11 lib got an so version bump like this in Xquartz? Jack
On Wed, Jan 6, 2016 at 10:33 PM, Jeremy Huddleston Sequoia <jeremyhu@apple.com> wrote:
Darn, sorry. I intended this build to be for 10.6.3+, but I accidentally left it built for 10.8. I'll update the sparkle feed to make sure it doesn't get offered to SL and Lion users. I'll get out an rc2 in the next couple days to address that.
On Jan 6, 2016, at 14:58, Peter Dyballa <Peter_Dyballa@web.de> wrote:
Am 06.01.2016 um 21:00 schrieb Jeremy Huddleston Sequoia:
XQuartz 2.7.9_rc1 is available for download. This update contains a workaround for an issue that users have been reporting on El Capitan. If you're on El Capitan and have been seeing OpenGL surfaces remain onscreen after they should have been dismissed, please give this update a try and report back.
On Snow Leopard, Mac OS X 10.6.8, it crashes at once with:
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0xfffffffffffffff8 Crashed Thread: Unknown
Backtrace not available
Unknown thread crashed with X86 Thread State (64-bit): rax: 0x0000000000000055 rbx: 0x0000000000000000 rcx: 0x0000000000000000 rdx: 0x0000000000000000 rdi: 0x0000000000000000 rsi: 0x0000000000000000 rbp: 0x0000000000000000 rsp: 0x0000000000000000 r8: 0x0000000000000000 r9: 0x0000000000000000 r10: 0x0000000000000000 r11: 0x0000000000000000 r12: 0x0000000000000000 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000 rip: 0x00007fff5fc01028 rfl: 0x0000000000010203 cr2: 0xfffffffffffffff8
Binary images description not available
-- Greetings
Pete
One-Shot Case Study, n.: The scientific equivalent of the four-leaf clover, from which it is concluded all clovers possess four leaves and are sometimes green.
_______________________________________________ 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