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/#unsubscr
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
>>
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
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 recen
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:
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 yo
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
> 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
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 uni
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
> 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
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 U
> >> 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 r
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 resol
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. Unfortu
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
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 c
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: i
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 knowled
> > 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:\WI
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
> 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
> 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/prob
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: ht
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é B
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/
Docu
26 matches
Mail list logo
