The MD5 hash of setup.exe on mirrors.kernel.org does not match the hash on
ftp.cygwin.com.
$ wget ftp://ftp.cygwin.com/pub/cygwin/setup.exe
$ md5sum.exe setup.exe
b31ddcef84f25919a5d3184167b4a90d *setup.exe
$ wget http://mirrors.kernel.org/sourceware/cygwin/setup.exe
$ md5sum.exe setup.exe
fbc848
cgf wrote
>
> How about if we eliminate -mno-cygwin from future releases and either
> provide our own mingw cross-tools or wrap the offerings from
> mingw.org?
I would miss -mno-cygwin. Gcc -mno-cygwin suppports symlinks, mingw
doesn't.
--host=i686-pc-cygwin --target=i686-pc-cygwin would be
Kataria, Sunil wrote:
I found that less was not working...and got it fixed (copied "less" from
old binaries)
However still not been able to see the man pages.
When I run the man page it shows some empty lines and that's it.
Does someone know about this issue and the fix?
Regards,
Sunil
---
I found that less was not working...and got it fixed (copied "less" from
old binaries)
However still not been able to see the man pages.
When I run the man page it shows some empty lines and that's it.
Does someone know about this issue and the fix?
Regards,
Sunil
-Original Message-
[I haven't read the whole thread yet, so I reserve the right to revise
and extend. Also, to say something somebody else already did, or
otherwise generally make an idiot of myself]
Christopher Faylor wrote:
How about if we eliminate -mno-cygwin from future releases and either
provide our own
Corinna Vinschen wrote:
[..] The next major Cygwin release will be able to read
native NTFS symlinks and treats them as symlinks. However, it's not
planned to utilize native NTFS symlinks when creating symlinks in Cygwin.
Actually, that sounds perfect. The main thing is to recognize them as
On Wed, 31 Jan 2007, Christopher Faylor wrote:
> On Wed, Jan 31, 2007 at 10:29:01AM -0600, Matthew Woehlke wrote:
> >Matt Wozniski wrote:
> >>Before simply ripping out support for it, how about just adding a
> >>message to gcc so that when passed "-mnocygwin" on the command line, it
> >>warns that
On Jan 31, 2007, at 6:46 AM, Brian Ford wrote:
On Fri, 26 Jan 2007, Peter Rehley wrote:
Hello,
I tried the latest release of cygwin1.dll (1.5.24-1) and it still is
hanging in the same way. I've tried to debug further with gdb, but
so far I haven't got any useful information out of gdb.
I'l
Hi
When I run a man page, it reported
Error executing formatting or display command.
System command (cd "/usr/share/man" && (echo ".ll 15.1i"; echo ".nr LL
15.1i"; echo ".pl 1100i"; /usr/bin/gunzip -c
'/usr/share/man/man1/cat.1.gz'; echo ".\\\""; echo ".pl \n(nlu+10") |
/usr/bin/tbl | /usr/
Chris Sutcliffe wrote:
I just thought that something which provides similar functionality to
what is available now would be required. That means MinGW versions of
gcc and binutils.
As long as I'm able to compile w32api and mingw-runtime for MinGW from
within Cygwin, I'll be a happy camper.
Ch
Kataria, Sunil wrote:
When I run a man page, it reported
Error executing formatting or display command.
System command (cd "/usr/share/man" && (echo ".ll 15.1i"; echo ".nr LL
15.1i"; echo ".pl 1100i"; /usr/bin/gunzip -c
'/usr/share/man/man1/cat.1.gz'; echo ".\\\""; echo ".pl \n(nlu+10") |
I just thought that something which provides similar functionality to
what is available now would be required. That means MinGW versions of
gcc and binutils.
As long as I'm able to compile w32api and mingw-runtime for MinGW from
within Cygwin, I'll be a happy camper.
Chris
--
Chris Sutcliffe
When I run a man page, it reported
Error executing formatting or display command.
System command (cd "/usr/share/man" && (echo ".ll 15.1i"; echo ".nr LL
15.1i"; echo ".pl 1100i"; /usr/bin/gunzip -c
'/usr/share/man/man1/cat.1.gz'; echo ".\\\""; echo ".pl \n(nlu+10") |
/usr/bin/tbl | /usr/bin/
On Wed, Jan 31, 2007 at 12:46:28PM -0500, Williams, Gerald S (Jerry) wrote:
>Christopher Faylor wrote:
>> When I was maintaining cygwin's gcc, I often thought about eliminating
>> -mno-cygwin and just providing a pure mingw cross compiler in the
>> distribution.
>
>I completely agree. Anybody depen
Christopher Faylor wrote:
> When I was maintaining cygwin's gcc, I often thought about eliminating
> -mno-cygwin and just providing a pure mingw cross compiler in the
> distribution.
I completely agree. Anybody depending on -mno-cygwin can create
their own shell wrapper. I personally don't care so
> On Jan 28 11:57, Yitzchak Scott-Thoennes wrote:
>> Corinna Vinschen wrote:
>> > Thanks for the info. It's interesting to know. What I still don't
>> get,
>> > however, is the fact that the same statement does not waste memory on
>> > the x86 Linux Perl 5.8.5, but does on the x86 Cygwin Perl 5.8
Christopher Faylor wrote:
On Wed, Jan 31, 2007 at 10:29:01AM -0600, Matthew Woehlke wrote:
Matt Wozniski wrote:
Before simply ripping out support for it, how about just adding a
message to gcc so that when passed "-mnocygwin" on the command line, it
warns that it's deprecated and will be remove
On Wed, 31 Jan 2007, Dave Korn wrote:
> On 31 January 2007 16:19, Brian Ford wrote:
> > On Wed, 31 Jan 2007, Christopher Faylor wrote:
> >> If we REALLY wanted to preserve -mno-cygwin, we could do so as a shell
> >> script wrapper for gcc but, personally, I think I'd rather just tell
> >> people to
On Wed, Jan 31, 2007 at 10:29:01AM -0600, Matthew Woehlke wrote:
>Matt Wozniski wrote:
>>Before simply ripping out support for it, how about just adding a
>>message to gcc so that when passed "-mnocygwin" on the command line, it
>>warns that it's deprecated and will be removed in the near future,
>
Matt Wozniski wrote:
Before simply ripping out support for it, how about just adding a
message to gcc so that when passed "-mnocygwin" on the command line, it
warns that it's deprecated and will be removed in the near future,
before processing?
...and add a REALLY BIG MESSAGE that, if something
Matt Wozniski wrote:
> phase out this 'feature'? While I agree that it wasn't a good feature
> to add in the first place, I think that removing it without at least a
> deprecation warning for a version or two will flood the mailing list
> with traffic by people who didn't realize that something t
On 31 January 2007 16:19, Brian Ford wrote:
> On Wed, 31 Jan 2007, Christopher Faylor wrote:
>
>> If we REALLY wanted to preserve -mno-cygwin, we could do so as a shell
>> script wrapper for gcc but, personally, I think I'd rather just tell
>> people to use the cross-compiler.
>
> Why not just a
On Wed, 31 Jan 2007, Christopher Faylor wrote:
> If we REALLY wanted to preserve -mno-cygwin, we could do so as a shell
> script wrapper for gcc but, personally, I think I'd rather just tell
> people to use the cross-compiler.
Why not just alias -mno-cygwin to -b i686-mingw?
--
Brian Ford
Lead
On 1/31/07, Christopher Faylor wrote:
I feel pretty strongly about this. I really don't think this option should
exist. It's unlike every other gcc port on the planet.
cgf
Before simply ripping out support for it, how about just adding a
message to gcc so that when passed "-mnocygwin" on the
On Wed, Jan 31, 2007 at 02:52:42PM -, Dave Korn wrote:
>On 31 January 2007 13:49, Corinna Vinschen wrote:
>
>[yep, ntsec, haven't forgotten. sorry for slowness!]
>
>> On Jan 31 08:31, Christopher Faylor wrote:
>>> On Wed, Jan 31, 2007 at 02:27:00PM +0100, Samuel Thibault wrote:
Eric Blake,
On Wed, Jan 31, 2007 at 02:48:42PM +0100, Corinna Vinschen wrote:
>On Jan 31 08:31, Christopher Faylor wrote:
>> On Wed, Jan 31, 2007 at 02:27:00PM +0100, Samuel Thibault wrote:
>> >Eric Blake, le Wed 31 Jan 2007 06:18:22 -0700, a ?crit :
>> >> I would much rather call the cross-compiler i686-mingw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Rehley wrote:
> Hello,
>
> One of the applications I've been working with has hanging issues. It
> will sometimes work properly, and sometimes it will hang and never
> continue through the rest of the program.
I have not done any pthread progr
Hello all. I've found this post:
http://www.thescripts.com/forum/thread32391.html
and I am having an identical problem.
I'm a newbie. I've installed cygwin (without python), and then installed
enthought - because I'm hoping to use the scypy tools, etc.
Anyway, I'm running the latest cygwin on a
On 31 January 2007 13:49, Corinna Vinschen wrote:
[yep, ntsec, haven't forgotten. sorry for slowness!]
> On Jan 31 08:31, Christopher Faylor wrote:
>> On Wed, Jan 31, 2007 at 02:27:00PM +0100, Samuel Thibault wrote:
>>> Eric Blake, le Wed 31 Jan 2007 06:18:22 -0700, a ?crit :
I would much ra
On Fri, 26 Jan 2007, Peter Rehley wrote:
> Hello,
>
> I tried the latest release of cygwin1.dll (1.5.24-1) and it still is
> hanging in the same way. I've tried to debug further with gdb, but
> so far I haven't got any useful information out of gdb.
>
> I'll keep trying to get some debug informat
On Jan 31 08:31, Christopher Faylor wrote:
> On Wed, Jan 31, 2007 at 02:27:00PM +0100, Samuel Thibault wrote:
> >Eric Blake, le Wed 31 Jan 2007 06:18:22 -0700, a ?crit :
> >> I would much rather call the cross-compiler i686-mingw-gcc than the
> >> current name of 'gcc -mno-cygwin'.
> >
> >Same for
On Wed, Jan 31, 2007 at 02:27:00PM +0100, Samuel Thibault wrote:
>Eric Blake, le Wed 31 Jan 2007 06:18:22 -0700, a ?crit :
>> I would much rather call the cross-compiler i686-mingw-gcc than the
>> current name of 'gcc -mno-cygwin'.
>
>Same for me.
Thinking about this some more, it seems like we'd
Eric Blake, le Wed 31 Jan 2007 06:18:22 -0700, a écrit :
> I would much rather call the cross-compiler i686-mingw-gcc than the
> current name of 'gcc -mno-cygwin'.
Same for me.
samuel
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/prob
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Christopher Faylor on 1/31/2007 6:13 AM:
>
> How about if we eliminate -mno-cygwin from future releases and either
> provide our own mingw cross-tools or wrap the offerings from mingw.org?
> This would mean that instead of saying 'gcc -mn
When I was maintaining cygwin's gcc, I often thought about eliminating
-mno-cygwin and just providing a pure mingw cross compiler in the
distribution. I really don't know why it wasn't done that way to begin
with. I have vague recollections of arguing for this when -mno-cygwin
was first introduce
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Patrick Herbst on 1/31/2007 6:07 AM:
> from your home directory ../../../ = one level up from the cygwin root.
One level up from cygwin root is still cygwin root. /.. == / as required
by POSIX.
- --
Don't work too hard, make some time f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Stephen Henry on 1/31/2007 2:50 AM:
>
> This works perfectly (from a directory in my home directory):
> $ ./x264.exe -o out.h264 ../../../testseq/yuv420/COASTGUARD-YUV420-CIF
> 352x288
>
> Whilst this does not:
> ./x264.exe -o out.264 /t
from your home directory ../../../ = one level up from the cygwin root.
for example... if home is c:\cygwin\home\user then that relative path
would put you at c:\
the root (/) for cygwin is actually the cygwin directory (c:\cygwin)
if you're trying to get just on your c:\ you have to specify it
John,
Please see the following:
http://cygwin.com/acronyms/#PPIOSPE
On Wed, Jan 31, 2007 at 12:54:51AM +0100, John F Burkhart wrote:
> I apologize to hijack your email, but I've found this post:
> http://www.thescripts.com/forum/thread32391.html
>
> and I am having an identical problem.
>
On Wed, Jan 31, 2007 at 12:51:27PM +, jano trouba wrote:
>>sys/socket.h is also a Cygwin thingy. Only the include files under
>>/usr/include/w32api and /usr/include/mingw are useful for non-cygwin
>>apps. If you want to use the POSIX headers, build a Cygwin app.
>
>OK
>
>Let's say I do not wa
sys/socket.h is also a Cygwin thingy. Only the include files under
/usr/include/w32api and /usr/include/mingw are useful for non-cygwin
apps. If you want to use the POSIX headers, build a Cygwin app.
OK
Let's say I do not want the POSIX flag. And I want to use only w32api and
mingw..
so
On Jan 31 10:52, jano trouba wrote:
>
> And also I do not understand :
>
> >> cc -Wall -D_POSIX_SOURCE -D__rtems__ -mno-cygwin -mwindows
> >-I../include/
> > ^^^
> >> [...]
> >> So did I miss a flag in order to compile, or a bad
On Jan 28 13:38, Shankar Unni wrote:
> This article from Mark "Sysinternals" Russinovitch discusses the new
> "real" symbolic link feature in Vista ("real" in that it's classic
> Unix-style, where the symlink is interpreted on the local OS, even for
> links in mounted shares, and can refer to ei
On Jan 30 06:12, Eric Blake wrote:
> This sounds like a problem in cygwin 1.5.24 with forking in general on
> xp64 [...]
Yes, my fault. I just uploaded a fixed 1.5.24-2 Cygwin release.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader
And also I do not understand :
> cc -Wall -D_POSIX_SOURCE -D__rtems__ -mno-cygwin -mwindows
-I../include/
^^^
> [...]
> So did I miss a flag in order to compile, or a bad location, or is it a
bug
> ??
No, you used a flag t
I've made a new version of the Cygwin DLL and associated utilities
available for download.
The 1.5.24-2 release fixes only one bug introduced in 1.5.24-1.
-1 was non-functional on XP 64 bit and 2003 Server 64 bit editions.
This should be rectified now.
To update your installation, click on the "
On Jan 28 11:57, Yitzchak Scott-Thoennes wrote:
> Corinna Vinschen wrote:
> > Thanks for the info. It's interesting to know. What I still don't get,
> > however, is the fact that the same statement does not waste memory on
> > the x86 Linux Perl 5.8.5, but does on the x86 Cygwin Perl 5.8.7 and th
> cc -Wall -D_POSIX_SOURCE -D__rtems__ -mno-cygwin -mwindows
-I../include/
^^^
> [...]
> So did I miss a flag in order to compile, or a bad location, or is it a
bug
> ??
No, you used a flag too many. The Cygwin header files and Cygwin
capab
On Jan 30 17:04, jano trouba wrote:
>
>
> Hello everybody...
>
> I uploaded last (as of yesterday) version of cygwin..
>
> Then I tried compiling some of my libraries...
>
> Here is the result on one dealing with sockets :
>
> cc -Wall -D_POSIX_SOURCE -D__rtems__ -mno-cygwin -mwindows -I../
Hi,
I have a really strange problem with my Cygwin installation. It
concerns a filename parameter given to a application launched from the
bash command prompt. The problem is as follows:
I have an application that takes a filename parameter. The application
uses the 'fopen' command to open the f
50 matches
Mail list logo
