Re: [PATCH] winsup/cygwin/fhandler/proc.cc: format_proc_cpuinfo() Linux 6.8 cpuinfo flags

[Corinna Vinschen]

On Mar 18 11:21, Brian Inglis wrote:
> On 2024-03-18 09:45, Corinna Vinschen wrote:
> > I see.  I just don't understands the difference between, say,
> > 
> >ftcprint (features1, 21, "avx512ifma");   /* vec int FMA */
> > + /*  ftcprint (features1, 22, ""); */  /* unused */
> >ftcprint (features1, 23, "clflushopt");   /* cache line flush opt */
> > 
> > and
> > 
> >ftcprint (features1,  3, "xsaves");   /* xsaves/xrstors */
> > + /*  ftcprint (features1,  4, "xfd"); */   /* eXtended Feature Disabling */
> > 
> > The latter makes sense, of course, but why is the first comment "unused",
> > rather than something like "PCOMMIT instruction" as in the cpuid output?
> > 
> > Note that I'm not saying that you have to change that, but I would like
> > to understand it.
> 
> Hi Corinna,
> 
> The cpuid output is not always up to date with the kernel, and there are a
> lot of bits defined, so if Linux does not use the bit I will not mention it,
> except where uses and visibility may vary because of merge/patch revisions,
> as happened recently with shstk and lam handling changes.
> 
> The cpuinfo capflags are generated by running the Linux build script
> mkcapflags.sh, from the feature symbol suffix, unless overriden by a quoted
> string at the start of the comment, and "" suppresses cpuinfo flag output.
> 
> In my weekly pulls of relevant rc sources, I generate a couple of summary
> logs to merge the cpuinfo capflags with the comments and feature bits, and
> diff everything relevant vs the previous tagged release.
> 
> I keep an eye on those diffs, and when the next release is no longer a
> candidate, I pull up the Linux changes and look at how they can be added to
> Cygwin.
> 
> I sometimes add features commented out to document bits used in a feature
> word, but not yet displayed on cpuinfo, just to make it easier to compare
> with Linux, or more obvious that an unused bit has not been missed.
> The latest additions are the result of uncertainties raised during my last
> cross check.
> 
> Below is a sample of the info used to display Linux cpuinfo flags, which I
> use to support Cygwin's, relevant to those you mentioned.
> Linux feature word 9 bit 22 is unused, and word 10 bit 4 is not displayed.
> [...]
> Many of the synthetic Linux features and flags are derived from hw boot or
> MSR info, which we can not yet access from Cygwin, so I ignore those
> changes, unless the feature can be derived from information readily
> available as a user in the cpu, Windows, or Cygwin.
> 
> I cross check the Linux and Cygwin sources occasionally to ensure I have not
> missed anything added or removed, spelling changes, Linux tweaks, or
> readability.
> 
> I have so far ignored feature disabling depending on conditions, and cpu
> errata checks and output, as some of that requires MSR info or low level
> access.
> 
> I have looked at trying to extract or generate tables from the Linux sources
> to drive our cpuinfo, use gcc cpuid and cpuinfo headers, automate or at
> least simplify maintenance, but there are many exceptions which we can not
> determine to output, and Intel's practices are not as architecturally
> structured as AMD's, so require code to decide.]

Thanks for the explanation.  Pushed.


Corinna

Re: Getting error 60 of curl to cygwin setup

[Brian Inglis via Cygwin]

On 2024-03-18 15:21, J M via Cygwin wrote:

With a fresh install of Cygwin then I launch (with package curl installed):

curl -O https://www.cygwin.com/setup-x86_64.exe

Shows a curl 60 error ssl problem.
Using -k or --insecure works, but is not recomended.
Howto fix it?


WJFFM!

That error implies that the version of curl you are running or the certificate 
store you are using does not include the Let's Encrypt CA used by Cygwin.com.


From what shell do you launch curl?

Please run:

which -a curl

and ensure that /usr/bin/curl precedes /cygdrive/c/WINDOWS/system32/curl then
run:

$ curl -V
curl 8.6.0 (x86_64-pc-cygwin) libcurl/8.6.0 OpenSSL/3.0.13 zlib/1.3.1 
brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.5 libssh2/1.11.0 
nghttp2/1.60.0 libgsasl/2.2.1 OpenLDAP/2.6.7

Release-Date: 2024-01-31
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns 
ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli gsasl GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 
Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd


