Discussion:
[Xquartz-dev] XQuartz 2.7.10-rc2 breaks all X binaries built against XQuartz 2.7.9
Jack Howarth
2016-09-25 00:23:12 UTC
Permalink
Jeremy,
You have a major thinko in XQuartz 2.7.10-rc2. Replacing
libXt.7.dylib with a symlink to libXt.6.dylib causes all binaries
built against XQuartz 2.7.9 to break....

dyld: Library not loaded: /opt/X11/lib/libXt.7.dylib
Referenced from: /sw/bin/gs
Reason: Incompatible library version: gs requires version 8.0.0 or
later, but libXt.7.dylib provides version 7.0.0

because the libXt.7.dylib in the current 2.7.9 release has an so
version of 8.0.0. You will need to replace the symlink with a proper
build of libXt.7.dylib to provide continuity in the so version number.
Jack
Jeremy Huddleston Sequoia
2016-09-25 16:59:15 UTC
Permalink
It's not the symlink that's the problem. It's the dylib version. It would work as intended if it had a current version of 8.0.0 and a compat version of 7.0.0.

Thanks for catching this. Please file a ticket.

As mentioned before, the entire problem with the 2.7.9 solution was that we can't have two different copies of libXt in the same process because the dependents don't necessarily respect layering.

I'll drop in a stub for libXt.7.dylib which re-exports libXt.6.dylib with the appropriate versioning.
Post by Jack Howarth
Jeremy,
You have a major thinko in XQuartz 2.7.10-rc2. Replacing
libXt.7.dylib with a symlink to libXt.6.dylib causes all binaries
built against XQuartz 2.7.9 to break....
dyld: Library not loaded: /opt/X11/lib/libXt.7.dylib
Referenced from: /sw/bin/gs
Reason: Incompatible library version: gs requires version 8.0.0 or
later, but libXt.7.dylib provides version 7.0.0
because the libXt.7.dylib in the current 2.7.9 release has an so
version of 8.0.0. You will need to replace the symlink with a proper
build of libXt.7.dylib to provide continuity in the so version number.
Jack
Loading...