[XFree86-4.2.0] Now that we have an improved ld, please make libXt a shared library.

[Nicholas Wourms]

Hi Harold,

It's been awhile...  Anyhow, I've been working on a few packages which 
use libtool, and thus the reason behind my request.  It turns out, using 
the new libtool, that one has to go to extreme lengths just to get libXt 
to link in, since the new libtool balks at linking true static archives 
into shared libraries on Cygwin.  As you know, X11's libs are very fussy 
over link order, thus there exists no simple way of getting the job done 
(i.e Automake refuses to allow -Wl flags in _la_LIBADD).  I've managed 
to resolve my issue locally by passing "-Wl,-L/usr/X11R6/lib -Wl,-lXt 
-Wl,-lSM -Wl,-lICE -Wl,-lX11 -Wl,--exclude-libs,libXt.a" to my projects' 
_la_LDFLAGS, but this is obviously a kludge.  There are many reasons why 
this is suboptimal, but the number one reason is that there is no way to 
transmit this information to projects linking against the library.  Any 
linkee will need to know that -lXt should linked in (I'll admit most 
projects are on the ball and already have -lXt in their build, but not 
all).  Another reason being that it reduces code bloat, which may or may 
not lead to better performance.  However, the primary reason for not 
building libXt shared is moot and has been for several months now. 
Compiling with the latest stable binutils & cygwin dll will allow an 
effortless building of libXt.dll.  If you doubt me, then `cd 
/usr/X11R6/lib` and do this:

gcc -shared -o ../libXt.dll -Wl,--image-base=0x10000000 
-Wl,--out-implib,libXt.dll.a -Wl,--export-all-symbols 
-Wl,--enable-auto-import -Wl,--whole-archive libXt.a -Wl, 
--no-whole-archive libSM.a libICE.a libX11.a

It works like a charm.  As we speak, I'm compiling a shared lesstif 
using libtool-1.5 and a shared libXt.  After minor adjustments of the 
Makefiles to account for cygwin's no undefined in shlibs issue, it seems 
to be working fine.

I really can't see any downside to doing this, since going from 
static-only -> shared breaks nothing (even if it does, then it does so 
because of badness of the broken package's build).  This may seem on the 
outside like a 4.3.0 type of change, but it really doesn't seem all that 
harmful.

So, hopefully you might consider this in one of your updated test 
series?  Thanks in advance for your consideration.

Cheers,
Nicholas