and check you get the same output as above, then run:

cygcheck -c ca-certificates ca-certificates-letsencrypt curl cygwin \
libbrotlidec1 libcurl4 libgsasl18 libgssapi_krb5_2 libidn2_0 libnghttp2_14 \
libopenldap2 libpsl5 libssh2_1 libssl3 libzstd1 zlib0

and ensure all packages show Status OK.

If that is the case, please follow the problem reporting guidelines below, and 
attach the output from running


cygcheck -hrsv > cygcheck-hrsv.log

as a text attachment to your reply.

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: HDF5 Installation

[Kyle Shores via Cygwin]

Any chance you could use cmake for the next installation? That way more
packages would be able to include HDF5 with cmake and pkg-config.

Best,
Kyle

On Mon, Mar 18, 2024 at 3:23 PM marco atzeri  wrote:

> On Mon, Mar 18, 2024 at 3:28 PM Kyle Shores via Cygwin  wrote:
> >
> > Howdy!
> >
> > Looking at the list of files
> >  >
> > for the 2024 HDF5 installation 1.12.3
> > , I notice that
> > neither the pkg-config or cmake files are installed. For reference,
> > mingw's installation
> > of hdf5  has
> them
> > here:
> >
> >
> >- /mingw64/lib/cmake/hdf5-targets.cmake
> >- /mingw64/lib/pkgconfig/hdf5.pc
> >
> > Are these installed elsewhere? If not, what's preventing them from
> > being installed, or what can I do to help them be installed?
> >
>
> Hi Kyle
>
> the package is NOT built using cmake but is using autoconf.
> There are no special change. So upstream have not included those files
> in the 1.12.3 autoconf
>
> I have not yet tried to build using cmake nor built the 1.14.x series
>
> Regards
> Marco
>

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Getting error 60 of curl to cygwin setup

[J M via Cygwin]

Hi,

With a fresh install of Cygwin then I launch (with package curl installed):

curl -O https://www.cygwin.com/setup-x86_64.exe

Shows a curl 60 error ssl problem.
Using -k or --insecure works, but is not recomended.
Howto fix it?

Regards,
Cesar Jorge

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: HDF5 Installation

[marco atzeri via Cygwin]

On Mon, Mar 18, 2024 at 3:28 PM Kyle Shores via Cygwin  wrote:
>
> Howdy!
>
> Looking at the list of files
> 
> for the 2024 HDF5 installation 1.12.3
> , I notice that
> neither the pkg-config or cmake files are installed. For reference,
> mingw's installation
> of hdf5  has them
> here:
>
>
>- /mingw64/lib/cmake/hdf5-targets.cmake
>- /mingw64/lib/pkgconfig/hdf5.pc
>
> Are these installed elsewhere? If not, what's preventing them from
> being installed, or what can I do to help them be installed?
>

Hi Kyle

the package is NOT built using cmake but is using autoconf.
There are no special change. So upstream have not included those files
in the 1.12.3 autoconf

I have not yet tried to build using cmake nor built the 1.14.x series

Regards
Marco

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Cannot downgrade gcc 13 or 12 to 11.4.0-1

[Jon Turney via Cygwin]

On 14/03/2024 18:34, Thomas Hedden via Cygwin wrote:
I installed a test version of gcc and cannot revert to an earlier, 
non-test version. Here are the latest versions listed in the setup routine:


11.4.0-1
12.3.1+20240202-0.1 (Test)
13.2.1+20240203-0.1 (Test)

(there are some even older ones, but I want 11.4.0-1.)

$ gcc --version
gcc (GCC) 13.2.1 20240203

[...]

$ gcc -o hello.exe hello.c
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find -lintl: No such file or directory
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find -liconv: No such file or directory

collect2: error: ld returned 1 exit status


This seems like a problem with this test version of gcc.  I guess maybe 
it now links with intl and iconv by default in the specsfile, which will 
require the corresponding devel packages to be installed, but it doesn't 
depend on them.


