Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r
On Tue, 4 Jun 2019 22:04:16, Vince Rice wrote: > It's cygport, he doesn't have to know about compiling C. ... Vince, this utter nonsense, and you know it! Henri -- 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: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r
On Tue, 4 Jun 2019 22:04:16, Vince Rice wrote: It's cygport, he doesn't have to know about compiling C. He has to know about running a one-line cygport command. This just seems purposefully ignorant. How exactly is he suppose to modify the C source to address the problem and recompile, if he doesnt know anything about compiling C? You offered the user nothing, and berated Brian for offering help. The only nonsense on offer here is from you. And the only one off-putting in this conversation is you. Oh really? Is that why OP agreed with me?: Anyway, Steven you are right compiling a package like OpenSSL is not straightforward even with Cygport but still feasable with reasonnable efforts (I guess because I'm used to have unsual setup where automatic tool does not work out of the box :) ) https://cygwin.com/ml/cygwin/2019-06/msg00026.html Read the thread dude and stop trolling. -- 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: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r
> On Jun 4, 2019, at 5:55 PM, Steven Penny wrote: > > Easy compared to what, assembly? Easy compared to hard. > He shows some domain knowledge of OpenSSL, but where are you getting that he > knows about compiling C? It's cygport, he doesn't have to know about compiling C. He has to know about running a one-line cygport command. >> Please refrain from your own inappropriate assumptions and meta-commentary >> based on that, as this is not a social media platform. > > No, but it is a public forum. and I will call out nonsense if I see it. As > your > type of comments are off putting to new users. Brian offered the user help. Brian is one of the most helpful people on this list. You offered the user nothing, and berated Brian for offering help. The only nonsense on offer here is from you. And the only one off-putting in this conversation is you. -- 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: [ANNOUNCEMENT] Test: cmake-3.13.1-1
See below what I said in both January and November the last times we had any
conversation on this. cmake_minimum_required, project_injected, and CommandLine
test failures are new and I'd personally come to a definitive thoroughly
researched conclusion on what's causing them before making a release. But I
don't intend on making any releases of cygwin packages any time soon, so you
can do whatever you want here.
top-posting because these conversations were off list:
Right, if the logs aren't super useful for debugging, then the next step I'd do
is what I said in November:
> What happens if you run the steps those tests are trying to execute on their
> own, not under ctest? Or try to run the unit tests with an existing older
> separate copy of ctest instead of the just-built copy?
The Qt*Autogen failures were pre-existing and I've identified the cause in past
versions, I should have made a note of it in writing somewhere more permanent
though. The build system there isn't handling dll dependencies of the test
executables quite correctly for cygwin. That's definitely a bug in how the test
is written and could eventually be resolved with a cygwin-specific patch to
those cmake tests by whoever ever has the time to work through it. The new ones
are what I was referring to and could be indicative of real problems. It's
possible some of them are due to missing dll issues like the Qt*Autogen
failures but that would surprise me a little. Running the executables manually
or outside of cygwin/ctest can sometimes give more useful output on problems
like that (from windows popups, etc).
From: Marco Atzeri
Sent: Thursday, January 10, 2019 5:49 AM
To: Tony Kelman; Ivan Shynkarenka
Subject: Re: refreshing cmake
Am 1/9/2019 um 7:28 AM schrieb Tony Kelman:
> I still think the test failures should be looked into and debugged,
> personally.
Tony,
to me it seems a case of best is enemy of good.
I look at the test log and I do not see what is the problem
so I am not able to debug.
Do you have some guidance ?
-
Start 359: RunCMake.cmake_minimum_required
359/561 Test #359: RunCMake.cmake_minimum_required
..***Failed
$ find . -name CMakeOutput.log -exec cat {} \;
The system is: CYGWIN - 2.11.2(0.329/5/3) - x86_64
The system is: CYGWIN - 2.11.2(0.329/5/3) - x86_64
The system is: CYGWIN - 2.11.2(0.329/5/3) - x86_64
The system is: CYGWIN - 2.11.2(0.329/5/3) - x86_64
The system is: CYGWIN - 2.11.2(0.329/5/3) - x86_64
The system is: CYGWIN - 2.11.2(0.329/5/3) - x86_64
The system is: CYGWIN - 2.11.2(0.329/5/3) - x86_64
there is nothing more.
---
Start 391: RunCMake.project_injected
391/561 Test #391: RunCMake.project_injected
***Failed
the single log is very long but I do not see a single error.
Start 422: RunCMake.CommandLine
422/561 Test #422: RunCMake.CommandLine
.***Failed
the single log is very long but I do not see a single error.
Start 454: Qt5Autogen.Complex
454/561 Test #454: Qt5Autogen.Complex
...***Failed
the single log shows no error.
There is just an isolated warning
all the targets seem built
$ find . -name "*.a" -or -name "*.dll" -or -name "*.exe"
./Adir/cyglibA.dll
./Adir/liblibA.dll.a
./Bdir/cyglibB.dll
./Bdir/liblibB.dll.a
./CMakeFiles/3.13.1/CompilerIdC/a.exe
./CMakeFiles/3.13.1/CompilerIdCXX/a.exe
./cyglibC.dll
./libcodeeditorLib.a
./liblibC.dll.a
./QtAutogen.exe
./targetObjectsTest.exe
$ PATH=$(PWD)/Adir:$(PWD)/Bdir:$PATH ./QtAutogen
Hello automoc: 12
Blub blub 13 !
Hello bar !
abc
I am private abc !
This is xyz !
I am yet another file !
just ./targetObjectsTest.exe produces no output at all
so I have no clue of what is supposed to do.
--
Start 487: Qt4Autogen.Complex
487/561 Test #487: Qt4Autogen.Complex
...***Failed
same a QT5
--
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: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r
On Tue, 4 Jun 2019 09:25:48, Brian Inglis wrote:
I am encouraging and offering the poster a way to solve their problem, after
providing some possible reasons for dropping support from some ECs.
Rebuilding a Cygwin package from source using cygport is a relatively easy
task.
Easy compared to what, assembly? I am comfortable with 3 programming languages,
and learning 4 others, and compiling C is not "relatively easy". Especially
considering the scope:
$ cd openssl-master
$ find -name '*.c' -exec wc -l {} + | tail -1
419738 total
400,000 lines of C.
I am not presuming, but assuming some amount of technical expertise, based on
a poster asking about openssl configuration and which ECs they want to
support. If they need more help they can ask in a follow up.
reread the post:
https://cygwin.com/ml/cygwin/2019-06/msg00012.html
He shows some domain knowledge of OpenSSL, but where are you getting that he
knows about compiling C? A conservative read would reveal that he might have no
knowledge of compiling C, and you want him to compile 400,000 lines of C because
its "easy".
Please refrain from your own inappropriate assumptions and meta-commentary
based on that, as this is not a social media platform.
No, but it is a public forum. and I will call out nonsense if I see it. As your
type of comments are off putting to new users.
Why would you assume the poster is a novice? Before commenting, please try
yourself to consider multiple perspectives on posts and replies?
As should you.
--
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: Trying to create default ACL entries to match file ACL entries
On 2019-06-04 15:34, Chris Wagner wrote: > / is just a mount to something like C:\Cygwin64 so there is no problem > in changing it. > You should delete all the target thing's permissions first to guarantee > starting > from a clean slate. > $ setfacl -kb z2/ && getfacl z1/ |setfacl -f - z2/ > This works for me with the latest packages. Watch out for valid DACLs if you want to be able to create files in any subdirectory from Windows programs or access them after creation: thar be grumblins! -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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: Trying to create default ACL entries to match file ACL entries
On 2019/06/04 14:26, Brian Inglis wrote: > On 2019-06-04 13:59, L A Walsh wrote: > >> lets see if this is more clear: >> On 2019/06/04 12:44, Eliot Moss wrote: >> >>> On 6/4/2019 3:34 PM, L A Walsh wrote: >>> I am trying to create an entry for '/' (or '.' w/me sitting in '/') where the default entries are the same as the file entries. ^^^ so tried doing: getfacl . | setfacl -d - . >> Sorry, but am trying to get the 'file' entries (w/o the -d) >> copied into the default. >> > > Not seeing -d, --default documented or supported in the code as an option flag > under Cygwin: it is available under Debian/Ubuntu at least, and probably other > Linux; Not to confuse things, but its under getfacl. silly me, thinking setfacl might have the same flag very confusing... So need to getfacl to get access perms, then turn them into a form for default acl... Sigh... -- 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: Trying to create default ACL entries to match file ACL entries
Hi Linda, / is just a mount to something like C:\Cygwin64 so there is no problem in changing it. You should delete all the target thing's permissions first to guarantee starting from a clean slate. $ setfacl -kb z2/ && getfacl z1/ |setfacl -f - z2/ This works for me with the latest packages. HTH, Chris -- 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: Trying to create default ACL entries to match file ACL entries
On 2019-06-04 13:59, L A Walsh wrote: > lets see if this is more clear: > On 2019/06/04 12:44, Eliot Moss wrote: >> On 6/4/2019 3:34 PM, L A Walsh wrote: >>> I am trying to create an entry for '/' (or '.' w/me sitting in '/') >>> where the default entries are the same as the file entries. >>> ^^^ >>> so tried doing: >>>getfacl . | setfacl -d - . > Sorry, but am trying to get the 'file' entries (w/o the -d) > copied into the default. Not seeing -d, --default documented or supported in the code as an option flag under Cygwin: it is available under Debian/Ubuntu at least, and probably other Linux; neither are the file input option flags -M, --modify-file, -X, --remove-file, or symbolic link -L, --logical, -P, --physical, or -R, --recursive option flags. Cygwin equivalent based on setfacl(1) would be something like: $ getfacl -a source_file | sed 's/.*/&\nd:&/' | setfacl -f - target_file where you are getting and duplicating the file accesses and also creating the DACLs. > On 2019/06/04 12:44, Eliot Moss wrote: >> O ... not sure _I'd_ mess what / on a Windows system! > - > Ya, not idea, but too late for that. Thanks for your > vote of confidence though! :wa: :-( I have had success using only setfacl -m and specifying everything I want changed or set in that argument e.g. $ setfacl -m u::rwx,g::r-x,o::r-x,d:u::rwx,d:g::r-x,d:o::r-x / probably using an admin account running with elevated permissions in this case. For Cygwin root /, I have only: $ lsp / | cygcheck-hrsv.sed drwxr-xr-x+ 1 $USER Administrators 0 May 31 05:19 / # file: / # owner: $USER # group: Administrators user::rwx group::r-x other::r-x default:user::rwx default:group::r-x default:other::r-x C:/.../cygwin64 $HOSTNAME\$USER:(F) BUILTIN\Administrators:(RX) Everyone:(RX) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) Successfully processed 1 files; Failed processing 0 files -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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: Trying to create default ACL entries to match file ACL entries
lets see if this is more clear: On 2019/06/04 12:44, Eliot Moss wrote: > On 6/4/2019 3:34 PM, L A Walsh wrote: > >> I am trying to create an entry for '/' (or '.' w/me sitting in '/') >> where the default entries are the same as the file entries. >> ^^^ >> >> so tried doing: >> >>getfacl . | setfacl -d - . >> Sorry, but am trying to get the 'file' entries (w/o the -d) copied into the default. On 2019/06/04 12:44, Eliot Moss wrote: > O ... not sure _I'd_ mess what / on a Windows system! > - Ya, not idea, but too late for that. Thanks for your vote of confidence though! :wa: :-( -- 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: Trying to create default ACL entries to match file ACL entries
On 6/4/2019 3:34 PM, L A Walsh wrote: I am trying to create an entry for '/' (or '.' w/me sitting in '/') where the default entries are the same as the file entries. O ... not sure _I'd_ mess what / on a Windows system! I noticed the example give in the manpage for copying entries: The special filename "-" indicates reading from stdin. Note that you can use this with getfacl and setfacl to copy ACLs from one file to another: $ getfacl source_file | setfacl -f - target_file so tried doing: getfacl . | setfacl -d - . I have no problem doing: mkdir temp getfacl . | setfacl -f - temp getfacl temp | setfacl -f . getfacl / | setfacl -f . I didn't want to try setting things on /, but you might: cd / mkdir foo getfacl foo | setfacl -f - . But I am not sure what foo would have as its permission, i.e., whether they are what you want. Regards - EM -- 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
Trying to create default ACL entries to match file ACL entries
I am trying to create an entry for '/' (or '.' w/me sitting in '/') where the default entries are the same as the file entries. I noticed the example give in the manpage for copying entries: The special filename "-" indicates reading from stdin. Note that you can use this with getfacl and setfacl to copy ACLs from one file to another: $ getfacl source_file | setfacl -f - target_file so tried doing: getfacl . | setfacl -d - . But keep running into: setfacl: missing entries. Also tried writing to a file and modifying that. Last try had: # file: . # owner: Bliss\law # group: Bliss\lawgroup default:user:Bliss\law:rwx default:group:SYSTEM:rwx default:group:Bliss\lawgroup:rwx default:group:Bliss\Domain Admins:rwx default:group:Bliss\Domain Users:r-x default:group:Administrators:rwx default:other::r-x mask::rwx user::rwx group::rwx other::r-x But still with: /> setfacl -f /tmp/norm . got: setfacl: missing entries. Using it with '-d' just gave illegal acl entries, so that didn't work either. What am I missing? Thanks! -linda -- 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: Download setup-x86_64 issue
On 6/4/2019 8:09 PM, Eliot Moss wrote:
> On 6/4/2019 2:00 PM, john doe wrote:
>> Hi, I'm trying to download the setup file to update cygwin using
>> powershell but it fails miserably:
>>
>> PS > (new-object system.net.webclient).do
>> wnloadfile("https://www.cygwin.com/setup-x86_64.exe;, "$PWD/try.exe")
>> Exception calling "DownloadFile" with "2" argument(s): "The underlying
>> connecti
>> on was closed: An unexpected error occurred on a send."
>> At line:1 char:47
>> + (new-object system.net.webclient).downloadfile
>> ("https://www.cygwin.com/
>> setup-x86_64.exe", "$PWD/try.exe")
>> + CategoryInfo : NotSpecified: (:) [],
>> MethodInvocationException
>> + FullyQualifiedErrorId : DotNetMethodException
>>
>>
>> It works for other URLs and would appriciate any input on the above.
>
> I just download with a web browser. Any reason you have
> to do this programmatically instead? Also, I know little
> about PS, but it could be that it just doesn't approve of
> this as a Microsoft-blessed kind of thing. When I invoke
> setup, I get popups about this not being from the Windows
> Store, etc. -- simply plow on.
>
Yes, I'm using Powershell to update Cygwin through a script and the
script fails at the download step.
> Also, a web search suggests that wget to PowerShell is
> also fine.
>
I meant Cygwin's wget, the idea is to not require any extra tool(s) to
update Cygwin, sorry about that.
> And here's another tidbit from the web:
>
> powershell -NoProfile -ExecutionPolicy unrestricted -Command (new-object
> System.Net.WebClient).Downloadfile('http://10.10.10.10:7000/iw4455.exe',
> 'C:\windows\temp\iw4455.exe')
>
> Perhaps the ExecutionPolicy thing is relevant here?
>
No -- se above, thanks anyway.
> Anyway, this question does not seem to be cygwin-specific, but
> more about PS ...
Everything was working a fiew days ago, and now, it isn't.
Thanks for your input.
--
John Doe
--
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: Download setup-x86_64 issue
On 6/4/2019 2:00 PM, john doe wrote:
Hi, I'm trying to download the setup file to update cygwin using
powershell but it fails miserably:
PS > (new-object system.net.webclient).do
wnloadfile("https://www.cygwin.com/setup-x86_64.exe;, "$PWD/try.exe")
Exception calling "DownloadFile" with "2" argument(s): "The underlying
connecti
on was closed: An unexpected error occurred on a send."
At line:1 char:47
+ (new-object system.net.webclient).downloadfile
("https://www.cygwin.com/
setup-x86_64.exe", "$PWD/try.exe")
+ CategoryInfo : NotSpecified: (:) [],
MethodInvocationException
+ FullyQualifiedErrorId : DotNetMethodException
It works for other URLs and would appriciate any input on the above.
I just download with a web browser. Any reason you have
to do this programmatically instead? Also, I know little
about PS, but it could be that it just doesn't approve of
this as a Microsoft-blessed kind of thing. When I invoke
setup, I get popups about this not being from the Windows
Store, etc. -- simply plow on.
Also, a web search suggests that wget to PowerShell is
also fine.
And here's another tidbit from the web:
powershell -NoProfile -ExecutionPolicy unrestricted -Command (new-object
System.Net.WebClient).Downloadfile('http://10.10.10.10:7000/iw4455.exe', 'C:\windows\temp\iw4455.exe')
Perhaps the ExecutionPolicy thing is relevant here?
Anyway, this question does not seem to be cygwin-specific, but
more about PS ...
Best wishes - EM
--
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
Download setup-x86_64 issue
Hi, I'm trying to download the setup file to update cygwin using
powershell but it fails miserably:
PS > (new-object system.net.webclient).do
wnloadfile("https://www.cygwin.com/setup-x86_64.exe;, "$PWD/try.exe")
Exception calling "DownloadFile" with "2" argument(s): "The underlying
connecti
on was closed: An unexpected error occurred on a send."
At line:1 char:47
+ (new-object system.net.webclient).downloadfile
("https://www.cygwin.com/
setup-x86_64.exe", "$PWD/try.exe")
+ CategoryInfo : NotSpecified: (:) [],
MethodInvocationException
+ FullyQualifiedErrorId : DotNetMethodException
It works for other URLs and would appriciate any input on the above.
P.S.
Using Wget on this w7works.
--
John Doe
--
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: [PATCH] mkdir: always check-for-existence
Hi Corinna,
Please see the attachment for my patch.
My MUA indeed replaced the tabs with spaces.
I did notice that the indentation was mixed tabs and spaces,
but as stated on the website I have kept the surrounding indentation.
Ben...
On 04-06-2019 09:41, Corinna Vinschen wrote:
Hi Ben,
On Jun 3 22:07, Ben wrote:
When creating a directory which already exists, NtCreateFile will correctly
return 'STATUS_OBJECT_NAME_COLLISION'.
However when creating a directory and all its parents a normal use would
be to start with mkdir(‘/cygdrive/c’) which translates to ‘C:\’ for which
it'll
instead return ‘STATUS_ACCESS_DENIED’.
So we better check for existence prior to calling NtCreateFile.
---
winsup/cygwin/dir.cc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc
index f43eae461..b757851d5 100644
--- a/winsup/cygwin/dir.cc
+++ b/winsup/cygwin/dir.cc
@@ -331,8 +331,10 @@ mkdir (const char *dir, mode_t mode)
debug_printf ("got %d error from build_fh_name", fh->error ());
set_errno (fh->error ());
}
+ else if (fh->exists ())
+ set_errno (EEXIST);
else if (has_dot_last_component (dir, true))
- set_errno (fh->exists () ? EEXIST : ENOENT);
+ set_errno (ENOENT);
else if (!fh->mkdir (mode))
res = 0;
delete fh;
--
2.21.0
I was just trying to apply your patch but it fails to apply cleanly.
Can you please check your indentation? The `else' lines are indented
more than the lines in between and TABs are missing.
Maybe your MUA breaks the output? If all else fails, you could attach
your patch as plain/text attachement to your mail, usually that's left
alone by the MUA.
Thanks,
Corinna
>From 190b5bc9497a1332ce53afd831debe1ac3e53ffb Mon Sep 17 00:00:00 2001
From: Ben Wijen
Date: Mon, 3 Jun 2019 20:15:50 +0200
Subject: [PATCH] mkdir: always check-for-existence
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
When using NtCreateFile when creating a directory that already exists,
it will correctly return 'STATUS_OBJECT_NAME_COLLISION'.
However using this function to create a directory (and all its parents)
a normal use would be to start with mkdir(â/cygdrive/câ) which translates
to âC:\â for which it'll instead return âSTATUS_ACCESS_DENIEDâ.
---
winsup/cygwin/dir.cc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc
index f43eae461..b757851d5 100644
--- a/winsup/cygwin/dir.cc
+++ b/winsup/cygwin/dir.cc
@@ -331,8 +331,10 @@ mkdir (const char *dir, mode_t mode)
debug_printf ("got %d error from build_fh_name", fh->error ());
set_errno (fh->error ());
}
+ else if (fh->exists ())
+ set_errno (EEXIST);
else if (has_dot_last_component (dir, true))
- set_errno (fh->exists () ? EEXIST : ENOENT);
+ set_errno (ENOENT);
else if (!fh->mkdir (mode))
res = 0;
delete fh;
--
2.21.0
Re: possible problem with memory allocation using calloc/mmap/munmap
> > > > > > It seems that when mmap() is called with length argument exceeding > > > > > > size of file, only memory to fit that file is allocated. munmap() > > > > > > however frees the full specified length. [...] > > > > > [...] > > > > > I know this situation is unsatisfying, but I have no easy workaround > > > > > to allow this. Cygwin could add the anonymous mapping on the next > > > > > 64K boundary on 64 bit, but that would result in a hole in the mapping > > > > > which seemed like a rather bad idea when porting mmap to 64 bit. > > > > > > > > > > Ken's also right that munmap is doing the right thing here. If > > > > > anything's wrong, it's mmap's workaround for mappings beyond the file > > > > > length. If only 64 bit would allow 4K-aligned mappings :( > > > > > > > > Thanks for the answer. It is appreciated. > > > > I understand the problem and difficulty to resolve it. Maybe returning > > > > an error from mmap (and putting a comment to code for its reason) > > > > would be sufficient. mmap caller could just adjust requested > > > > allocation size to file size. Without error, caller has no way of > > > > knowing memory was not allocated and segfault is then thrown in an > > > > unrelated memory segment which makes the root cause hard to track > > > > down. But, I do not know all the implication that could result from > > > > that, so evaluation of this approach is up to you. > > > [...] > > > Eventually Cygwin adds another mapping to fullfill the entire mapping > > > request: > > > > > > |-- file 4K --|-- filler 60K --|-- filler 192K --| > > > > > > The problem on WOW64 and real 64 bit is that it's impossible to map > > > the first filler. However, this area in the VM will *never* be > > > allocated by other application functions due to the allocation > > > granularity of 64K! > > > > > > So my workaround for 64 bit and WOW64 is to just skip allocating the > > > first filler: > > > > > > |-- file 4K --|-- THE VOID 60K --|-- filler 192K --| > > > > > > The advantage is now that the following munmap of 256K will only > > > unmap the map for the file and the filler, but not the region you > > > calloced before, which formerly was accidentally mapped to the > > > filler region. This just can't happen anymore now. > > > > > > Would that be feasible? If so I can push my patch and create a > > > developer snapshot for testing. > > > > Two questions arise when I'm thinking about workaround solution: > > - what happens if caller tries to write to |-- THE VOID 60K --|. Since > > this is unallocated, would there be a segfault? > > Accessing the VOID would raise SIGSEGV, while accessing the filler > raises SIGBUS. The latter is also used to implement MAP_NORESERVE, > which the VOID can't support. I played around a bit and I can confirm it would be consistent with current behavior: memwrite <0 - filesize) - no error, written to file memwrite > > - is it possible that some subsequent mem alloc request would return > > region from |-- THE VOID 60K --| which could again cause segfault > > after munmap? > > No, as stated above. Allocations are restricted to Windows' 64K > allocation granularity. I apologize. I missed that sentence. So, your workaround seems fine. -- 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
[newlib-cygwin] cygcheck: expand common_apps list
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=5c2a3661c1aeefb0591ce46e8ab3274f0c6d9112
commit 5c2a3661c1aeefb0591ce46e8ab3274f0c6d9112
Author: Yaakov Selkowitz
Date: Thu May 23 11:47:36 2019 -0400
cygcheck: expand common_apps list
An increasing number of tools are being included in Windows which have the
same names as those included in Cygwin packages. Indicating which one is
first in PATH can be helpful in diagnosing behavioural discrepencies
between them.
Also, fix the alphabetization of ssh.
Diff:
---
winsup/utils/cygcheck.cc | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/winsup/utils/cygcheck.cc b/winsup/utils/cygcheck.cc
index d5972c0..2cc25d9 100644
--- a/winsup/utils/cygcheck.cc
+++ b/winsup/utils/cygcheck.cc
@@ -99,28 +99,43 @@ static common_apps[] = {
{"awk", 0},
{"bash", 0},
{"cat", 0},
+ {"certutil", 0},
+ {"clinfo", 0},
+ {"comp", 0},
+ {"convert", 0},
{"cp", 0},
{"cpp", 1},
{"crontab", 0},
+ {"curl", 0},
+ {"expand", 0},
{"find", 0},
+ {"ftp", 0},
{"gcc", 0},
{"gdb", 0},
{"grep", 0},
+ {"hostname", 0},
{"kill", 0},
+ {"klist", 0},
{"ld", 0},
{"ls", 0},
{"make", 0},
{"mv", 0},
+ {"nslookup", 0},
{"patch", 0},
{"perl", 0},
+ {"replace", 0},
{"rm", 0},
{"sed", 0},
- {"ssh", 0},
{"sh", 0},
+ {"shutdown", 0},
+ {"sort", 0},
+ {"ssh", 0},
{"tar", 0},
{"test", 0},
+ {"timeout", 0},
{"vi", 0},
{"vim", 0},
+ {"whoami", 0},
{0, 0}
};
Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r
On 2019-06-03 16:36, Steven Penny wrote: > On Mon, 3 Jun 2019 14:35:29, Brian Inglis wrote: >> You can easily rebuild the package yourself with the cygport utility, to >> check >> that works, then change the build config to include the Brainpool ECs, and >> rebuild the way you want it. > > Please do not presume someones technical prowess. It might be easy *to you*, > but > its certainly not easy in an objective sense, and definitely not to a novice > Cygwin user. > > This is coming from someone who has built hundreds of Cygwin and Mingw64 > packages. Have some perspective. I am encouraging and offering the poster a way to solve their problem, after providing some possible reasons for dropping support from some ECs. Rebuilding a Cygwin package from source using cygport is a relatively easy task. I am not presuming, but assuming some amount of technical expertise, based on a poster asking about openssl configuration and which ECs they want to support. If they need more help they can ask in a follow up. Please refrain from your own inappropriate assumptions and meta-commentary based on that, as this is not a social media platform. Why would you assume the poster is a novice? Before commenting, please try yourself to consider multiple perspectives on posts and replies? "There are more things in heaven and Earth, Horatio, Than are dreamt of in your philosophy." Hamlet: Shakespeare -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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
[newlib-cygwin] Cygwin: Allow accessing 48 bit address space in Windows 8.1 or later
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=e1254add73b1fb834933b38a5163d72c30c2330b
commit e1254add73b1fb834933b38a5163d72c30c2330b
Author: Corinna Vinschen
Date: Tue Jun 4 16:58:53 2019 +0200
Cygwin: Allow accessing 48 bit address space in Windows 8.1 or later
64 bit Windows started out with a 44 bit address space due to a
restriction of the AMD64 CPUs at the time. Starting with Windows
8.1, these CPUs are not supported anymore and Windows switched to
the full 48 bit address space supported by AMD64.
Cygwin didn't follow suit yet so mmaps are still restricted to
the lower 44 bit address space. Fix that by using a system-specific
upper address for mmap allocations, 44 bit up to Windows 8, 48 bit
starting with Windows 8.1.
While at it, move the heap by another 8 Gigs to leave some space
for a potential extension of DLL address space, and restrict the
mmap lower address so the heap can grow to 32 Gigs before colliding
with mmaps.
Diff:
---
winsup/cygwin/heap.cc | 6 +++---
winsup/cygwin/mmap.cc | 6 --
winsup/cygwin/wincap.cc | 9 +
winsup/cygwin/wincap.h | 4
4 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/winsup/cygwin/heap.cc b/winsup/cygwin/heap.cc
index e18cd55..b839c8c 100644
--- a/winsup/cygwin/heap.cc
+++ b/winsup/cygwin/heap.cc
@@ -34,9 +34,9 @@ eval_start_address ()
executable starts at 0x1:0040L, the Cygwin DLL starts at
0x1:8004L, other rebased DLLs are located in the region from
0x2:L up to 0x4:L, -auto-image-based DLLs are located
- in the region from 0x4:L up to 0x6:L.
- So we let the heap start at 0x6:L. */
- uintptr_t start_address = 0x6L;
+ in the region from 0x4:L up to 0x6:L. Leave another
+ 8 Gigs slack space, so lets start the heap at 0x8:L. */
+ uintptr_t start_address = 0x8L;
#else
/* Windows performs heap ASLR. This spoils the entire region below
0x2000 for us, because that region is used by Windows to randomize
diff --git a/winsup/cygwin/mmap.cc b/winsup/cygwin/mmap.cc
index 9eb1643..8b1aedc 100644
--- a/winsup/cygwin/mmap.cc
+++ b/winsup/cygwin/mmap.cc
@@ -801,8 +801,10 @@ mmap_worker (mmap_list *map_list, fhandler_base *fh,
caddr_t base, size_t len,
#ifdef __x86_64__
/* The memory region used for memory maps */
-#define MMAP_STORAGE_LOW 0x008L /* Leave 8 Gigs for heap. */
-#define MMAP_STORAGE_HIGH 0x700L /* Leave enough room for OS. */
+#define MMAP_STORAGE_LOW 0x0010L /* Leave 32 Gigs for heap. */
+/* Up to Win 8 only supporting 44 bit address space, starting with Win 8.1
+ 48 bit address space. */
+#define MMAP_STORAGE_HIGH wincap.mmap_storage_high ()
/* FIXME? Unfortunately the OS doesn't support a top down allocation with
a ceiling value. The ZeroBits mechanism only works for
diff --git a/winsup/cygwin/wincap.cc b/winsup/cygwin/wincap.cc
index 17e0cf1..5c6e642 100644
--- a/winsup/cygwin/wincap.cc
+++ b/winsup/cygwin/wincap.cc
@@ -20,6 +20,7 @@ details. */
wincaps wincap_vista __attribute__((section (".cygwin_dll_common"), shared)) =
{
def_guard_pages:1,
+ mmap_storage_high:0x0700LL,
{
is_server:false,
needs_count_in_si_lpres2:true,
@@ -46,6 +47,7 @@ wincaps wincap_vista __attribute__((section
(".cygwin_dll_common"), shared)) = {
wincaps wincap_7 __attribute__((section (".cygwin_dll_common"), shared)) = {
def_guard_pages:1,
+ mmap_storage_high:0x0700LL,
{
is_server:false,
needs_count_in_si_lpres2:false,
@@ -72,6 +74,7 @@ wincaps wincap_7 __attribute__((section
(".cygwin_dll_common"), shared)) = {
wincaps wincap_8 __attribute__((section (".cygwin_dll_common"), shared)) = {
def_guard_pages:2,
+ mmap_storage_high:0x0700LL,
{
is_server:false,
needs_count_in_si_lpres2:false,
@@ -98,6 +101,7 @@ wincaps wincap_8 __attribute__((section
(".cygwin_dll_common"), shared)) = {
wincaps wincap_8_1 __attribute__((section (".cygwin_dll_common"), shared)) = {
def_guard_pages:2,
+ mmap_storage_high:0x7000LL,
{
is_server:false,
needs_count_in_si_lpres2:false,
@@ -124,6 +128,7 @@ wincaps wincap_8_1 __attribute__((section
(".cygwin_dll_common"), shared)) = {
wincaps wincap_10_1507 __attribute__((section (".cygwin_dll_common"),
shared)) = {
def_guard_pages:2,
+ mmap_storage_high:0x7000LL,
{
is_server:false,
needs_count_in_si_lpres2:false,
@@ -150,6 +155,7 @@ wincaps wincap_10_1507 __attribute__((section
(".cygwin_dll_common"), shared))
wincaps wincap_10_1703 __attribute__((section (".cygwin_dll_common"), shared))
= {
def_guard_pages:2,
+ mmap_storage_high:0x7000LL,
{
is_server:false,
needs_count_in_si_lpres2:false,
@@ -176,6 +182,7 @@ wincaps wincap_10_1703 __attribute__((section
Re: possible problem with memory allocation using calloc/mmap/munmap
On Jun 4 15:48, Stanislav Kascak wrote: > > > > > It seems that when mmap() is called with length argument exceeding > > > > > size of file, only memory to fit that file is allocated. munmap() > > > > > however frees the full specified length. [...] > > > > [...] > > > > I know this situation is unsatisfying, but I have no easy workaround > > > > to allow this. Cygwin could add the anonymous mapping on the next > > > > 64K boundary on 64 bit, but that would result in a hole in the mapping > > > > which seemed like a rather bad idea when porting mmap to 64 bit. > > > > > > > > Ken's also right that munmap is doing the right thing here. If > > > > anything's wrong, it's mmap's workaround for mappings beyond the file > > > > length. If only 64 bit would allow 4K-aligned mappings :( > > > > > > Thanks for the answer. It is appreciated. > > > I understand the problem and difficulty to resolve it. Maybe returning > > > an error from mmap (and putting a comment to code for its reason) > > > would be sufficient. mmap caller could just adjust requested > > > allocation size to file size. Without error, caller has no way of > > > knowing memory was not allocated and segfault is then thrown in an > > > unrelated memory segment which makes the root cause hard to track > > > down. But, I do not know all the implication that could result from > > > that, so evaluation of this approach is up to you. > > [...] > > Eventually Cygwin adds another mapping to fullfill the entire mapping > > request: > > > > |-- file 4K --|-- filler 60K --|-- filler 192K --| > > > > The problem on WOW64 and real 64 bit is that it's impossible to map > > the first filler. However, this area in the VM will *never* be > > allocated by other application functions due to the allocation > > granularity of 64K! > > > > So my workaround for 64 bit and WOW64 is to just skip allocating the > > first filler: > > > > |-- file 4K --|-- THE VOID 60K --|-- filler 192K --| > > > > The advantage is now that the following munmap of 256K will only > > unmap the map for the file and the filler, but not the region you > > calloced before, which formerly was accidentally mapped to the > > filler region. This just can't happen anymore now. > > > > Would that be feasible? If so I can push my patch and create a > > developer snapshot for testing. > > Two questions arise when I'm thinking about workaround solution: > - what happens if caller tries to write to |-- THE VOID 60K --|. Since > this is unallocated, would there be a segfault? Accessing the VOID would raise SIGSEGV, while accessing the filler raises SIGBUS. The latter is also used to implement MAP_NORESERVE, which the VOID can't support. > - is it possible that some subsequent mem alloc request would return > region from |-- THE VOID 60K --| which could again cause segfault > after munmap? No, as stated above. Allocations are restricted to Windows' 64K allocation granularity. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: Question regarding OpenSSL 1.1.1b package configuration against OpenSSL 1.0.2r
Hi Guys, Thanks for your feedback. I have recompile the openssl package with Cygport and this has allowed me to point out the differences between the OpenSSL mainline and the Cygwin pacakge. Actually the Cygwin package follow the spec from Fedora package where it has been decided to remove some patented algorithms. After some readings on wikipedia, the implementation of the Brainpool curves may requires patented method to be as efficient as NIST curves. (https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Implementation) I don't know if OpenSSL use such optimization algorithm but I find out that we can use the Brainpool curves by providing the ECC parameters to OpenSSL 1.1.1b Fedora version. (https://bitnuts.de/articles/using_brainpool_ecc_in_openssl.html) Therefore the patch will remove builtin support of RFC defined Brainpool curves (and others) and keep only NIST which are optimized remove only the named curves but not the algorithms behind. I'm not legal person therefore I can't tell if this is really make any difference but I think the algorithm is still embedded in the OpenSSL package. I think that the default ECC implementation is not optimized of all curves except for NIST curves. May be this needs to be check with OpenSSL team ? Anyway, Steven you are right compiling a package like OpenSSL is not straightforward even with Cygport but still feasable with reasonnable efforts (I guess because I'm used to have unsual setup where automatic tool does not work out of the box :) ) Regarding the CVE-2016-7055 pointed by Brian, as far as I have read this is impacting only the Brainpool P 512 curve and this is not compromizing the private key and I think we could restrict the restriction to this curves only. (https://nvd.nist.gov/vuln/detail/CVE-2016-7055) Best Regards, Ben Le mar. 4 juin 2019 à 00:36, Steven Penny a écrit : > > On Mon, 3 Jun 2019 14:35:29, Brian Inglis wrote: > > You can easily rebuild the package yourself with the cygport utility, to > > check > > that works, then change the build config to include the Brainpool ECs, and > > rebuild the way you want it. > > Please do not presume someones technical prowess. It might be easy *to you*, > but > its certainly not easy in an objective sense, and definitely not to a novice > Cygwin user. > > This is coming from someone who has built hundreds of Cygwin and Mingw64 > packages. Have some perspective. > > > -- > 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 > -- 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: Are archived lists downloadable?
On Fri, May 10, 2019 at 4:43 AM Henning wrote: > > Is there a possibility to download compressed archives of cygwin mailing > lists for offline searching and reading? I vaguely recall a script to traverse the tree and download any messages that were not already present in a local copy, but it was so long ago I don't even recall if it was written with wget or curl anymore. I do not recall any way to simply download them as an already compressed archive. -- Erik -- "I do not think any of us are truly sane, Caleb. Not even you. Courage is not sanity. Being willing to die for someone else is not sanity." ... "Love is not sane, nor is faith." ... "If sanity lacks those things, Caleb, I want no part of it." -- Alexandria Terri in "Weaving the Wyvern" by Alexis Desiree Thorne -- 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: possible problem with memory allocation using calloc/mmap/munmap
> > > > It seems that when mmap() is called with length argument exceeding > > > > size of file, only memory to fit that file is allocated. munmap() > > > > however frees the full specified length. Since (at least on my > > > > computer) big chunk of memory allocated by calloc() is located after > > > > mmap() allocation, munmap() frees even memory of that calloc(). > > > > > > Ken's right. Due to the differences between mapping files on Windows > > > vs. Unix, Cygwin can't map beyond the file size + the remainder of the > > > last page. Cygwin tries to workaround that on 32 bit by allocating > > > an anonymous mapping following the file mapping to keep the range free > > > from other mappings. But on 64 bit this workaround doesn't work anymore > > > because the OS is missing an (undocumented) flag which allows to > > > create mappings on 4K boundaries, rather than just on 64K boundaries. > > > > > > I know this situation is unsatisfying, but I have no easy workaround > > > to allow this. Cygwin could add the anonymous mapping on the next > > > 64K boundary on 64 bit, but that would result in a hole in the mapping > > > which seemed like a rather bad idea when porting mmap to 64 bit. > > > > > > Ken's also right that munmap is doing the right thing here. If > > > anything's wrong, it's mmap's workaround for mappings beyond the file > > > length. If only 64 bit would allow 4K-aligned mappings :( > > > > Thanks for the answer. It is appreciated. > > I understand the problem and difficulty to resolve it. Maybe returning > > an error from mmap (and putting a comment to code for its reason) > > would be sufficient. mmap caller could just adjust requested > > allocation size to file size. Without error, caller has no way of > > knowing memory was not allocated and segfault is then thrown in an > > unrelated memory segment which makes the root cause hard to track > > down. But, I do not know all the implication that could result from > > that, so evaluation of this approach is up to you. > > Given that most of the required code already exists for 32 bit systems > (except under WOW64, suffering the same problem as the 64 bit WIndows > environment), I hacked a bit on this code this morning and I got your > testcase running fine. The idea being that after a successful mmap the > expectation that a matching munmap does *not* unmap unrelated mappings > is valid. > > In more depth, here's what Cygwin does on 32 bit, assuming a file size > of 100 bytes and a mapping request of 256K: > > First Cygwin mmaps the file. This results in a 4K mapping in Windows: > > file:|-- 100b --| > > mapping: |-- 4K ----| > > Next Cygwin adds another mapping to fill up the range up to the next > 64K allocation granularity boundary: > > |-- file 4K --|-- filler 60K --| > > Eventually Cygwin adds another mapping to fullfill the entire mapping > request: > > |-- file 4K --|-- filler 60K --|-- filler 192K --| > > The problem on WOW64 and real 64 bit is that it's impossible to map > the first filler. However, this area in the VM will *never* be > allocated by other application functions due to the allocation > granularity of 64K! > > So my workaround for 64 bit and WOW64 is to just skip allocating the > first filler: > > |-- file 4K --|-- THE VOID 60K --|-- filler 192K --| > > The advantage is now that the following munmap of 256K will only > unmap the map for the file and the filler, but not the region you > calloced before, which formerly was accidentally mapped to the > filler region. This just can't happen anymore now. > > Would that be feasible? If so I can push my patch and create a > developer snapshot for testing. Two questions arise when I'm thinking about workaround solution: - what happens if caller tries to write to |-- THE VOID 60K --|. Since this is unallocated, would there be a segfault? - is it possible that some subsequent mem alloc request would return region from |-- THE VOID 60K --| which could again cause segfault after munmap? Stanislav Kascak -- 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: Cygwin/X does not seem to work on Windows 10
> I pinned the Cygwin/X "XWin Server" Start Menu item to the taskbar. > When I click that, I get "Cygwin/X Server 0:0" and "X applications menu on :0" > icons in the systray. When I start it via the "XWin Server" entry in the Start Menu - which I have discovered just now, since you mentioned it, I do not get anything in the systray. However, when I use the FVWM entry in the Start Menu, I get a maximized window inside which fvwm is running, and inside this, I can - from the context menu - start among others xterm etc. Ronald -- 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: Cygwin/X does not seem to work on Windows 10
On Tue, Jun 4, 2019, at 15:18, Massimo Balestra wrote: > > > - Installed all the packages, as described in > > https://x.cygwin.com/docs/ug/setup.html > > - Started XLaunch > > - Selected "Multiple Window" and "Start no client", to start the X Server > > I don't know XLaunch but for the Xwindows I prepared a shorcut that run: > > D:\cygwin64\bin\XWin.exe -multiwindow -listen tcp This is interesting, because the way to use XLaunch is the one which is described on the Cygwin/X website. Anyway, I did I started it from the Windows command prompt, as you suggested (without the -listen option because I don't plan to use ssh), and when I then start my DISPLAY=:0.0 xterm & I get the error message xterm: cannot load font "-Misc-Fixed-bold-R-*-*-13-120-75-75-C-120-ISO10646-1" which means that at least the DISPLAY is not a problem anymore. Don't know why it can't find a suitable font, since I have installed plenty of fonts from the Cygwin X11 category. What still does not work is the "X-icon" in the notification area. As a further test, I started DISPLAY=:0.0 xeyes & because this for sure doesn't need any font. This worked too. Ronald -- 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: Cygwin/X does not seem to work on Windows 10
On 2019-06-04 05:52, Ronald Fischer wrote: > What I did: > - Installed all the packages, as described in > https://x.cygwin.com/docs/ug/setup.html > - Started XLaunch > - Selected "Multiple Window" and "Start no client", to start the X Server > - Clicked on "Fertig stellen" (= finish). > - Using mintty, I started a cygwin shell (zsh). > - Inside this shell, I tried a > xterm & > which, not surprisingly, resulted into: >xterm: Xt error: Can't open display: >xterm: DISPLAY is not set > and then a > DISPLAY=:0.0 xterm & > which also produced an error message: >xterm: Xt error: Can't open display: :0.0 > Interestingly, there is an X-Icon in the notification area, and when I hover > over it, the tooltip says "Cygwin/X Servre: 0.0", but when I right-click on > this > icon, no context menu appears. > When I do a double-LEFT-click on this icon, the icon disappears completely. > I then opened the Task Manager, but could not find any process where the > name hinted that an X server would be running. I pinned the Cygwin/X "XWin Server" Start Menu item to the taskbar. When I click that, I get "Cygwin/X Server 0:0" and "X applications menu on :0" icons in the systray. I set up to have a mintty window launched, near the end of ~/.startxwinrc, copied from /etc/X11/xinit/startxwinrc, which now ends: if [ -x /usr/bin/x-terminal-emulator ] ; then /usr/bin/mintty - & fi exec /usr/bin/xwin-xdg-menu fi So that control still ends up in the XDG menu. As mintty does not take normal XTerm options, it is run explicitly. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- 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: Cygwin/X does not seem to work on Windows 10
> - Installed all the packages, as described in > https://x.cygwin.com/docs/ug/setup.html > - Started XLaunch > - Selected "Multiple Window" and "Start no client", to start the X Server I don't know XLaunch but for the Xwindows I prepared a shorcut that run: D:\cygwin64\bin\XWin.exe -multiwindow -listen tcp I need the -listen tcp because I use XWin mainly through a tunnel ssh And it works perfectly in windows 10 (1809) Have fun Massimo -- 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: possible problem with memory allocation using calloc/mmap/munmap
On Jun 4 11:38, Stanislav Kascak wrote: > > > It seems that when mmap() is called with length argument exceeding > > > size of file, only memory to fit that file is allocated. munmap() > > > however frees the full specified length. Since (at least on my > > > computer) big chunk of memory allocated by calloc() is located after > > > mmap() allocation, munmap() frees even memory of that calloc(). > > > > Ken's right. Due to the differences between mapping files on Windows > > vs. Unix, Cygwin can't map beyond the file size + the remainder of the > > last page. Cygwin tries to workaround that on 32 bit by allocating > > an anonymous mapping following the file mapping to keep the range free > > from other mappings. But on 64 bit this workaround doesn't work anymore > > because the OS is missing an (undocumented) flag which allows to > > create mappings on 4K boundaries, rather than just on 64K boundaries. > > > > I know this situation is unsatisfying, but I have no easy workaround > > to allow this. Cygwin could add the anonymous mapping on the next > > 64K boundary on 64 bit, but that would result in a hole in the mapping > > which seemed like a rather bad idea when porting mmap to 64 bit. > > > > Ken's also right that munmap is doing the right thing here. If > > anything's wrong, it's mmap's workaround for mappings beyond the file > > length. If only 64 bit would allow 4K-aligned mappings :( > > Thanks for the answer. It is appreciated. > I understand the problem and difficulty to resolve it. Maybe returning > an error from mmap (and putting a comment to code for its reason) > would be sufficient. mmap caller could just adjust requested > allocation size to file size. Without error, caller has no way of > knowing memory was not allocated and segfault is then thrown in an > unrelated memory segment which makes the root cause hard to track > down. But, I do not know all the implication that could result from > that, so evaluation of this approach is up to you. Given that most of the required code already exists for 32 bit systems (except under WOW64, suffering the same problem as the 64 bit WIndows environment), I hacked a bit on this code this morning and I got your testcase running fine. The idea being that after a successful mmap the expectation that a matching munmap does *not* unmap unrelated mappings is valid. In more depth, here's what Cygwin does on 32 bit, assuming a file size of 100 bytes and a mapping request of 256K: First Cygwin mmaps the file. This results in a 4K mapping in Windows: file:|-- 100b --| mapping: |-- 4K ----| Next Cygwin adds another mapping to fill up the range up to the next 64K allocation granularity boundary: |-- file 4K --|-- filler 60K --| Eventually Cygwin adds another mapping to fullfill the entire mapping request: |-- file 4K --|-- filler 60K --|-- filler 192K --| The problem on WOW64 and real 64 bit is that it's impossible to map the first filler. However, this area in the VM will *never* be allocated by other application functions due to the allocation granularity of 64K! So my workaround for 64 bit and WOW64 is to just skip allocating the first filler: |-- file 4K --|-- THE VOID 60K --|-- filler 192K --| The advantage is now that the following munmap of 256K will only unmap the map for the file and the filler, but not the region you calloced before, which formerly was accidentally mapped to the filler region. This just can't happen anymore now. Would that be feasible? If so I can push my patch and create a developer snapshot for testing. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Cygwin/X does not seem to work on Windows 10
What I did: - Installed all the packages, as described in https://x.cygwin.com/docs/ug/setup.html - Started XLaunch - Selected "Multiple Window" and "Start no client", to start the X Server - Clicked on "Fertig stellen" (= finish). - Using mintty, I started a cygwin shell (zsh). - Inside this shell, I tried a xterm & which, not surprisingly, resulted into: xterm: Xt error: Can't open display: xterm: DISPLAY is not set and then a DISPLAY=:0.0 xterm & which also produced an error message: xterm: Xt error: Can't open display: :0.0 Interestingly, there is an X-Icon in the notification area, and when I hover over it, the tooltip says "Cygwin/X Servre: 0.0", but when I right-click on this icon, no context menu appears. When I do a double-LEFT-click on this icon, the icon disappears completely. I then opened the Task Manager, but could not find any process where the name hinted that an X server would be running. Ronald -- 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: possible problem with memory allocation using calloc/mmap/munmap
> > It seems that when mmap() is called with length argument exceeding > > size of file, only memory to fit that file is allocated. munmap() > > however frees the full specified length. Since (at least on my > > computer) big chunk of memory allocated by calloc() is located after > > mmap() allocation, munmap() frees even memory of that calloc(). > > Ken's right. Due to the differences between mapping files on Windows > vs. Unix, Cygwin can't map beyond the file size + the remainder of the > last page. Cygwin tries to workaround that on 32 bit by allocating > an anonymous mapping following the file mapping to keep the range free > from other mappings. But on 64 bit this workaround doesn't work anymore > because the OS is missing an (undocumented) flag which allows to > create mappings on 4K boundaries, rather than just on 64K boundaries. > > I know this situation is unsatisfying, but I have no easy workaround > to allow this. Cygwin could add the anonymous mapping on the next > 64K boundary on 64 bit, but that would result in a hole in the mapping > which seemed like a rather bad idea when porting mmap to 64 bit. > > Ken's also right that munmap is doing the right thing here. If > anything's wrong, it's mmap's workaround for mappings beyond the file > length. If only 64 bit would allow 4K-aligned mappings :( Thanks for the answer. It is appreciated. I understand the problem and difficulty to resolve it. Maybe returning an error from mmap (and putting a comment to code for its reason) would be sufficient. mmap caller could just adjust requested allocation size to file size. Without error, caller has no way of knowing memory was not allocated and segfault is then thrown in an unrelated memory segment which makes the root cause hard to track down. But, I do not know all the implication that could result from that, so evaluation of this approach is up to you. Thanks again. -- 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: [ANNOUNCEMENT] Test: cmake-3.13.1-1
Am 30.05.2019 um 18:05 schrieb Yaakov Selkowitz: On Thu, 2019-05-30 at 10:11 +0200, Marco Atzeri wrote: Am 28.05.2019 um 04:39 schrieb Steven Penny: On Thu, 29 Nov 2018 07:58:53, Marco Atzeri wrote: Test version 3.13.3-1 of Can we please move this out of test? I have no problem, but Tony thinks that as the cmake test suite test is not perfect so he prefers to stay with the old one. 99% tests passed, 4 tests failed out of 548 I was not able to identify the failures root cause, and I suspect they are not fundamental and related to the test suite itfelf. Our cmake is falling really far behind, and it is starting to affect its usability as packages require newer features. I'd rather see us keep up with the latest stable release (now 3.13.4). -- Yaakov noted. building 3.13.5 for the time being as 3.14.5 failed and will need more analysis Tony, please advise if you want to follow up by yourself Regards Marco --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus -- 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: [PATCH] mkdir: always check-for-existence
Hi Ben,
On Jun 3 22:07, Ben wrote:
> When creating a directory which already exists, NtCreateFile will correctly
> return 'STATUS_OBJECT_NAME_COLLISION'.
>
> However when creating a directory and all its parents a normal use would
> be to start with mkdir(‘/cygdrive/c’) which translates to ‘C:\’ for which
> it'll
> instead return ‘STATUS_ACCESS_DENIED’.
>
> So we better check for existence prior to calling NtCreateFile.
> ---
> winsup/cygwin/dir.cc | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc
> index f43eae461..b757851d5 100644
> --- a/winsup/cygwin/dir.cc
> +++ b/winsup/cygwin/dir.cc
> @@ -331,8 +331,10 @@ mkdir (const char *dir, mode_t mode)
> debug_printf ("got %d error from build_fh_name", fh->error ());
> set_errno (fh->error ());
> }
> + else if (fh->exists ())
> + set_errno (EEXIST);
> else if (has_dot_last_component (dir, true))
> - set_errno (fh->exists () ? EEXIST : ENOENT);
> + set_errno (ENOENT);
> else if (!fh->mkdir (mode))
> res = 0;
> delete fh;
>
> --
> 2.21.0
I was just trying to apply your patch but it fails to apply cleanly.
Can you please check your indentation? The `else' lines are indented
more than the lines in between and TABs are missing.
Maybe your MUA breaks the output? If all else fails, you could attach
your patch as plain/text attachement to your mail, usually that's left
alone by the MUA.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
Re: [PATCH v2] cygcheck: expand common_apps list
Hi Yaakov, On Jun 3 18:19, Yaakov Selkowitz wrote: > An increasing number of tools are being included in Windows which have the > same names as those included in Cygwin packages. Indicating which one is > first in PATH can be helpful in diagnosing behavioural discrepencies > between them. > > Also, fix the alphabetization of ssh. Sure, please push. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [Attn. Maintainer] /etc/profile.d/lapack0.csh
Am 02.06.2019 um 17:37 schrieb Achim Gratz: The profile script for csh does not work as intended. Since it must be sourced, it leaves variables set in the user shell and potentially clobbers variables the user might use ($newpath is just too obvious a name). Something like this should be more robust: --8<---cut here---start->8--- set __LA_BINDIR=/usr/lib/lapack set __LA_PATH=($path:q $__LA_BINDIR:q) foreach __LA_F ($path:q) if ( "$__LA_F" == "$__LA_BINDIR" ) then set __LA_PATH=($path:q) break endif end set path=($__LA_PATH:q) unset __LA_* --8<---cut here---end--->8--- Regards, Achim. noted for the next release --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus
