Doubtful about unison

Doubtful about unison

[Olivier Lefevre]

I just installed unison 2.32 and I am a bit doubtful because
'unison', 'unison -version' and 'unison -help' don't print
anything at all (they do on my Linux box). Is it expected?

-- O.L.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[René Berber]

On 2/27/2011 10:47 PM, Olivier Lefevre wrote:

> I just installed unison 2.32 and I am a bit doubtful because
> 'unison', 'unison -version' and 'unison -help' don't print
> anything at all (they do on my Linux box). Is it expected?

No.

Use cygcheck `which unison` to see what's missing.
-- 
René Berber



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Olivier Lefevre]

On 2/28/2011 7:06 AM, René Berber wrote:
> Use cygcheck `which unison` to see what's missing.

Thanks, I didn't know that command. cygcheck says:
"C:\cygwin/bin\unison - Cannot open" Still in the
dark...

-- O.L.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Andrew Schulman]

> I just installed unison 2.32 and I am a bit doubtful because
> 'unison', 'unison -version' and 'unison -help' don't print
> anything at all (they do on my Linux box). Is it expected?

No, on my host I get

$ unison -version
unison version 2.32.52


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Andrew Schulman]

> On 2/28/2011 7:06 AM, René Berber wrote:
> > Use cygcheck `which unison` to see what's missing.
> 
> Thanks, I didn't know that command. cygcheck says:
> "C:\cygwin/bin\unison - Cannot open" Still in the
> dark...

Try `cygcheck /usr/bin/unison-2.32`.  /usr/bin/unison should be just a
symlink to /etc/alternatives/unison, which in turn is a symlink to one of
your installed versions of unison.  E.g. on my host,

$ ls -l /usr/bin/unison
lrwxrwxrwx 1 ASchulma Domain Users 24 Oct  6 09:26 /usr/bin/unison ->
/etc/alternatives/unison

$ ls -l /etc/alternatives/unison
lrwxrwxrwx 1 ASchulma Domain Users 20 Oct 12 09:42 /etc/alternatives/unison
-> /usr/bin/unison-2.32



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Olivier Lefevre]

> Try `cygcheck /usr/bin/unison-2.32`.

Now I get:
C:\cygwin/bin\unison-2.32.exe
   C:\cygwin/bin\cygwin1.dll
     C:\WINDOWS\system32\ADVAPI32.DLL
       C:\WINDOWS\system32\KERNEL32.dll
         C:\WINDOWS\system32\ntdll.dll
       C:\WINDOWS\system32\RPCRT4.dll
         C:\WINDOWS\system32\Secur32.dll
   C:\cygwin/bin\cyggcc_s-1.dll
All of these files exist.

> /usr/bin/unison should be just a symlink to /etc/alternatives/unison,
 > which in turn is a symlink to one of your installed versions of unison.

Yes indeed. And for extra fun there's also /bin/unison.
Symlinks are much abused in Unix: everything lives in 3,
4, 5 different places.

-- O.L.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Andrew Schulman]

> > Try `cygcheck /usr/bin/unison-2.32`.
> 
> Now I get:
> C:\cygwin/bin\unison-2.32.exe
>    C:\cygwin/bin\cygwin1.dll
>      C:\WINDOWS\system32\ADVAPI32.DLL
>        C:\WINDOWS\system32\KERNEL32.dll
>          C:\WINDOWS\system32\ntdll.dll
>        C:\WINDOWS\system32\RPCRT4.dll
>          C:\WINDOWS\system32\Secur32.dll
>    C:\cygwin/bin\cyggcc_s-1.dll
> All of these files exist.

Hm.  Okay, what if you run `strace /usr/bin/unison-2.32 -version`?  When I
do that, around line 375 of the output I see

 6657   90249 [main] unison-2.32 5424 fhandler_base::write: binary write
unison version 2.32.52

I'm not very knowledgeable about strace output, but if you attach yours
here I can look for problems and compare it to mine.

Also, from setup.exe, what version of unison2.32 are you using?  Is it
2.32.52-3?  There were earlier some versions of Unison that were briefly
released that were broken in a way that I think looked like this.

> > /usr/bin/unison should be just a symlink to /etc/alternatives/unison,
>  > which in turn is a symlink to one of your installed versions of unison.
> 
> Yes indeed. And for extra fun there's also /bin/unison.

Well that's different, it's a bonus Cygwin mount point :)

> Symlinks are much abused in Unix: everything lives in 3,
> 4, 5 different places.