This seems like a mistake. (I think libstdc++ will now require these, 
but they shouldn't be needed just for c compilation.)


So, I can't compile anything. I don't need the test version to work, I 
just want to downgrade to 11.4.0-1. However, if I uninstall the test 
version, and then try to install 11.4.0-1, I get the following message:


Problem 1/1
package gcc-g++-11.4.0-1 requires gcc11, but none of the providers can 
be installed

Solution 1/2
   - allow replacement of gcc-core-13.2.1+20240203-0.1 with 
gcc-core-11.4.0-1

Solution 2/2 (default)
   - do not ask to lock gcc-g++-11.4.0-1

What should I do?


Sorry that this message isn't very clear, and this situation is not 
handled well by setup.


You need to downgrade all the various gcc packages in step.

Which you can do manually, but perhaps the easiest way to do this is to 
select the 'Sync' option at the top-right, which will downgrade all test 
packages.



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH] winsup/cygwin/fhandler/proc.cc: format_proc_cpuinfo() Linux 6.8 cpuinfo flags

[Brian Inglis]

On 2024-03-18 09:45, Corinna Vinschen wrote:

On Mar 18 08:10, Brian Inglis wrote:

On 2024-03-18 03:33, Corinna Vinschen wrote:

On Mar 16 10:44, Brian Inglis wrote:

add Linux 6.8 cpuinfo flags:
Intel 0x0007:1 eax:17 fred  Flexible Return and Event Delivery;
AMD   0x801f   eax:4  sev_snp   SEV secure nested paging;
document unused and some unprinted bits that could look like omissions;
fix typos and misalignments;


I'm a bit puzzled about the "unused" slots.  You're adding them
only in some places.  What makes them "look like omissions"?


Mainly because single bits are omitted, presumably because they do not want
to pollute the symbol space with as yet unused features, just as they do not
output all features as cpuinfo flags, until it indicates something about the
build and/or system.

Compare the minimal common standard feature bits defined in the gcc lib
cpuid.h and gcc cpuinfo.h headers, with Linux cpuinfo cpufeatures.h, and the
output of the cpuid utility, where almost all bits in older cpuid entries
are defined.


I see.  I just don't understands the difference between, say,

   ftcprint (features1, 21, "avx512ifma");   /* vec int FMA */
+ /*  ftcprint (features1, 22, ""); */  /* unused */
   ftcprint (features1, 23, "clflushopt");   /* cache line flush opt */

and

   ftcprint (features1,  3, "xsaves");   /* xsaves/xrstors */
+ /*  ftcprint (features1,  4, "xfd"); */   /* eXtended Feature Disabling */

The latter makes sense, of course, but why is the first comment "unused",
rather than something like "PCOMMIT instruction" as in the cpuid output?

Note that I'm not saying that you have to change that, but I would like
to understand it.


Hi Corinna,

The cpuid output is not always up to date with the kernel, and there are a lot 
of bits defined, so if Linux does not use the bit I will not mention it, except 
where uses and visibility may vary because of merge/patch revisions, as happened 
recently with shstk and lam handling changes.


The cpuinfo capflags are generated by running the Linux build script 
mkcapflags.sh, from the feature symbol suffix, unless overriden by a quoted 
string at the start of the comment, and "" suppresses cpuinfo flag output.


In my weekly pulls of relevant rc sources, I generate a couple of summary logs 
to merge the cpuinfo capflags with the comments and feature bits, and diff 
everything relevant vs the previous tagged release.


I keep an eye on those diffs, and when the next release is no longer a 
candidate, I pull up the Linux changes and look at how they can be added to Cygwin.


I sometimes add features commented out to document bits used in a feature word, 
but not yet displayed on cpuinfo, just to make it easier to compare with Linux, 
or more obvious that an unused bit has not been missed.
The latest additions are the result of uncertainties raised during my last cross 
check.


Below is a sample of the info used to display Linux cpuinfo flags, which I use 
to support Cygwin's, relevant to those you mentioned.

Linux feature word 9 bit 22 is unused, and word 10 bit 4 is not displayed.

$ grep -iC1 'avx512ifma\|clflushopt\|xsaves\|xfd' *
capflags.h- [X86_FEATURE_SMAP]   = "smap",
capflags.h: [X86_FEATURE_AVX512IFMA] = "avx512ifma",
capflags.h: [X86_FEATURE_CLFLUSHOPT] = "clflushopt",
capflags.h- [X86_FEATURE_CLWB]   = "clwb",
--
capflags.h- [X86_FEATURE_XGETBV1]= "xgetbv1",
capflags.h: [X86_FEATURE_XSAVES] = "xsaves",
capflags.h- [X86_FEATURE_CQM_LLC]= "cqm_llc",
--
cpufeatures.h-#define X86_FEATURE_SMAP  ( 9*32+20) /* Supervisor Mode 
Access Prevention */
cpufeatures.h:#define X86_FEATURE_AVX512IFMA( 9*32+21) /* AVX-512 Integer 
Fused Multiply-Add instructions */
cpufeatures.h:#define X86_FEATURE_CLFLUSHOPT( 9*32+23) /* CLFLUSHOPT 
instruction */

cpufeatures.h-#define X86_FEATURE_CLWB  ( 9*32+24) /* CLWB instruction 
*/
--
cpufeatures.h-#define X86_FEATURE_XGETBV1   (10*32+ 2) /* XGETBV with ECX = 
1 instruction */
cpufeatures.h:#define X86_FEATURE_XSAVES(10*32+ 3) /* XSAVES/XRSTORS 
instructions */
cpufeatures.h:#define X86_FEATURE_XFD   (10*32+ 4) /* "" eXtended 
Feature Disabling */

cpufeatures.h-
--
cpufeatures.log-Intel   0x0007  0   EBX 20  "smap" 
   Supervisor Mode Access Prevention
cpufeatures.log:Intel   0x0007  0   EBX 21  "avx512ifma" 
   AVX-512 Integer Fused Multiply-Add instructions
cpufeatures.log:Intel   0x0007  0   EBX 23  "clflushopt" 
   CLFLUSHOPT instruction
cpufeatures.log-Intel   0x0007  0   EBX 24  "clwb" 
   CLWB instruction

--
cpufeatures.log-0x000d  1   EAX  2  "xgetbv1" 
   XGETBV with ECX = 1 instruction
cpufeatures.log:0x000d  1   EAX  3  "xsaves" 
   XSAVES/XRSTORS instructions

Re: ACEs and ACLs

[Corinna Vinschen via Cygwin]

On Mar 18 09:23, J. Terry Corbet via Cygwin wrote:
> 
> Sorry, 84-yr old eyes sometimes don't work as well.  Thanks for confirming
> that  nothing has changed with regards to these matters; clearly it is some
> change in the way Windows 11 tries to cooperate with Windows 10 in the case
> of mapped network drives being using in the file sharing mode wherein remote
> users must have ids and passwords on the target drives -- which they do and
> always have, but the key ACE entry known as NT AUTHORITY\Authenticated Users
> is correctly specified after performing an icacls /reset, but is not longer
> correctly set after editing a file with vim across the network.  I'll keep
> looking and trying to  learn.  Thank you.

Please add the "noacl" flag where you need it and try again.  The result
is using the standard Windows security, so you should see what you
expect in that case.


Thanks,
Corinna


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH] winsup/cygwin/fhandler/proc.cc: format_proc_cpuinfo() Linux 6.8 cpuinfo flags

[Corinna Vinschen]

On Mar 18 08:10, Brian Inglis wrote:
> On 2024-03-18 03:33, Corinna Vinschen wrote:
> > Hi Brian,
> > 
> > On Mar 16 10:44, Brian Inglis wrote:
> > > add Linux 6.8 cpuinfo flags:
> > > Intel 0x0007:1 eax:17 fredFlexible Return and Event 
> > > Delivery;
> > > AMD   0x801f   eax:4  sev_snp SEV secure nested paging;
> > > document unused and some unprinted bits that could look like omissions;
> > > fix typos and misalignments;
> > 
> > I'm a bit puzzled about the "unused" slots.  You're adding them
> > only in some places.  What makes them "look like omissions"?
> 
> Mainly because single bits are omitted, presumably because they do not want
> to pollute the symbol space with as yet unused features, just as they do not
> output all features as cpuinfo flags, until it indicates something about the
> build and/or system.
> 
> Compare the minimal common standard feature bits defined in the gcc lib
> cpuid.h and gcc cpuinfo.h headers, with Linux cpuinfo cpufeatures.h, and the
> output of the cpuid utility, where almost all bits in older cpuid entries
> are defined.

I see.  I just don't understands the difference between, say,

  ftcprint (features1, 21, "avx512ifma");   /* vec int FMA */
+ /*  ftcprint (features1, 22, ""); */  /* unused */
  ftcprint (features1, 23, "clflushopt");   /* cache line flush opt */

and

  ftcprint (features1,  3, "xsaves");   /* xsaves/xrstors */
+ /*  ftcprint (features1,  4, "xfd"); */   /* eXtended Feature Disabling */

