----- Original Message ----- From: "Charles Wilson" <[EMAIL PROTECTED]> > > 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.
Right. But the one package could provide the same .dll twice (until all dependent packages are rebuilt). > > 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.... Go right ahead :]. Tweak a setup.ini locally, and install from there. Recursion works. > > 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"...) Lol! Rob