Arguably, yes.  In this case the symlinks are there to help you manage
multiple conflicting versions of Unison - see
/usr/share/doc/unison/README.Cygwin.

Andrew.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

On 02/28/2011 10:35 AM, Andrew Schulman wrote:
> Hm.  Okay, what if you run `strace /usr/bin/unison-2.32 -version`?  When I
> do that, around line 375 of the output I see
> 
>  6657   90249 [main] unison-2.32 5424 fhandler_base::write: binary write
> unison version 2.32.52
> 
> I'm not very knowledgeable about strace output, but if you attach yours
> here I can look for problems and compare it to mine.

Please be careful when posting strace clips to the list - the overall
strace can be quite huge, so posting it untrimmed manages to spam most
list readers.  Conversely, unless you know exactly what you're looking
for when trimming it, you are likely to trim too much to make it useful
to the developer.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: Doubtful about unison

[Olivier Lefevre]

> Hm.  Okay, what if you run `strace /usr/bin/unison-2.32 -version`?

I had forgotten about that. I used truss a lot in the past but I
didn't know Cygwin had an equivalent.

 > Please be careful when posting strace clips to the list - the overall
 > strace can be quite huge

Yes but no danger here: it dies right away with an error popup that
says "The program entry point [I am translating from the german; I
might be a little off] "__ctype_ptr__" was not found in cygwin1.dll"

Looks like it was wrongly linked or compiled. Or maybe there's a
mismatch between what it was complied against and my own Cygwin? I
only just installed Unison but I haven't updated anything else, least
of all Cygwin base (which has gone wrong for me in the past), in many
months.

> Also, from setup.exe, what version of unison2.32 are you using?
> Is it 2.32.52-3?

Yes.

-- O.L.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Andy Koppe]

On 28 February 2011 19:52, Matthias Andree wrote:
> Am 28.02.2011 20:31, schrieb Olivier Lefevre:
>
>> Yes but no danger here: it dies right away with an error popup that
>> says "The program entry point [I am translating from the german; I
>> might be a little off] "__ctype_ptr__" was not found in cygwin1.dll"
>>
>> Looks like it was wrongly linked or compiled. Or maybe there's a
>> mismatch between what it was complied against and my own Cygwin? I
>
> No, instead, it was wrongly installed by yourself.
>
>> only just installed Unison but I haven't updated anything else, least
>> of all Cygwin base (which has gone wrong for me in the past), in many
>> months.
>
> Which is the problem: the unison command was compiled against a newer
> cygwin1.dll than yours.

To be fair, setup.exe ought to be able to resolve or warn about such
version dependencies. Unfortunately the infrastructure for that isn't
in place, as it would require version requirements to be expressed in
packages' setup.hint files (rather than in their READMEs, as they are
at the moment).

Andy

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

setup.exe considerations (was: Doubtful about unison)

[Matthias Andree]

Am 01.03.2011 08:20, schrieb Andy Koppe:
> On 28 February 2011 19:52, Matthias Andree wrote:

>> Which is the problem: the unison command was compiled against a newer
>> cygwin1.dll than yours.
> 
> To be fair, setup.exe ought to be able to resolve or warn about such
> version dependencies. Unfortunately the infrastructure for that isn't
> in place, as it would require version requirements to be expressed in
> packages' setup.hint files (rather than in their READMEs, as they are
> at the moment).

No it doesn't require such version dependencies.

As a lightweight alternative, setup.exe might just recursively select
all "requires" packages that a newly installed or upgraded package
depends on "for update" (possibly from the same version branch,
curr/test/prev), making sure not to implicitly downgrade.

In this particular example, it would mark "alternatives" and "cygwin"
for update as direct unison2.32 dependencies, and recursively also
libintl8, libiconv2, base-cygwin, and libgcc1.



On the other hand, Cygwin package maintainers do a pretty good job of
not breaking existing setups, so "update everything" (to the "curr"
version) is usually a safe bet.---I've been doing that for over four
years and the only thing that hicc-upped regularly (and required
rebasing or peflagsall) was git-svn.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: setup.exe considerations (was: Doubtful about unison)

[Andy Koppe]

On 1 March 2011 10:57, Matthias Andree wrote:
> Am 01.03.2011 08:20, schrieb Andy Koppe:
>> On 28 February 2011 19:52, Matthias Andree wrote:
>
>>> Which is the problem: the unison command was compiled against a newer
>>> cygwin1.dll than yours.
>>
>> To be fair, setup.exe ought to be able to resolve or warn about such
>> version dependencies. Unfortunately the infrastructure for that isn't
>> in place, as it would require version requirements to be expressed in
>> packages' setup.hint files (rather than in their READMEs, as they are
>> at the moment).
>
> No it doesn't require such version dependencies.
>
> As a lightweight alternative, setup.exe might just recursively select
> all "requires" packages that a newly installed or upgraded package
> depends on "for update" (possibly from the same version branch,
> curr/test/prev), making sure not to implicitly downgrade.

Good idea, although that would entail unnecessary (and unwanted)
updates, for example, the Cygwin DLL would get updated whatever
package you installed, even if the package was built years ago.

> On the other hand, Cygwin package maintainers do a pretty good job of
> not breaking existing setups, so "update everything" (to the "curr"
> version) is usually a safe bet.

True, and anything else is unsupported.

Andy

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: setup.exe considerations (was: Doubtful about unison)

[Andrew Schulman]

> >> Which is the problem: the unison command was compiled against a newer
> >> cygwin1.dll than yours.
> > 
> > To be fair, setup.exe ought to be able to resolve or warn about such
> > version dependencies. Unfortunately the infrastructure for that isn't
> > in place, as it would require version requirements to be expressed in
> > packages' setup.hint files (rather than in their READMEs, as they are
> > at the moment).

It would also require packagers to know what the version requirements are.
I can record what versions of things were installed when I built Unison -
or better yet, get cygport to record that for me - but I don't really know
whether it would break with an earlier or later version of cygwin, etc.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Olivier Lefevre]

On 3/1/2011 8:20 AM, Andy Koppe wrote:
> To be fair, setup.exe ought to be able to resolve or warn about such
> version dependencies.

That's what I was tempted to say. For the record this is what I did:
1) select Keep
2) manually pick unison
3) accept the dialog about dependencies
Yet AFAICT only Unison was installed.

This is complicated by the fact that I did not directly install but
did a first download-without-installation and then installed from
local bundles. The above is what happened at download time; I am no
longer sure what I did at installation time but most likely the same.

In a slightly different line of thought, isn't it rather brittle of
Cygwin that a minor upgrade (I was already at some 1.7 version)
breaks applications? Think, a contrario, of how you can still run
ancient Windows apps on XP.

Anyway I upgraded everything and now I am fine. I was badly burned
by a backward incompatibility a while back (1.5 -> 1.6?) and became
upgrade-shy. Maybe I will resume upgrading more frequently and
consistently.

Thanks for the help.

-- O.L.

PS: In a related vein, OpenSSH did not install its libraries, although
I re-re-re-installed it, causing exim, svn etc to fail. I had to unpack
the library tar ball manually.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: setup.exe considerations

[Olivier Lefevre]

On 3/1/2011 1:46 PM, Andy Koppe wrote:
> Good idea, although that would entail unnecessary (and unwanted)
> updates, for example, the Cygwin DLL would get updated whatever
> package you installed, even if the package was built years ago.

Indeed and upgrading Cygwin itself is the very thing I was trying
to avoid.

>> On the other hand, Cygwin package maintainers do a pretty good job of
>> not breaking existing setups, so "update everything" (to the "curr"
>> version) is usually a safe bet.
>
> True, and anything else is unsupported.

Fair enough.

-- O.L.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Andrew Schulman]

> Anyway I upgraded everything and now I am fine.

That's good.

As I commented in the other thread, I don't really know which versions of
Cygwin or other libraries will work with Unison, or any of my other
packages.  I just compile and release them.  For the most part that seems
to work - yours is the first report I can recall of an app, or Unison
specifically, breaking because Cygwin et al. hadn't been updated.

I generally figure that 1.7 is 1.7 and good luck everyone.

Anyway I'm glad it's working for you now.
Andrew.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: setup.exe considerations (was: Doubtful about unison)

[Andy Koppe]

On 1 March 2011 14:04, Andrew Schulman wrote:
>> >> Which is the problem: the unison command was compiled against a newer
>> >> cygwin1.dll than yours.
>> >
>> > To be fair, setup.exe ought to be able to resolve or warn about such
>> > version dependencies. Unfortunately the infrastructure for that isn't
>> > in place, as it would require version requirements to be expressed in
>> > packages' setup.hint files (rather than in their READMEs, as they are
>> > at the moment).
>
> It would also require packagers to know what the version requirements are.
> I can record what versions of things were installed when I built Unison -
> or better yet, get cygport to record that for me - but I don't really know
> whether it would break with an earlier or later version of cygwin, etc.

I think it would be entirely reasonable to record the version you
built against as the minimum requirement, as you couldn't be expected
to test against older libraries as well. Wanting to use latest Unison
with an old Cygwin DLL is a case of having your cake and eating it,
it's just that it would be good if setup.exe was able to point that
out. But, in another bakery-related metaphor, this is pie-in-the-sky.

If Unison broke with a later Cygwin version, that would be a
compatibility bug that would need to be fixed asap anyway.

Andy

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Andy Koppe]

On 1 March 2011 14:25, Olivier Lefevre wrote:
> On 3/1/2011 8:20 AM, Andy Koppe wrote:
>>
>> To be fair, setup.exe ought to be able to resolve or warn about such
>> version dependencies.
>
> That's what I was tempted to say. For the record this is what I did:
> 1) select Keep
> 2) manually pick unison
> 3) accept the dialog about dependencies
> Yet AFAICT only Unison was installed.

Yeah, the Keep button should come with a at-your-own-risk warning really.


> This is complicated by the fact that I did not directly install but
> did a first download-without-installation and then installed from
> local bundles. The above is what happened at download time; I am no
> longer sure what I did at installation time but most likely the same.
>
> In a slightly different line of thought, isn't it rather brittle of
> Cygwin that a minor upgrade (I was already at some 1.7 version)
> breaks applications? Think, a contrario, of how you can still run
> ancient Windows apps on XP.

The problem you had was a case of broken forward compatibility,
whereas your Windows example is talking about backward compatibility.
The Cygwin devs do try hard to maintain the latter, so even really old
packages in the distribution continue to run with the latest DLL. What
isn't guaranteed to work is running packages built on the latest DLL
with an old DLL, because that's likely to depend on new features in
the latest DLL.

Andy

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: setup.exe considerations (was: Doubtful about unison)

[Andrew Schulman]

> I think it would be entirely reasonable to record the version you
> built against as the minimum requirement, as you couldn't be expected
> to test against older libraries as well. Wanting to use latest Unison
> with an old Cygwin DLL is a case of having your cake and eating it,
> it's just that it would be good if setup.exe was able to point that
> out. But, in another bakery-related metaphor, this is pie-in-the-sky.

I don't know, it seems half-baked to me :)


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Olivier Lefevre]

On 3/3/2011 8:06 AM, Andy Koppe wrote:
>> In a slightly different line of thought, isn't it rather brittle of
>> Cygwin that a minor upgrade (I was already at some 1.7 version)
>> breaks applications? Think, a contrario, of how you can still run
>> ancient Windows apps on XP.
>
> The problem you had was a case of broken forward compatibility,
> whereas your Windows example is talking about backward compatibility.

Yes, you're right, I had it mostly backwards.

However in this case it seems the problem wasn't that Unison used new
features of Cygwin but that somehow the layout of the Cygwin DLL had
changed, in a way that broke applications. I am not much of a system-
level programmer but in higher-level languages you'd expect things to
keep working as long as functionality (i.e., method signatures) has not
changed or that the new functionality is a strict superset of the older
one. I am sure I am betraying a woeful ignorance of C-level programming,
of linkers etc (which maybe isn't such a wise thing to do in a public
forum; oh well) with this question but isn't there a way to pin down
entry points and suchlike to ensure better forward compatibility? Would
rebaseall have helped? This is just for my enlightenment: I am not
suggesting you twist yourself into pretzel shapes trying to ensure
stellar forward compatibility; I suspect Cygwin programming is tricky
enough as it is.

-- O.L.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Christopher Faylor]

On Thu, Mar 03, 2011 at 02:46:59PM +0100, Olivier Lefevre wrote:
>On 3/3/2011 8:06 AM, Andy Koppe wrote:
>>> In a slightly different line of thought, isn't it rather brittle of
>>> Cygwin that a minor upgrade (I was already at some 1.7 version)
>>> breaks applications? Think, a contrario, of how you can still run
>>> ancient Windows apps on XP.
>>
>> The problem you had was a case of broken forward compatibility,
>> whereas your Windows example is talking about backward compatibility.
>
>Yes, you're right, I had it mostly backwards.
>
>However in this case it seems the problem wasn't that Unison used new
>features of Cygwin but that somehow the layout of the Cygwin DLL had
>changed, in a way that broke applications. I am not much of a system-
>level programmer but in higher-level languages you'd expect things to
>keep working as long as functionality (i.e., method signatures) has not
>changed or that the new functionality is a strict superset of the older
>one. I am sure I am betraying a woeful ignorance of C-level programming,
>of linkers etc (which maybe isn't such a wise thing to do in a public
>forum; oh well) with this question but isn't there a way to pin down
>entry points and suchlike to ensure better forward compatibility? Would
>rebaseall have helped? This is just for my enlightenment: I am not
>suggesting you twist yourself into pretzel shapes trying to ensure
>stellar forward compatibility; I suspect Cygwin programming is tricky
>enough as it is.

