* Re: cygintl.dll missing
2001-11-14 14:06 ` Charles Wilson
@ 2001-11-14 14:25 ` Charles Wilson
2001-11-14 14:35 ` Robert Collins
2001-11-21 12:34 ` Charles Wilson
2 siblings, 0 replies; 20+ messages in thread
From: Charles Wilson @ 2001-11-14 14:25 UTC (permalink / raw)
To: Robert Collins; +Cc: Corinna Vinschen, cygwin
Robert Collins wrote:
>>Yeah, I'm surprised, too. Vim requires gettext in
>>
> setup.hint/setup.ini
>
>>so clicking on vim should activate gettext as well.
>>
>
> It will. What is probably happening is that folk are clicking on gettext
> until it is selected, and then clicking on vim, which means that they
> have selected the prev gettext version.
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.
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?
In classic libtool versioning, let's say 35p1-2 is version 2:3:1.
According to http://www.cl.cam.ac.uk/texinfodoc/libtool_6.html, when we
add to the interface, we should increment c and a, but set r to 0.
Therefore, 38's revision number is 3:0:2 (I'm ignoring the -36 and -37
releases).
However, under the windows versioning scheme, the DLL name is
"cygfoo-$(c - a).dll" -- that is, the version number indicates the
earlist interface supported by the DLL:
35p1-2: cygintl-$(2 - 1).dll == cygintl-1.dll
38: cygintl-$(3 - 2).dll -- cygintl-1.dll
---> no versioning change (since cygintl was originally released without
versioning info, I'm not going to uselessly add versioning information
until there is a CHANGE in that info. So, right now, 35p1-2 AND 38
still contain merely "cygintl.dll"
In most cases, these two dll's are interchangeable -- UNLESS one
actually USES the added interfaces. Like bind_text_whatever. This is a
problem that really just can't be solved on the windows platform --
unless you want to revision EVERY release of a DLL differntly ( e.g.
don't use the $(c - a) thing, but use $(c)-$(r)-$(a) instead.) But
then, given the limitations of the windows runtime loader, you'd really
be better off not doing DLL's at all and just linking everything
statically. :-P
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.
--Chuck
--
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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cygintl.dll missing
2001-11-14 14:06 ` Charles Wilson
2001-11-14 14:25 ` Charles Wilson
@ 2001-11-14 14:35 ` Robert Collins
2001-11-14 14:36 ` Robert Collins
` (2 more replies)
2001-11-21 12:34 ` Charles Wilson
2 siblings, 3 replies; 20+ messages in thread
From: Robert Collins @ 2001-11-14 14:35 UTC (permalink / raw)
To: Charles Wilson; +Cc: Corinna Vinschen, cygwin
----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.edu>
> 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/
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: cygintl.dll missing
2001-11-14 14:35 ` Robert Collins
@ 2001-11-14 14:36 ` Robert Collins
2001-11-14 15:35 ` Christopher Faylor
2001-11-21 13:05 ` Robert Collins
2 siblings, 0 replies; 20+ messages in thread
From: Robert Collins @ 2001-11-14 14:36 UTC (permalink / raw)
To: Charles Wilson; +Cc: Corinna Vinschen, cygwin
----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.edu>
> 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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cygintl.dll missing
2001-11-14 14:35 ` Robert Collins
2001-11-14 14:36 ` Robert Collins
@ 2001-11-14 15:35 ` Christopher Faylor
2001-11-14 18:15 ` Jong B. Lee
2001-11-21 15:39 ` Christopher Faylor
2001-11-21 13:05 ` Robert Collins
2 siblings, 2 replies; 20+ messages in thread
From: Christopher Faylor @ 2001-11-14 15:35 UTC (permalink / raw)
To: cygwin, cygwin
On Thu, Nov 22, 2001 at 08:05:38AM +1100, Robert Collins wrote:
>----- Original Message -----
>From: "Charles Wilson" <cwilson@ece.gatech.edu>
>> 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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cygintl.dll missing
2001-11-14 15:35 ` Christopher Faylor
@ 2001-11-14 18:15 ` Jong B. Lee
2001-11-21 16:34 ` Jong B. Lee
2001-11-21 15:39 ` Christopher Faylor
1 sibling, 1 reply; 20+ messages in thread
From: Jong B. Lee @ 2001-11-14 18:15 UTC (permalink / raw)
To: cygwin
----- Original Message -----
From: Christopher Faylor <cgf@redhat.com>
To: <cygwin@cygwin.com>; <cygwin@cygwin.com>
Sent: Thursday, November 22, 2001 8:39 AM
Subject: Re: cygintl.dll missing
> 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
>
Dear cgf,
One example is here : http://cygwin.com/ml/cygwin/2001-11/msg01322.html
This happens to those who have not cygwin installed on their machine.
BTW, I think we need full install option by one clicking.
Jong B. Lee
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cygintl.dll missing
2001-11-14 18:15 ` Jong B. Lee
@ 2001-11-21 16:34 ` Jong B. Lee
0 siblings, 0 replies; 20+ messages in thread
From: Jong B. Lee @ 2001-11-21 16:34 UTC (permalink / raw)
To: cygwin
----- Original Message -----
From: Christopher Faylor <cgf@redhat.com>
To: <cygwin@cygwin.com>; <cygwin@cygwin.com>
Sent: Thursday, November 22, 2001 8:39 AM
Subject: Re: cygintl.dll missing
> 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
>
Dear cgf,
One example is here : http://cygwin.com/ml/cygwin/2001-11/msg01322.html
This happens to those who have not cygwin installed on their machine.
BTW, I think we need full install option by one clicking.
Jong B. Lee
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cygintl.dll missing
2001-11-14 15:35 ` Christopher Faylor
2001-11-14 18:15 ` Jong B. Lee
@ 2001-11-21 15:39 ` Christopher Faylor
1 sibling, 0 replies; 20+ messages in thread
From: Christopher Faylor @ 2001-11-21 15:39 UTC (permalink / raw)
To: cygwin, cygwin
On Thu, Nov 22, 2001 at 08:05:38AM +1100, Robert Collins wrote:
>----- Original Message -----
>From: "Charles Wilson" <cwilson@ece.gatech.edu>
>> 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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cygintl.dll missing
2001-11-14 14:35 ` Robert Collins
2001-11-14 14:36 ` Robert Collins
2001-11-14 15:35 ` Christopher Faylor
@ 2001-11-21 13:05 ` Robert Collins
2 siblings, 0 replies; 20+ messages in thread
From: Robert Collins @ 2001-11-21 13:05 UTC (permalink / raw)
To: Charles Wilson; +Cc: Corinna Vinschen, cygwin
----- Original Message -----
From: "Charles Wilson" <cwilson@ece.gatech.edu>
> 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/
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: cygintl.dll missing
2001-11-14 14:06 ` Charles Wilson
2001-11-14 14:25 ` Charles Wilson
2001-11-14 14:35 ` Robert Collins
@ 2001-11-21 12:34 ` Charles Wilson
2 siblings, 0 replies; 20+ messages in thread
From: Charles Wilson @ 2001-11-21 12:34 UTC (permalink / raw)
To: Robert Collins; +Cc: Corinna Vinschen, cygwin
Robert Collins wrote:
>>Yeah, I'm surprised, too. Vim requires gettext in
>>
> setup.hint/setup.ini
>
>>so clicking on vim should activate gettext as well.
>>
>
> It will. What is probably happening is that folk are clicking on gettext
> until it is selected, and then clicking on vim, which means that they
> have selected the prev gettext version.
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.
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?
In classic libtool versioning, let's say 35p1-2 is version 2:3:1.
According to http://www.cl.cam.ac.uk/texinfodoc/libtool_6.html , when we
add to the interface, we should increment c and a, but set r to 0.
Therefore, 38's revision number is 3:0:2 (I'm ignoring the -36 and -37
releases).
However, under the windows versioning scheme, the DLL name is
"cygfoo-$(c - a).dll" -- that is, the version number indicates the
earlist interface supported by the DLL:
35p1-2: cygintl-$(2 - 1).dll == cygintl-1.dll
38: cygintl-$(3 - 2).dll -- cygintl-1.dll
---> no versioning change (since cygintl was originally released without
versioning info, I'm not going to uselessly add versioning information
until there is a CHANGE in that info. So, right now, 35p1-2 AND 38
still contain merely "cygintl.dll"
In most cases, these two dll's are interchangeable -- UNLESS one
actually USES the added interfaces. Like bind_text_whatever. This is a
problem that really just can't be solved on the windows platform --
unless you want to revision EVERY release of a DLL differntly ( e.g.
don't use the $(c - a) thing, but use $(c)-$(r)-$(a) instead.) But
then, given the limitations of the windows runtime loader, you'd really
be better off not doing DLL's at all and just linking everything
statically. :-P
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.
--Chuck
--
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/
^ permalink raw reply [flat|nested] 20+ messages in thread