Mail Archives: cygwin-apps/2001/12/14/12:24:26
Robert Collins wrote:
> ----- Original Message -----
> From: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
>
>>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.
- Raw text -