The latter makes sense, of course, but why is the first comment "unused",
rather than something like "PCOMMIT instruction" as in the cpuid output?

Note that I'm not saying that you have to change that, but I would like
to understand it.


Thanks,
Corinna

Re: ACEs and ACLs

[J. Terry Corbet via Cygwin]

Sorry, 84-yr old eyes sometimes don't work as well.  Thanks for 
confirming that  nothing has changed with regards to these matters; 
clearly it is some change in the way Windows 11 tries to cooperate with 
Windows 10 in the case of mapped network drives being using in the file 
sharing mode wherein remote users must have ids and passwords on the 
target drives -- which they do and always have, but the key ACE entry 
known as NT AUTHORITY\Authenticated Users is correctly specified after 
performing an icacls /reset, but is not longer correctly set after 
editing a file with vim across the network.  I'll keep looking and 
trying to  learn.  Thank you.


On 2024-03-18 08:43, Corinna Vinschen via Cygwin wrote:

On Mar 18 08:30, J. Terry Corbet via Cygwin wrote:

Thank you for the greatly needed assistance, but the reference to which you
have pointed me says that noacl will be ignored in the case of ntfs file
systems.

No, it doesn't say that.  It says

   "The flag is ignored on NFS filesystems."
   ^^^
 not NTFS


All of mine are and that has not changed, neither has the default
entry in fstab, which seems always to have been:

none /cygdrive cygdrive binary, posix=0, user 0 0

Well, the code in question hasn't changed for years either.


¯\_(ツ)_/¯
Corinna



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: ACEs and ACLs

[Corinna Vinschen via Cygwin]

On Mar 18 08:30, J. Terry Corbet via Cygwin wrote:
> Thank you for the greatly needed assistance, but the reference to which you
> have pointed me says that noacl will be ignored in the case of ntfs file
> systems.

No, it doesn't say that.  It says

  "The flag is ignored on NFS filesystems."
  ^^^
not NTFS

> All of mine are and that has not changed, neither has the default
> entry in fstab, which seems always to have been:
> 
> none /cygdrive cygdrive binary, posix=0, user 0 0

Well, the code in question hasn't changed for years either.


¯\_(ツ)_/¯
Corinna

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: ACEs and ACLs

[J. Terry Corbet via Cygwin]

Thank you for the greatly needed assistance, but the reference to which 
you have pointed me says that noacl will be ignored in the case of ntfs 
file systems.  All of mine are and that has not changed, neither has the 
default entry in fstab, which seems always to have been:


none /cygdrive cygdrive binary, posix=0, user 0 0

On 2024-03-18 04:41, Corinna Vinschen via Cygwin wrote:

On Mar 16 18:05, J. Terry Corbet via Cygwin wrote:

[...]
And here is the status that icacls reports back on the original, owning
workstation
after having use vim to modify the two files from that remote workstation.

FileExp.txt NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
     NW10\tcorbet:(DENY)(S,RD,WD,AD,REA,WEA,X,DC)
     NW10\tcorbet:(D,Rc,WDAC,WO,RA,WA)
     NW10\None:(Rc,S,RA)
     NT AUTHORITY\Authenticated Users:(RX,W)
     NT AUTHORITY\SYSTEM:(RX,W)
     BUILTIN\Administrators:(RX,W)
     BUILTIN\Users:(RX)
     Everyone:(Rc,S,RA)

vimtest.txt NULL SID:(DENY)(Rc,S,WEA,X,DC)
     NW10\tcorbet:(R,W,D,WDAC,WO)
     NW10\None:(DENY)(S,X)
     NT AUTHORITY\Authenticated Users:(DENY)(S,X)
     NT AUTHORITY\SYSTEM:(DENY)(S,X)
     BUILTIN\Administrators:(DENY)(S,X)
     BUILTIN\Users:(DENY)(S,X)
     NW10\None:(RX)
     NT AUTHORITY\Authenticated Users:(RX,W)
     NT AUTHORITY\SYSTEM:(RX,W)
     BUILTIN\Administrators:(RX,W)
     BUILTIN\Users:(RX)
     Everyone:(R)

If my understanding is correct concerning the precedence handling of an
ACL with multiple ACEs for the same user/ID, this result from grep
on the original, owning workstation would not surprise you:

F:\Dev\cygshoot>grep foo fileexp.txt
grep: fileexp.txt: Permission denied

but it blows me completely away.  Clearly I no longer have an environment
in which I can work on any file from any workstation using any Cygwin
utilities.

What have I messed up?

The problem is that your identity is based on the SID of every single
machine, and the machines don't know the SIDs of other machines.  The
default ACL created in Cygwin is emulating POSIX permissions.  This
becomes a problem when sharing files between machines not in the
same Windows domain.

The workaround is not to use POSIX permissions on shares.  Create
matching mount points in /etc/fstab or /etc/fstab.d/ and add the
"noacl" mount flag:

   https://cygwin.com/cygwin-ug-net/using.html#mount-table

Alternatively, you can also just add an fstab entry for the cygdrive
prefix which adds the "noacl" flag, see

   https://cygwin.com/cygwin-ug-net/using.html#cygdrive

but keep in mind that this also affects local paths if you access
them via the cygdrive prefix.


HTH,
Corinna



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

HDF5 Installation

[Kyle Shores via Cygwin]

Howdy!

Looking at the list of files

for the 2024 HDF5 installation 1.12.3
, I notice that
neither the pkg-config or cmake files are installed. For reference,
mingw's installation
of hdf5  has them
here:


   - /mingw64/lib/cmake/hdf5-targets.cmake
   - /mingw64/lib/pkgconfig/hdf5.pc

Are these installed elsewhere? If not, what's preventing them from
being installed, or what can I do to help them be installed?

-- 

Kyle Shores | Software Developer

NSF National Center for Atmospheric Research (NSF NCAR)

Atmospheric Chemistry Observations and Modeling lab (ACOM)

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH] winsup/cygwin/fhandler/proc.cc: format_proc_cpuinfo() Linux 6.8 cpuinfo flags

[Brian Inglis]

On 2024-03-18 03:33, Corinna Vinschen wrote:

Hi Brian,

On Mar 16 10:44, Brian Inglis wrote:

add Linux 6.8 cpuinfo flags:
Intel 0x0007:1 eax:17 fred  Flexible Return and Event Delivery;
AMD   0x801f   eax:4  sev_snp   SEV secure nested paging;
document unused and some unprinted bits that could look like omissions;
fix typos and misalignments;


I'm a bit puzzled about the "unused" slots.  You're adding them
only in some places.  What makes them "look like omissions"?


Mainly because single bits are omitted, presumably because they do not want to 
pollute the symbol space with as yet unused features, just as they do not output 
all features as cpuinfo flags, until it indicates something about the build 
and/or system.


Compare the minimal common standard feature bits defined in the gcc lib cpuid.h 
and gcc cpuinfo.h headers, with Linux cpuinfo cpufeatures.h, and the output of 
the cpuid utility, where almost all bits in older cpuid entries are defined.


--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

Re: Bogus exit code 127 from a child process

[Alexey Izbyshev via Cygwin]

On 2024-03-18 07:58, Takashi Yano wrote:

On Mon, 18 Mar 2024 12:09:06 +0900
Takashi Yano wrote:

On Sun, 17 Mar 2024 14:10:55 +0100
Dimitry Andric wrote:
> On 17 Mar 2024, at 13:50, Dimitry Andric  
wrote:
> >
> > On 17 Mar 2024, at 13:35, Takashi Yano via Cygwin  wrote:
> > ...
> >>
> >> I also test your test case:
> >> while bash -c 'true & true & wait -n || { echo 1: $?; exit 1; } && wait -n 
|| { echo 2: $?; exit 1; }'; do echo $((i++)); done
> >> in Linux (Debian 12.5), and the issue reproduced!
> >
> > Yeah, same here with bash 5.1.16(1)-release on Ubuntu 22.04. It errors out 
with 127 after ~50-200 loops.
>
> Having built bash master (bash-5.2-27-gf3b6bd19) here, it consistently gives 
127 in this area:
>
> https://git.savannah.gnu.org/cgit/bash.git/tree/builtins/wait.def#n227
>
>211  #if defined (JOB_CONTROL)
>212if (nflag)
>213  {
>214if (list)
>215  {
>216opt = set_waitlist (list);
>217if (opt == 0)
>218  WAIT_RETURN (127);
>219wflags |= JWAIT_WAITING;
>220  }
>221
>222status = wait_for_any_job (wflags, );
>223if (vname && status >= 0)
>224  builtin_bind_var_to_int (vname, pstat.pid, bindflags);
>225
>226if (status < 0)
> => 227  status = 127;
>228if (list)
>229  unset_waitlist ();
>230WAIT_RETURN (status);
>231  }
>232  #endif
>
> So for some reason, wait_for_any_job() returns a negative value in this 
particular situation.

Line 218 looks also suspicious.


Probably, this is not a bug. man bash says:
  If  the  -n option is supplied, wait waits for a single 
job from
  the list of ids or, if no ids are supplied, any job, to 
complete
  and returns its exit status.  If none of the supplied  
arguments
  is a child of the shell, or if no arguments are supplied 
and the
  shell  has no unwaited‐for children, the exit status is 
127.


If the background process exited before calling 'wait -n', it returns 
127.

This is very different from wait() system call, which is necessary for
any background joubs, otherwise zombie remains.

In the shell, it is not necessary to call wait command for background 
jobs,
therefore exit status of the background job which already exited is not 
held

anymore.

So, actual bug is in the test case.


I missed the subthread starting from your bash version request due to 
not being CCed, so replying via the mail archive link.


I'm sorry for wasting your time with the bad test case. I should have 
tested on Linux first myself. Thank you, Takashi and Dimitry.


The original problem with make that I was reproducing doesn't involve 
"wait -n" or any bash background jobs though, so this puts me back to 
the point before (I thought) I eliminated make. I'll try my older 
reproducers with new Cygwin versions, and will probably look at make 
source code (since it's starting to look like it might be a bug in make, 
not in Cygwin) before posting further.


Thanks,
Alexey


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: ACEs and ACLs

[Corinna Vinschen via Cygwin]

On Mar 16 18:05, J. Terry Corbet via Cygwin wrote:
> [...]
> And here is the status that icacls reports back on the original, owning
> workstation
> after having use vim to modify the two files from that remote workstation.
> 
> FileExp.txt NULL SID:(DENY)(Rc,S,REA,WEA,X,DC)
>     NW10\tcorbet:(DENY)(S,RD,WD,AD,REA,WEA,X,DC)
>     NW10\tcorbet:(D,Rc,WDAC,WO,RA,WA)
>     NW10\None:(Rc,S,RA)
>     NT AUTHORITY\Authenticated Users:(RX,W)
>     NT AUTHORITY\SYSTEM:(RX,W)
>     BUILTIN\Administrators:(RX,W)
>     BUILTIN\Users:(RX)
>     Everyone:(Rc,S,RA)
> 
> vimtest.txt NULL SID:(DENY)(Rc,S,WEA,X,DC)
>     NW10\tcorbet:(R,W,D,WDAC,WO)
>     NW10\None:(DENY)(S,X)
>     NT AUTHORITY\Authenticated Users:(DENY)(S,X)
>     NT AUTHORITY\SYSTEM:(DENY)(S,X)
>     BUILTIN\Administrators:(DENY)(S,X)
>     BUILTIN\Users:(DENY)(S,X)
>     NW10\None:(RX)
>     NT AUTHORITY\Authenticated Users:(RX,W)
>     NT AUTHORITY\SYSTEM:(RX,W)
>     BUILTIN\Administrators:(RX,W)
>     BUILTIN\Users:(RX)
>     Everyone:(R)
> 
> If my understanding is correct concerning the precedence handling of an
> ACL with multiple ACEs for the same user/ID, this result from grep
> on the original, owning workstation would not surprise you:
> 
> F:\Dev\cygshoot>grep foo fileexp.txt
> grep: fileexp.txt: Permission denied
> 
> but it blows me completely away.  Clearly I no longer have an environment
> in which I can work on any file from any workstation using any Cygwin
> utilities.
> 
> What have I messed up?

The problem is that your identity is based on the SID of every single
machine, and the machines don't know the SIDs of other machines.  The
default ACL created in Cygwin is emulating POSIX permissions.  This
becomes a problem when sharing files between machines not in the
same Windows domain.

The workaround is not to use POSIX permissions on shares.  Create
matching mount points in /etc/fstab or /etc/fstab.d/ and add the
"noacl" mount flag:

  https://cygwin.com/cygwin-ug-net/using.html#mount-table

Alternatively, you can also just add an fstab entry for the cygdrive
prefix which adds the "noacl" flag, see

  https://cygwin.com/cygwin-ug-net/using.html#cygdrive

but keep in mind that this also affects local paths if you access
them via the cygdrive prefix.


HTH,
Corinna

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Additional odd behavior after my upgrade to the latest CYGWIN64 version

[Corinna Vinschen via Cygwin]

On Mar 16 16:49, Michael Goldshteyn via Cygwin wrote:
> Cygwin handles (filename) case insensitivity in a very weird way at the
> Windows command prompt:
> --
> c:\Users\Michael>set CYGWIN=
> 
> c:\Users\Michael>printf "%q " 'a' 'A' "a" "A" a A
> a A a A a A
> 
> REM OK, so far so good, but, now:
> c:\Users\Michael>set CYGWIN=glob:ignorecase
> 
> C:\Users\Michael>printf "%q " 'a' 'A' "a" "A" a A
> a a a a a A
> 
> REM So, if I don't put a command line arg into any sort of quotes, it gets
> lower-cased for cygwin apps (from the Windows command line).
> REM I should also add that there is no file named 'a' or 'A' in the current
> working directory.
> 
> REM This behavior, of course, doesn't happen in Cygwin bash:
> --
> C:\Users\Michael>bash
> Michael@lambda /cygdrive/c/Users/Michael
> $ echo "$CYGWIN"
> glob:ignorecase
> Michael@lambda /cygdrive/c/Users/Michael
> $ printf "%q " 'a' 'A' "a" "A" a A
> a A a A a A
> $ # Output looks correct, quoted or not
> --
> The unsolicited conversion of case for quoted string is very odd, to say
> the least. If you remove the glob:ignorecase from the CYGWIN env var
> definition, use of filenames on Windows with Cygwin tools becomes
> completely case sensitive, which is very undesirable when compared to the
> fact that other Windows tools do not care about file case (i.e., case
> insensitive, but preserving, as MS puts it).

This was an ill-advised optimization attempt in glob.  I revert the
patch and pushed the change(*), so this will be fixed in Cygwin 3.5.2.

For the time being, you can also test this by installing the just
building Cygwin test release 3.6.0-0.85.g89afbb8d8af2, which should
be available in an hour or two.


Thanks,
Corinna


(*) https://cygwin.com/cgit/newlib-cygwin/commit/?id=70375b2205

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH] winsup/cygwin/fhandler/proc.cc: format_proc_cpuinfo() Linux 6.8 cpuinfo flags

[Corinna Vinschen]

Hi Brian,

On Mar 16 10:44, Brian Inglis wrote:
> add Linux 6.8 cpuinfo flags:
> Intel 0x0007:1 eax:17 fredFlexible Return and Event 
> Delivery;
> AMD   0x801f   eax:4  sev_snp SEV secure nested paging;
> document unused and some unprinted bits that could look like omissions;
> fix typos and misalignments;

I'm a bit puzzled about the "unused" slots.  You're adding them
only in some places.  What makes them "look like omissions"?


Thanks,
Corinna

Re: Additional odd behavior after my upgrade to the latest CYGWIN64 version

[Andrey Repin via Cygwin]

Greetings, Michael Goldshteyn!

> Cygwin handles (filename) case insensitivity in a very weird way at the
> Windows command prompt:
> --
> c:\Users\Michael>set CYGWIN=

> c:\Users\Michael>printf "%q " 'a' 'A' "a" "A" a A
> a A a A a A

> REM OK, so far so good, but, now:
> c:\Users\Michael>set CYGWIN=glob:ignorecase

> C:\Users\Michael>printf "%q " 'a' 'A' "a" "A" a A
> a a a a a A

Oh, so THAT's what causing my git diff to disappear!

>> [C:\]$ set cyg
>> CYGWIN=wincmdln winsymlinks:native glob:ignorecase
>> CYGWIN_DIR=C:\Programs\Cygwin
>> CYGWIN_MIRROR=https://ftp-stud.hs-esslingen.de/pub/Mirrors/sources.redhat.com/cygwin
>>
>> [C:\]$ mintty -- git diff --minimal "--diff-filter=MAD" --find-renames=70 
>> --irreversible-delete HEAD --

>> # The actual executed command is:
>> git diff --minimal --diff-filter=mad --find-renames=70 --irreversible-delete 
>> HEAD --

I don't think that's how it is supposed to work.


-- 
With best regards,
Andrey Repin
Monday, March 18, 2024 12:06:56

Sorry for my terrible english...


-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple