Robert Collins wrote: > ----- Original Message ----- > From: "Charles Wilson" <[EMAIL PROTECTED]> > >>However, this means that the new gettext dll is not backward >> > compatible > >>with packages linked against the old dll So, I've split it up into >> > two > >>packages, and provided a "compatibility' package: >> > > Ouch. Do you know why it's not compatible? (i.e. is auto-import breaking > something?)
Well, whaddaya know. I replaced my cygintl.dll with cygintl-1.dll and wget/uuencode/etc still worked. I just assumed because I changed the header files (back to the original) and was no longer declaring things "__declspec()" that that consitituted an API change. However, by (partially) switching over to libtool-based dll-building, libtool imposes its own versioning: the new DLL's *name* is different, and will continue to be different (especially once we get the new devel libtool working, and I switch gettext fully over to libtool-based dll-building). So, even if there is NO incompatibility, the name change itself is necessary and significant. >>other than perhaps to add a (not real) dependence on libintl0 in >>gettext's setup.hint to force an install... >> > > Why? If gettext needs libintl1, and sharutils et al need libintl0, then > anyone who updates will get libintl0 automatically if they have > sharutils et al installed. Hmm...I want to test this first.... > gettext should only depend on libintl1 IMO. No lying, then? > IMO we can take steps to reduce the occurence of this: IIRC every time > it has happened it's been a .dll splitout from the original package > issue. Yep -- it's always tied to package renaming, and that (hopefully) only occurs on splitting. Or stupidity. (I'm still not sure why I named some of my graphics lib packages "libfoo" and others merely "foo"...libtiff vs. jpeg? And let's not even talk about "jbigkit"...) --Chuck P.S. McNultyism: I'm out of email contact for the next several days. Back on Monday.
