-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Updated to address packaging issues. /usr/lib/charset.alias and uptime(1)
are removed. readlink(1) still conflicts with cygutils, so we will need a
cygutils 1.2.5-2 soon.
Also, this drop fixes pwd(1) by working around the broken nature of d_ino
in
I have installed cygwin, plus Cygwin-X, to c:\progra~1\cygwin. I have used it
that way for years. However, I have noticed that when I try to run an
X-Windows program using the pre-defined shortcuts in the start menu, such as
xcalc or bitmap, that they will not run. When I look at the properties
Mike McCollister wrote:
I have installed cygwin, plus Cygwin-X, to c:\progra~1\cygwin. I have used it
that way for years. However, I have noticed that when I try to run an
X-Windows program using the pre-defined shortcuts in the start menu, such as
xcalc or bitmap, that they will not run.
Hi, I seem to be suffering this issue:
http://www.mail-archive.com/cygwin-xfree@cygwin.com/msg13265.html /
http://sources.redhat.com/ml/cygwin-xfree/2004-12/msg00161.html
I'm running XP on one side, Fedora Core 3 on the other. I'm launching
cygwin/x (Release: 6.8.1.0-9) with
On Tue, 1 Feb 2005, Auz wrote:
Hi, I seem to be suffering this issue:
http://www.mail-archive.com/cygwin-xfree@cygwin.com/msg13265.html /
http://sources.redhat.com/ml/cygwin-xfree/2004-12/msg00161.html
I'm running XP on one side, Fedora Core 3 on the other. I'm launching
cygwin/x
CVSROOT:/cvs/src
Module name:src
Changes by: [EMAIL PROTECTED] 2005-02-01 15:11:50
Modified files:
winsup/cygwin : ChangeLog fhandler.cc fhandler.h
fhandler_proc.cc fhandler_process.cc
fhandler_socket.cc path.cc
CVSROOT:/cvs/uberbaum
Module name:winsup
Changes by: [EMAIL PROTECTED] 2005-02-01 16:49:14
Modified files:
cygwin : ChangeLog cygthread.cc devices.cc devices.h
devices.in dtable.cc fhandler_proc.cc path.cc
CVSROOT:/cvs/uberbaum
Module name:winsup
Changes by: [EMAIL PROTECTED] 2005-02-01 17:16:15
Modified files:
cygwin : ChangeLog fhandler_proc.cc
Log message:
* fhandler_proc.cc (format_proc_partitions): Remove PartitionType check
since
it
Hello Cygwin Gurus,
Before anyone starts flaming me, I'd like to say that the question I have
does not concern any particular app in cygwin but the whole of cygwin (as
in literally) on our local mirror...(If this is better discussed in
cygwin-talk, please point it out.)
I have updated the version of cron on cygwin.com to 3.0.1-19.
I removed the -18 version from the server since it was missing an
important patch. Other than that, it's what has been promissed
for -18:
Thanks to Pierre Humblet for the following contribution:
Small improvements to cron-config
Hello,
I am porting a plasma simulation code from linux to cygwin (my windows
box is 4x faster than the linux box I can get).
During the linking phase I am getting an error message about unresolved
symbols. I am a bit puzzled about some of them (tcl/tk, xpm) because I
believe that I am
[EMAIL PROTECTED] kirjoitti:
Hello Cygwin Gurus,
Our cygwin mirror is on a linux box running trustix secure linux version
2.0. I decided to upgrade to trustix secure linux 2.2 and as I was about
to created a bootdisk for a network install, I inadvertently typed:
[clipped very sad thing that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This question came up on the coreutils list:
Does cygwin provide any support for sparse files on NTFS volumes that
support it? lseek() could be patched to use FSCTL_SET_ZERO_DATA when a
seek jumps past the end of a file open for writing, but there
At 04:07 AM 2/1/2005, Mirko wrote:
During the linking phase I am getting an error message about unresolved
symbols. I am a bit puzzled about some of them (tcl/tk, xpm) because I
believe that I am pointing to the correct libraries (so much about my
knowledge of pointing to libraries), and
On Tue, Feb 01, 2005 at 03:20:54PM +0200, Jani Tiainen wrote:
[EMAIL PROTECTED] kirjoitti:
Hello Cygwin Gurus,
Our cygwin mirror is on a linux box running trustix secure linux version
2.0. I decided to upgrade to trustix secure linux 2.2 and as I was about
to created a bootdisk for a network
On Tue, Feb 01, 2005 at 06:48:56AM -0700, Eric Blake wrote:
This question came up on the coreutils list:
Does cygwin provide any support for sparse files on NTFS volumes that
support it? lseek() could be patched to use FSCTL_SET_ZERO_DATA when a
seek jumps past the end of a file open for
On Feb 1 06:48, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This question came up on the coreutils list:
Does cygwin provide any support for sparse files on NTFS volumes that
support it? lseek() could be patched to use FSCTL_SET_ZERO_DATA when a
seek jumps past the
-Original Message-
From: cygwin-owner On Behalf Of Christopher Faylor
Sent: 01 February 2005 14:57
On Tue, Feb 01, 2005 at 03:20:54PM +0200, Jani Tiainen wrote:
list-subscriber kirjoitti:
Hello Cygwin Gurus,
Our cygwin mirror is on a linux box running trustix secure
linux
I have problems compiling DLLs with -mno-cygwin flag, using libtool.
Command is: libtool --mode=link --tag=CXX g++ -rpath
/Projects/Tests/libtool -mno-cygwin -no-undefined -o libcommon.la common.lo
Output:
rm -fr .libs/libcommon.a .libs/libcommon.la .libs/libcommon.lai
g++ -shared -nostdlib
On Tue, 1 Feb 2005, Dave Korn wrote:
-Original Message-
From: cygwin-owner On Behalf Of Christopher Faylor
Sent: 01 February 2005 14:57
On Tue, Feb 01, 2005 at 03:20:54PM +0200, Jani Tiainen wrote:
list-subscriber kirjoitti:
Hello Cygwin Gurus,
Our cygwin mirror is on a
Vladius wrote:
I have problems compiling DLLs with -mno-cygwin flag, using libtool.
Command is: libtool --mode=link --tag=CXX g++ -rpath
/Projects/Tests/libtool -mno-cygwin -no-undefined -o libcommon.la
common.lo
Output:
rm -fr .libs/libcommon.a .libs/libcommon.la .libs/libcommon.lai
g++ -shared
-Original Message-
From: cygwin-owner On Behalf Of Max Bowsher
Sent: 01 February 2005 15:35
Vladius wrote:
As U can see... it automatically passes -lcygwin flag to the
linker(g++). When cygcheck'ing resulting DLL it lists
cygwin DLL as one
of its dependencies.
I heard
Vladius wrote:
I have problems compiling DLLs with -mno-cygwin flag, using libtool.
Command is: libtool --mode=link --tag=CXX g++ -rpath
/Projects/Tests/libtool -mno-cygwin -no-undefined -o libcommon.la
common.lo
Output:
rm -fr .libs/libcommon.a .libs/libcommon.la .libs/libcommon.lai
g++
On Tue, Feb 01, 2005 at 03:56:17PM -, Dave Korn wrote:
-Original Message-
From: cygwin-owner On Behalf Of Max Bowsher
Sent: 01 February 2005 15:35
Vladius wrote:
As U can see... it automatically passes -lcygwin flag to the
linker(g++). When cygcheck'ing resulting DLL it
-Original Message-
From: Vladius [mailto:[EMAIL PROTECTED]
I have found a solution to hack this issue.
1.Goto usr/autotool/devel/bin/
2.Open libtool file with a text editor(vim).
3.Search for postdeps initialisation. (postdeps= string)
4.Remove -lcygwin initialisation literal
-Original Message-
From: cygwin-owner On Behalf Of Christopher Faylor
Sent: 01 February 2005 17:27
Has it been established that the cygwin version of libtool is *supposed*
to handle mingw? I'd be rather surprised if that was a goal.
Nope, I just assumed that it could be made to
On Tue, Feb 01, 2005 at 06:15:50PM -, Dave Korn wrote:
-Original Message-
From: cygwin-owner On Behalf Of Christopher Faylor
Sent: 01 February 2005 17:27
Has it been established that the cygwin version of libtool is *supposed*
to handle mingw? I'd be rather surprised if that was
I too have been seeing a problem with very slow file access in large
directories.
Specifically,
On a Cygwin/Win2k box, I have a mirror of an FTP site. The site has 2.5
million files spread between 100 directories.
(20,000 - 30,000 files per directory) I have previously run this number
of
On Jan 31 12:25, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] said:
There's a patch in current Cygwin CVS which should solve the icon
problem.
Super. Tho, will fixing the icon problem also fix the behavior dichotomy
between Explorer and Open/Save dialogs (which I noted in my
At 02:28 PM 2/1/2005, you wrote:
I too have been seeing a problem with very slow file access in large
directories.
Specifically,
On a Cygwin/Win2k box, I have a mirror of an FTP site. The site has 2.5
million files spread between 100 directories.
(20,000 - 30,000 files per directory) I have
On Tue, 2005-02-01 at 14:51 -0500, Larry Hall wrote:
At 02:28 PM 2/1/2005, you wrote:
I too have been seeing a problem with very slow file access in large
directories.
Specifically,
On a Cygwin/Win2k box, I have a mirror of an FTP site. The site has 2.5
million files spread between 100
Dave Korn wrote:
-Original Message-
From: Vladius [mailto:[EMAIL PROTECTED]
I have found a solution to hack this issue.
1.Goto usr/autotool/devel/bin/
2.Open libtool file with a text editor(vim).
3.Search for postdeps initialisation. (postdeps= string)
4.Remove -lcygwin
On Tuesday, February 01, 2005 3:22 PM [EST], Ken Sheldon wrote:
More information:
Not only Cygwin apps incur this large performance penalty.
Something similar happens with the cmd.exe prompt command DIR,
with the windows file explorer, or with IIS (FTP server). This
only seems to happen in
Dave Korn wrote:
-Original Message-
From: Vladius [mailto:[EMAIL PROTECTED]
I have found a solution to hack this issue.
1.Goto usr/autotool/devel/bin/
2.Open libtool file with a text editor(vim).
3.Search for postdeps initialisation. (postdeps= string)
4.Remove -lcygwin
On Tue, Feb 01, 2005 at 11:43:04AM -0800, [EMAIL PROTECTED] wrote:
On Jan 31 12:25, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] said:
There's a patch in current Cygwin CVS which should solve the icon
problem.
Super. Tho, will fixing the icon problem also fix the behavior dichotomy
Further coreutils-5.3.0 debugging turned up more POSIX bugs in cygwin:
pwd.h defines struct passwd with the pw_uid and pw_gid members as ints,
although POSIX requires uid_t and gid_t.
http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html
sys/time.h defines utimes with non-const
On Tue, Feb 01, 2005 at 08:58:03PM +, [EMAIL PROTECTED] wrote:
readdir() populates the dirent.d_ino member with a hashed filename,
regardless of whether the file is located on NTFS and actually has an
inode. This means that readdir() and stat()'s idea of inode are
different, and this breaks
We have an application which can run in a command-line driven mode. For Windows,
the app is compiled with MSVC. However, some of our users (including some people
in-house) like to use it from within a Cygwin shell. It works fine in a bash
running in a Windows console window, but not when running
Larry Hall wrote:
Chris has already answered that question earlier in
the discussion. He needs physical access to the
machine to resolve this problem. Remote access isn't
enough.
Forgive my ignorance, but I read the archives back to
1 jan 2004 but found no explanation why remote access
doesn't
I just want to add that the app must still be able to distinguish between having
had its stdin redirected or not.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:
Hi all,
I have just spent a couple of days trying to install cygwin on my
windows 2003 server, it would freeze about 85% and come up with an error
about being unable to open a log file, well after sifting through the
mailing list I found nothing about this fault. I was beginning to give
On Tue, 1 Feb 2005, Joris van der Sande wrote:
Larry Hall wrote:
Chris has already answered that question earlier in
the discussion. He needs physical access to the
machine to resolve this problem. Remote access isn't
enough.
Forgive my ignorance, but I read the archives back to
1
On Tue, Feb 01, 2005 at 11:01:11PM +0100, Joris van der Sande wrote:
Larry Hall wrote:
Chris has already answered that question earlier in the discussion. He
needs physical access to the machine to resolve this problem. Remote
access isn't enough.
Forgive my ignorance, but I read the archives
Ken Sheldon wrote:
Not only Cygwin apps incur this large performance penalty. Something
similar happens with the cmd.exe prompt command DIR, with the windows
file explorer, or with IIS (FTP server). This only seems to happen in
the directory structures created by my CygWin scripts (using
On Tuesday, February 01, 2005 7:53 PM [EST], Brian Dessent wrote:
Ken Sheldon wrote:
Not only Cygwin apps incur this large performance penalty.
Something similar happens with the cmd.exe prompt command DIR,
with the windows file explorer, or with IIS (FTP server). This
only seems to happen
I cannot log on my ftp server.
In the ftp client I get :
==8==8==
Response: 220 ProFTPD 1.2.10 Server (ProFTPD Default
Installation) [127.0.0.1]
Command:USER anonymous
Response: 331 Anonymous login ok, send your complete
email address as your
Dear All,
I installed Cygwin on Windows Xp SP2. During install to select some packages
like; apache postgresql and download from net. I installed cygwin to
D:\cygwin. There was no error until installation finish but when I run
cygwin.bat.
It shown propmt but can't run any command.
bash-2.05b$
Maybe somehow the base packages were deselected or something , so what
i would do is uninstall cygwin completely, then run setup.exe again
and let it do a default install. Then after installation is complete
run setup.exe again to add more packages. Its a good idea to save
setup.exe because it
Christopher Faylor wrote:
Has it been established that the cygwin version of libtool is *supposed*
to handle mingw? I'd be rather surprised if that was a goal.
DING! We HAVE a winner!
The installed libtool has been configured -- by virtue of the fact that
I ran the build in a cygwin environment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Christopher Faylor on 2/1/2005 2:51 PM:
On Tue, Feb 01, 2005 at 08:58:03PM +, Eric Blake wrote:
readdir() populates the dirent.d_ino member with a hashed filename,
This is not going to be fixed. It's a longstanding problem.
On Tue, 1 Feb 2005, Charles Wilson wrote:
Christopher Faylor wrote:
OTOH, I never have understood why tools insist on including such things as
-lcygwin or -lc on a linker command line.
There's a good reason for libtool to do so, but it escapes me at the moment.
Trust Me(tm).
Innate
On Tue, Feb 01, 2005 at 08:50:06PM -0700, Eric Blake wrote:
According to Christopher Faylor on 2/1/2005 2:51 PM:
On Tue, Feb 01, 2005 at 08:58:03PM +, Eric Blake wrote:
readdir() populates the dirent.d_ino member with a hashed filename,
This is not going to be fixed. It's a longstanding
On Tue, Feb 01, 2005 at 11:02:18PM -0500, Igor Pechtchanski wrote:
On Tue, 1 Feb 2005, Charles Wilson wrote:
Christopher Faylor wrote:
OTOH, I never have understood why tools insist on including such things
as -lcygwin or -lc on a linker command line.
There's a good reason for libtool to do so,
At 10:34 PM 2/1/2005, you wrote:
Maybe somehow the base packages were deselected or something , so what
i would do is uninstall cygwin completely, then run setup.exe again
and let it do a default install. Then after installation is complete
run setup.exe again to add more packages.
Ah, that's
Cool - does that mean it was a bug and was fixed, or did it just
happen to disappear due to some other improvement? Either way...
'bout how long does it take till things go from CVS to a release,
these days. I've tried twice to build from CVS, but never seem
to have gotten a full build to run
linda w wrote:
Cool - does that mean it was a bug and was fixed, or did it just
happen to disappear due to some other improvement? Either way...
I think that the functionality did not exist before, and Corinna added
it. So, not a bug, just things that weren't implemented yet. I suspect
On Mon, Jan 31, 2005 at 12:00:16PM -0500, Christopher Faylor wrote:
On Wed, Jan 05, 2005 at 08:40:26PM -0800, Yitzchak Scott-Thoennes wrote:
On Wed, Jan 05, 2005 at 11:05:13PM -0500, Christopher Faylor [EMAIL
PROTECTED] wrote:
On Wed, Jan 05, 2005 at 06:36:02PM -0800, Yitzchak Scott-Thoennes
HI!
I got errors during installation and ssh setup. One error repeated itself
several times during the final phase of the instalation.
entry point _fopen64 link could not be located in cygwin1.dll
the other message appeared during the ssh setup.
entry point _getreent could not be located
Arthur Arapetian wrote:
I got errors during installation and ssh setup. One error repeated itself
several times during the final phase of the instalation.
entry point _fopen64 link could not be located in cygwin1.dll
the other message appeared during the ssh setup.
entry point
59 matches
Mail list logo
