From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18164 invoked by alias); 21 Nov 2001 23:39:43 -0000 Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sources.redhat.com Received: (qmail 18143 invoked from network); 21 Nov 2001 23:39:43 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (207.175.42.154) by sourceware.cygnus.com with SMTP; 21 Nov 2001 23:39:43 -0000 Received: from trixie.bosbc.com (cgf.cipe.redhat.com [10.0.1.172]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id fALNdfq25881 for ; Wed, 21 Nov 2001 18:39:41 -0500 Received: (from cgf@localhost) by trixie.bosbc.com (8.11.6/8.8.7) id fALNduQ23104; Wed, 21 Nov 2001 18:39:56 -0500 Date: Wed, 14 Nov 2001 15:35:00 -0000 From: Christopher Faylor To: cygwin@cygwin.com, cygwin@cygwin.com Subject: Re: cygintl.dll missing Message-ID: <20011121233956.GB22925@redhat.com> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <009f01c17214$9d03d130$3396e4c2@MONTEZUMA> <4.3.1.2.20011120204158.0217cef8@pop.ma.ultranet.com> <20011121103409.G21630@cygbert.vinschen.de> <002a01c17270$1641a8f0$0200a8c0@lifelesswks> <3BFBEDA2.5050003@ece.gatech.edu> <024e01c172d0$45fce450$0200a8c0@lifelesswks> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <024e01c172d0$45fce450$0200a8c0@lifelesswks> User-Agent: Mutt/1.3.23.1i X-SW-Source: 2001-11/txt/msg00839.txt.bz2 On Thu, Nov 22, 2001 at 08:05:38AM +1100, Robert Collins wrote: >----- Original Message ----- >From: "Charles Wilson" >> 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 :}. I'm still not clear on how this is happening, though. Is setup.exe checking to see if a package exists on disk and then not automatically selecting that package for download? Or, is it the previously theorized situation where someone specifically selects gettext but selects the wrong version? cgf -- 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/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Faylor To: cygwin@cygwin.com, cygwin@cygwin.com Subject: Re: cygintl.dll missing Date: Wed, 21 Nov 2001 15:39:00 -0000 Message-ID: <20011121233956.GB22925@redhat.com> References: <009f01c17214$9d03d130$3396e4c2@MONTEZUMA> <4.3.1.2.20011120204158.0217cef8@pop.ma.ultranet.com> <20011121103409.G21630@cygbert.vinschen.de> <002a01c17270$1641a8f0$0200a8c0@lifelesswks> <3BFBEDA2.5050003@ece.gatech.edu> <024e01c172d0$45fce450$0200a8c0@lifelesswks> X-SW-Source: 2001-11/msg01427.html Message-ID: <20011121153900.52sASAK5j-GeBu57gMfd5favmEvnTxwSeLAA7bjnr1c@z> On Thu, Nov 22, 2001 at 08:05:38AM +1100, Robert Collins wrote: >----- Original Message ----- >From: "Charles Wilson" >> 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 :}. I'm still not clear on how this is happening, though. Is setup.exe checking to see if a package exists on disk and then not automatically selecting that package for download? Or, is it the previously theorized situation where someone specifically selects gettext but selects the wrong version? cgf -- 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/