This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin 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: RFD: gettext, iconv, packaging...


Charles Wilson wrote:

Corinna Vinschen wrote:


If only these two tools are using cyggettext*.dll and the other one,
why not linking statically against them?  I don't see a reason to
have dlls hanging around for that purpose.


No, you got it backwards. There are only two programs -- the two MAIN programs "gettext.exe" and "ngettext.exe" -- that DON'T use the cyggettext*.dll code. There are 6 or so "development" oriented programs that DO use the code. Why include duplicate code in all those programs if it can all be stored in a shared library?

Answer: because it doesn't work. :-(

I have been able to build a new gettext suite based on 0.11.2 and it passes the expected tests (and fails others for good and known reasons). However, make install fails miserably -- because libtool (even 20020502) has problems:

relinking. (2)

(1) *EVERY* time you do another 'make' invocation, libtool relinks the .exe's. This is because 'make' is looking for foo.exe in <working dir>, but foo.exe is in <working dir>/.libs/. The only thing in <working dir> is the libtool wrapper script, foo. So, we relink. again and again and again... :-(

(2) When doing a 'make install', libtool insists on relinking the libraries. But, it doesn't understand DESTDIR -- so even though I *HAD* a perfectly good 'cyggettextlib-0.11.2.dll' which depended on the new cygintl-2.dll -- the NEW relinked one gets linked against -L/usr/lib and picks up cygintl-1.dll. (libtool thinks that libintl.la has already been installed into /usr/lib, and assumes that -L/usr/lib is the right thing to do. But libintl.la was installed into $(DESTDIR)/usr/lib.)

IMO, this is a cross-platform libtool bug: libtool doesn't understand $(DESTDIR), and relinks against the wrong library. (This of course begs the question: why is libtool relinking the DLLs? There's no need to do that on windows; we have no -rpath.)

Rather than delay a release of gettext-0.11.2 and libiconv for Yet Another Round of Libtool Fixing, I'm going to go with Corinna's suggestion: just make libgettextlib and libgettextsrc static libs (libtool convenience libraries). Nobody but gettext's own tools are allowed to use them anyway, so they might as well be.

The damage: the utility programs are, taken all together, a few hundred kb bigger than they would otherwise be. Big **** deal.

--Chuck



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