On 6/17/19 6:17 PM, Thomas Dickey wrote:
On Mon, Jun 17, 2019 at 10:14:50AM -0700, Alan Coopersmith wrote:
On 6/16/19 5:08 PM, Thomas Dickey wrote:
I've built, but don't see how to run... with Solaris 11.4
(since the existing libraries are linked to an ABI 4 libXt).
It's the same ABI, we just preserve the long-standing Solaris .so.4
versioning for binary compatibility sake, by patching src/Makefile.am
to change the libXt_la_LDFLAGS:
https://github.com/oracle/solaris-userland/blob/master/components/x11/lib/libXt/patches/01-6671721.patch#L686-L701
You can see the rest of our libXt build configuration/patches in:
https://github.com/oracle/solaris-userland/tree/master/components/x11/lib/libXt
I see...
When I looked at this a month ago, I'd thought the ABI was incompatible.
I modified my script to use the .so.4 (okay), but seeing the extra entrypoints
in the patches, didn't want to replace /usr/lib/64/libXt.so.4
Rather, my test packages go under /opt/dickey (except for the app-defaults
files, to work with the default search-paths). I used the rpath option for
linking xterm to the separate copy of libXt.so.4, which _almost_ worked
as I'd wanted -- but some of the dependent libraries load libXt.so.4, and
_those_ end up on the default linker path. Setting $LD_LIBRARY_PATH "fixed"
that (so I could test the library), but of course isn't a solution.
Right - I tend to build all the X.org upstream sources to install to a
/usr/X11R7 directory, since they're not all direct drop-in replacements
for what we ship in Solaris, and don't normally try to force them into
place over the system-provided ones - but then I can easily use our
build recipes to generate new system packages with our customizations
when needed.
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/alanc
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
