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

[Harold L Hunt II]

Nicholas,

I really don't know what to do here.  Perhaps some others know what to 
do and whether or not this is a good idea.

Would it be easier to update to 4.3.0?  Have we already made Xt a shared 
lib in 4.3.0?

On a side note, has anyone been seeing signs of when 4.4.0 is going to 
be released?  I noticed that they just tagged 4.3.99.9, so maybe it 
would be better to wait an release 4.4.0 when it is ready instead.

Any thoughts?

Harold

Nicholas Wourms wrote:
> 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
>