This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: [XFree86-4.2.0] Now that we have an improved ld, please makelibXt a shared library.
- From: Harold L Hunt II <huntharo at msu dot edu>
- To: cygwin-xfree at cygwin dot com
- Date: Mon, 28 Jul 2003 01:11:49 -0400
- Subject: Re: [XFree86-4.2.0] Now that we have an improved ld, please makelibXt a shared library.
- References: <bg1kkb$din$1@main.gmane.org>
- Reply-to: cygwin-xfree at cygwin dot com
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