This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [XFree86-4.2.0] Now that we have an improved ld, please makelibXt a shared library.


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]