libXt release

[Alan Coopersmith]

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.coopersmith at oracle.com
	 Oracle Solaris Engineering - https://blogs.oracle.com/alanc