I've been trying to get the new gcc PCH code working on Cygwin.
The gcc PCH implementation works by using mmap() to quickly
resurrect the precompiled header when compiling on a new file.
To allow this to be done quickly, mmap() is used when creating the
precompiled header and the precompiled infor
Corinna Vinschen wrote:
On Thu, Jul 03, 2003 at 10:19:42AM -0400, Christopher Faylor wrote:
On Thu, Jul 03, 2003 at 11:47:28AM +0200, Corinna Vinschen wrote:
>Do you mean something like this:
>
> If addr is given, check if it's 64K aligned. If not, align and
> raise the memory requirement accord
Corinna Vinschen wrote:
In other words, addr -= (off - gran_off). This address should
now be 64k aligned. Error if it isn't.
Use this address when calling MapViewOfFileEx(). If the call fails
and MAP_FIXED is not set, then try again with addr = 0.
Yes, that's what I mentioned in my first reply. I
Corinna Vinschen wrote:
o I think there is a problem with the address arithmetic in the match()
method used by munmap(). Compare the code in list::match (__off64_t
off, DWORD len) with list::match (caddr_t addr, DWORD len,
__off32_t start).
>
Uhm, no.
Thanks for the detailed explanation. You'
I got this error trying to build gcc using cygwin 1.5.11. This problem
is easily reproduced:
X:> touch Tfoo.exe
X:> chmod a+rx Tfoo
X:> ls -l Tfoo
-rwxrwxrwx1 earlch mkpasswd0 Oct 8 22:08 Tfoo
X:> mv Tfoo foo
mv: `Tfoo' and `foo' are the same file
Huh?
Digging deeper, I see that ls u
Christopher Faylor wrote:
I don't understand what you are implying. Is this patch ready to go
or does it need more work?
Chris,
Please refer to my reply to your previous response:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01996.html
What do you suggest?
Earl
--
Unsubscribe info: http://cy
Christopher Faylor wrote:
What do you suggest?
If you have a patch that's ready to go, I'll review it. If it isn't
ready to go then there's not anything for me to do as far as I can tell.
If you're asking me to work on it, then that is something I don't have
time to do.
Chris,
I'm asking whether I
Brian Ford wrote:
Does any of this help you understand where CGF is coming from?
Brian,
Thanks for taking the time to explain the situation to me.
I'm not sure what I'll do at this point.
I think this is a worthwhile patch in general. The precompiled
header processing in gcc is a valuable feature t
This code used to work on Perl 5.6.1-2 on Cygwin 1.3.10.
I've now moved to Perl 5.8.5-3 on Cygwin 1.5.11.
Here is the Perl program:
binmode STDOUT;
print "Hello\n";
1. Output to file on text mount
perl foo.pl > foo.txt ; od -c foo.txt
000 H e l l o \r \n
Igor Pechtchanski wrote:
On Wed, 3 Nov 2004, Earl Chew wrote:
This code used to work on Perl 5.6.1-2 on Cygwin 1.3.10.
I've now moved to Perl 5.8.5-3 on Cygwin 1.5.11.
Here is the Perl program:
binmode STDOUT;
print "Hello\n";
1. Output to file on text mount
Christopher Faylor wrote:
You are missing the fact that the OP was reporting a real bug, apparently.
To confirm, I ran the program:
binmode STDOUT;
print "Hello\n";
using Perl 5.6.1-2 on Cygwin 1.5.11:
perl foo.pl > foo.txt ; od -c foo.txt
000 H e l l o \r \n
Yitzchak Scott-Thoennes wrote:
> So check the length.
Good idea:
binmode STDOUT;
print "Hello\n";
perl foo.pl > foo.txt ; od -c foo.txt ; ls -l foo.txt
000 H e l l o \r \n# Perl 5.8.5-3 Cygwin 1.5.11
-rw-r--r-- 1 earl mkpasswd 7 Nov 4 11:10 foo.txt
I think the name of the current executable is stored in myself->progname
within cygwin1.dll.
The more easily accessible __progname returns the basename of the
executable.
Is there a way for an application to obtain myself->program, other
than resorting to raw win32 call to GetModuleFileName()?
Earl
I'd like some guidance or suggestions as to how to debug a
problem that I suspect has to do with my hyperthreaded cpu machine.
The symptom is that I have two build scripts executing. The scripts
traverse directories, use make, bash, sh, perl, etc. I have two
hyperthreaded cpus running XP, and very
I'm working on a cygwin problem and have been looking at the Win32
process tree structure using Process Explorer from Sysinternals:
http://www.sysinternals.com/ntw2k/freeware/procexp.shtml
I'd like help understanding why Process Explorer shows cygwin
child processes as orphans, but win32 child proc
Earl Chew wrote:
I'd like help understanding why Process Explorer shows cygwin
child processes as orphans, but win32 child processes as children.
How is this so?
I think I've discovered the reason for this is that during
the fork/exec, the child that does the exec is discarded and
repla
We've come across a very subtle problem where child processes will
fail after some time. On our hyperthreaded systems, the child process
fails by consuming one thread, and degrading the system (typically
locking up the desktop) and power-off is the only recovery.
We use cygwin to provide a build sy
The call to GetFileSize() doesn't match the Microsoft documentation,
and invariably mis-sizes the disk image as zero.
Earl
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ
Earl Chew wrote:
The call to GetFileSize() doesn't match the Microsoft documentation,
and invariably mis-sizes the disk image as zero.
A couple of comments regarding your recent changes:
a. GetFileSize() returns the bits 32-63 of the file size in
the 2nd parameter. I think code like th
Christopher Faylor wrote:
Let me again point out that a cygwin program shouldn't be doing *ANY OF
THIS*.
It shouldn't be calling GetFileSize and it shouldn't be calling
CreateFile.
I think part of the original motivation might have been that under
some circumstances this set of programs needs to be
This patch duplicates the change in gzip-1.3.3-4 and is also mentioned
in:
http://sources.redhat.com/ml/cygwin/1997-02/msg00204.html
Earl
--- tailor.h~ 2002-09-25 14:21:30.0 -0700
+++ tailor.h2004-10-15 17:42:50.229826500 -0700
@@ -299,7 +299,11 @@
#endif
#ifndef SET_BINARY_MODE
+#
I have a Makefile which performs "rm -f -r" as part of a clean target.
On Win7 with 1.7.5-1 this can fail with:
rm -f -r win32
rm: cannot remove directory `win32': Directory not empty
I tried 1.7.7-1 but the problem still seems to be there.
Doing a little digging, I find that /bin/rm calls
unl
> There shouldn't be any race. When you set the delete disposition,
> the file is actually deleted as soon as the last handle to the file
> is closed. If the file isn't opened by another process, it will
> disappear right at the NtClose at the end of unlink_nt. Please note
> that the call to che
Corinna Vinschen wrote:
> ...or having a cwd below the directory. Trying to remove a directory
> which is the CWD of some process is the most common reason that the
> directory is blocked, because the Win32 CWD is opened without the
> FILE_SHARE_DELETE flag. Especially something like `rm -rf ../f
24 matches
Mail list logo
