----- Original Message ----- From: "Charles Wilson" <[EMAIL PROTECTED]> > Well, the *real* problem here is that gettext-0.10.38-2's cygintl.dll > exports some symbols that gettext-0.10.35p1-2's cygintl.dll does not. > Therefore, 38's dll is backward compatibile with apps that use 35p1-2's > DLL, but 35p1-2 is not *forward* compatible.
It exports the new symbols, but what I wnat to know - why does vim use them? Are they used in the same #defines that previously used older symbols? > I don't know how to solve this problem. The libtool versioning scheme > -- as mapped to the windows dll structure -- implies that the version > number should NOT change when symbols are ADDED to the interface, right? ... Yes, and I still think that reasononing is correct. It means that having the newest .dll on the system will work for all apps linked to that dll name. Even linux doesn't guarantee forward compatability. (i.e. having an older library than a program needs won't work. Having a newer one will work for old binaries). ... > So, to repeat: this illustrates a problem with gettext (more globally, > with dll versioning on windows) but I don't know how to solve it. > Except "update your gettext package". Sigh. Yup. It's a wonderful world :]. Seriously though, I don't percieve this as an issue. What I see as an issue is setup.exe not allowing package-version constraints on dependencies. And thats *my* problem :}. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