I can't make much sense of the above.  It seems like gobble-de-gook.
Except for certain very rare cases, old programs should work fine with
new Cygwin DLLs.  We don't "change the layout" in a way that breaks
compatibility for old programs and new DLLs.

Since we do continually augment the Cygwin DLL by adding new features
and new functions, a program which is linked with a new Cygwin DLL may
make use of the new functions.  There isn't anything, short of time
travel, that the Cygwin DLL can do at that point to make the program
backwards compatible.  It's possible that a program might want to take
newer features into account but I think it would be rather daft and
counter-productive for anyone maintaining a program to worry about
that scenario.

Windows itself offers new APIs in newer OSes.  So a program built to
work on Windows 7 may not work on Windows XP.  That's just the way
the world works.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Olivier Lefevre]

On 3/3/2011 5:45 PM, Christopher Faylor wrote:
> I can't make much sense of the above.

Than explain me what was meant by "The program
entry point __ctype_ptr__ was not found in cygwin1.dll"
Or is it a function entry point?

-- O.L.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Olivier Lefevre]

I think the english message should have been "The procedure
entry point __ctype_ptr__ could not be located in the dynamic
link library cygwin1.dll"; I mistranslated "procedure" as
"program". So this just means that the procedure __ctype_ptr__
cannot be found in the DLL, correct?

And is it a recent addition? I googled it but could not find
any indication of when it was introduced.

-- O.L.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Corinna Vinschen]

On Mar  4 08:08, Olivier Lefevre wrote:
> I think the english message should have been "The procedure
> entry point __ctype_ptr__ could not be located in the dynamic
> link library cygwin1.dll"; I mistranslated "procedure" as
> "program". So this just means that the procedure __ctype_ptr__
> cannot be found in the DLL, correct?
> 
> And is it a recent addition? I googled it but could not find
> any indication of when it was introduced.

__ctype_ptr__ has been introduced into newlib July 2008.  It's available
ever since.  It has been introduced into Cygwin with all developer
snapshots later than that, and officially with the first 1.7.0 test
release.  It was never introduced into Cygwin 1.5, though, given that
the last version, 1.5.25-15 was release in June 2008.

So, if you got this error message, it means you were running an
application built for 1.7 under a 1.5 Cygwin DLL.


Corinna


-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Christopher Faylor]

On Fri, Mar 04, 2011 at 10:47:25AM +0100, Corinna Vinschen wrote:
>On Mar  4 08:08, Olivier Lefevre wrote:
>> I think the english message should have been "The procedure
>> entry point __ctype_ptr__ could not be located in the dynamic
>> link library cygwin1.dll"; I mistranslated "procedure" as
>> "program". So this just means that the procedure __ctype_ptr__
>> cannot be found in the DLL, correct?
>> 
>> And is it a recent addition? I googled it but could not find
>> any indication of when it was introduced.
>
>__ctype_ptr__ has been introduced into newlib July 2008.  It's available
>ever since.  It has been introduced into Cygwin with all developer
>snapshots later than that, and officially with the first 1.7.0 test
>release.  It was never introduced into Cygwin 1.5, though, given that
>the last version, 1.5.25-15 was release in June 2008.
>
>So, if you got this error message, it means you were running an
>application built for 1.7 under a 1.5 Cygwin DLL.

Right: i.e., you're running a new application with an old DLL.

I just went back and read this inexplicably long thread and see that,
also inexplicably, no one asked for cygcheck output as requested by
http://cygwin.com/problems.html .  It's likely that this would have
been detected many messages ago if you'd provided that.

If I missed this in my archive spelunking then I apologize.  Otherwise,
I think there's a lesson here for us all.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Doubtful about unison

[Olivier Lefevre]

On 3/4/2011 10:47 AM, Corinna Vinschen wrote: [...]

Thanks. Now that's clear.

-- O.L.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple