cygintl.dll missing

cygintl.dll missing

[Martin Vit]

Hello,

I was installed cygwin and I want run vi.
System show me error message that
cygintl.dll could not be found.

Where I can download this DLL library?


Thanks


Regards 
Martin Vit


--
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/

Re: cygintl.dll missing

[Charles Wilson]

Look here:

http://www.cygwin.com/packages/

--Chuck
(thanks chris!)

Martin Vit wrote:
> 
> Hello,
> 
> I was installed cygwin and I want run vi.
> System show me error message that
> cygintl.dll could not be found.
> 
> Where I can download this DLL library?
> 
> Thanks
> 
> Regards
> Martin Vit
> 
> --
> 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/

--
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/

Re: cygintl.dll missing

[Larry Hall (RFK Partners, Inc)]

At 05:41 PM 11/20/2001, Martin Vit wrote:
>Hello,
>
>I was installed cygwin and I want run vi.
>System show me error message that
>cygintl.dll could not be found.
>
>Where I can download this DLL library?


I'm under the impression that this situation shouldn't occur anymore 
with the new setup (someone please correct me if I'm wrong).  It does
seem with the number of messages we've seen lately w.r.t. vi that there 
is some issue here but I'm uncertain as to what it is.  Does anybody have 
an idea?

Martin, can you tell us all *exactly* the steps you took to install 
Cygwin, from start to finish and every step in between before running
vi?



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
838 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
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/

Re: cygintl.dll missing

[Corinna Vinschen]

On Tue, Nov 20, 2001 at 08:45:25PM -0500, Larry Hall (RFK Partners, Inc) wrote:
> At 05:41 PM 11/20/2001, Martin Vit wrote:
> >Hello,
> >
> >I was installed cygwin and I want run vi.
> >System show me error message that
> >cygintl.dll could not be found.
> >
> >Where I can download this DLL library?
> 
> 
> I'm under the impression that this situation shouldn't occur anymore 
> with the new setup (someone please correct me if I'm wrong).  It does

Yeah, I'm surprised, too.  Vim requires gettext in setup.hint/setup.ini
so clicking on vim should activate gettext as well.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
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/

Re: cygintl.dll missing

[Robert Collins]

----- Original Message -----
From: "Corinna Vinschen" <cygwin@cygwin.com>
To: <cygwin@sources.redhat.com>
Sent: Wednesday, November 21, 2001 8:34 PM
Subject: Re: cygintl.dll missing


> On Tue, Nov 20, 2001 at 08:45:25PM -0500, Larry Hall (RFK Partners,
Inc) wrote:
> > At 05:41 PM 11/20/2001, Martin Vit wrote:
> > >Hello,
> > >
> > >I was installed cygwin and I want run vi.
> > >System show me error message that
> > >cygintl.dll could not be found.
> > >
> > >Where I can download this DLL library?
> >
> >
> > I'm under the impression that this situation shouldn't occur anymore
> > with the new setup (someone please correct me if I'm wrong).  It
does
>
> 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.

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/

Re: cygintl.dll missing

[Robert Collins]

----- Original Message -----
From: "Corinna Vinschen" <cygwin@cygwin.com>
To: <cygwin@sources.redhat.com>
Sent: Wednesday, November 21, 2001 8:34 PM
Subject: Re: cygintl.dll missing


> On Tue, Nov 20, 2001 at 08:45:25PM -0500, Larry Hall (RFK Partners,
Inc) wrote:
> > At 05:41 PM 11/20/2001, Martin Vit wrote:
> > >Hello,
> > >
> > >I was installed cygwin and I want run vi.
> > >System show me error message that
> > >cygintl.dll could not be found.
> > >
> > >Where I can download this DLL library?
> >
> >
> > I'm under the impression that this situation shouldn't occur anymore
> > with the new setup (someone please correct me if I'm wrong).  It
does
>
> 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.

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/

Re: cygintl.dll missing

[Corinna Vinschen]

On Wed, Nov 21, 2001 at 08:37:06PM +1100, Robert Collins wrote:
> ----- Original Message -----
> From: "Corinna Vinschen" <cygwin@cygwin.com>
> To: <cygwin@sources.redhat.com>
> Sent: Wednesday, November 21, 2001 8:34 PM
> Subject: Re: cygintl.dll missing
> 
> 
> > On Tue, Nov 20, 2001 at 08:45:25PM -0500, Larry Hall (RFK Partners,
> Inc) wrote:
> > > At 05:41 PM 11/20/2001, Martin Vit wrote:
> > > >Hello,
> > > >
> > > >I was installed cygwin and I want run vi.
> > > >System show me error message that
> > > >cygintl.dll could not be found.
> > > >
> > > >Where I can download this DLL library?
> > >
> > >
> > > I'm under the impression that this situation shouldn't occur anymore
> > > with the new setup (someone please correct me if I'm wrong).  It
> does
> >
> > 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.

Oh, yes.  What about turning the order in setup to skip->curr->prev->test?

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
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/

Re: cygintl.dll missing

[Robert Collins]

----- Original Message -----
From: "Corinna Vinschen" <cygwin@cygwin.com>
> > 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.
>
> Oh, yes.  What about turning the order in setup to
skip->curr->prev->test?

See cygwin-apps (IIRC) 'bout 2 days ago where I discussed this and said
that that is too simple - it needs to be dependent on the curr/prev/exp
buttons as well.

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/

Re: cygintl.dll missing

[Charles Wilson]

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/

Re: cygintl.dll missing

[Charles Wilson]

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/

Re: cygintl.dll missing

[Robert Collins]

----- 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/

Re: cygintl.dll missing

[Robert Collins]

----- 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/

Re: cygintl.dll missing

[Christopher Faylor]

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/

Re: cygintl.dll missing

[Jong B. Lee]

----- 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

Re: cygintl.dll missing

[Corinna Vinschen]

On Wed, Nov 21, 2001 at 08:37:06PM +1100, Robert Collins wrote:
> ----- Original Message -----
> From: "Corinna Vinschen" <cygwin@cygwin.com>
> To: <cygwin@sources.redhat.com>
> Sent: Wednesday, November 21, 2001 8:34 PM
> Subject: Re: cygintl.dll missing
> 
> 
> > On Tue, Nov 20, 2001 at 08:45:25PM -0500, Larry Hall (RFK Partners,
> Inc) wrote:
> > > At 05:41 PM 11/20/2001, Martin Vit wrote:
> > > >Hello,
> > > >
> > > >I was installed cygwin and I want run vi.
> > > >System show me error message that
> > > >cygintl.dll could not be found.
> > > >
> > > >Where I can download this DLL library?
> > >
> > >
> > > I'm under the impression that this situation shouldn't occur anymore
> > > with the new setup (someone please correct me if I'm wrong).  It
> does
> >
> > 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.

Oh, yes.  What about turning the order in setup to skip->curr->prev->test?

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
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/

Re: cygintl.dll missing

[Robert Collins]

----- Original Message -----
From: "Corinna Vinschen" <cygwin@cygwin.com>
> > 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.
>
> Oh, yes.  What about turning the order in setup to
skip->curr->prev->test?

See cygwin-apps (IIRC) 'bout 2 days ago where I discussed this and said
that that is too simple - it needs to be dependent on the curr/prev/exp
buttons as well.

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/

Re: cygintl.dll missing

[Charles Wilson]

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/

Re: cygintl.dll missing

[Robert Collins]

----- 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/

Re: cygintl.dll missing

[Christopher Faylor]

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/

Re: cygintl.dll missing

[Jong B. Lee]

----- 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