Re: frequent hangs running ldd

[Mark Geisert via Cygwin]

On 5/24/2024 3:26 PM, Jeremy Drake via Cygwin wrote:

On Sat, 25 May 2024, Takashi Yano wrote:


On Fri, 24 May 2024 14:46:40 -0700 (PDT)
Jeremy Drake wrote:

Thanks for the report. However, I cannot reproduce the issue.
If it always hangs in GetConsoleProcessList (), I doubt it is not a cygwin
bug but a windows bug.

By any chance, is the number of processes that attach to the same pty more
than 32768 in your environment?



I doubt it, I was running a shell with this command:
find /usr/bin -name \*.dll -printf '%p:\n' -exec ldd '{}' \;


Thanks for the details. I could reproduce the issue.
It seems that ldh.exe (which is called from ldd?) falls into infinite loop.
However, gdb cannot attach to ldh.exe...



Windbg reports that ldh.exe is already being debugged.  I was able to do a
"non-invasive" attach to ldh.exe in windbg, but it doesn't seem to be able
to deal with the split debug symbols (gnulink?).  I don't know if gdb can
do a non-invasive attach like that (or open a minidump assuming one could
be made from a non-invasize attach in windbg).


ldd is the debugger of ldh. I found that Sysinternals Process Explorer 
can attach to ldh, show the threads, and can get stack backtraces which 
are refreshable. You have to convert addresses shown there into 
source-relevant addresses manually.


I'm bowing out for now as I think Takashi has a handle on this.
Cheers,

..mark


--
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: frequent hangs running ldd

[Mark Geisert via Cygwin]

On 5/24/2024 3:17 PM, Takashi Yano via Cygwin wrote:

On Fri, 24 May 2024 14:46:40 -0700 (PDT)
Jeremy Drake wrote:

Thanks for the report. However, I cannot reproduce the issue.
If it always hangs in GetConsoleProcessList (), I doubt it is not a cygwin
bug but a windows bug.

By any chance, is the number of processes that attach to the same pty more
than 32768 in your environment?



I doubt it, I was running a shell with this command:
find /usr/bin -name \*.dll -printf '%p:\n' -exec ldd '{}' \;


Thanks for the details. I could reproduce the issue.
It seems that ldh.exe (which is called from ldd?) falls into infinite loop.
However, gdb cannot attach to ldh.exe...


I could reproduce this too, even to not being able to attach gdb. If you 
exit that gdb session, I think you'll find the target process still 
stuck. You might be able to attach gdb again and it'll work. Here's what 
I found:


~ gdb -q /usr/bin/ldd
Reading symbols from /usr/bin/ldd...
Reading symbols from /usr/lib/debug//usr/bin/ldd.exe.dbg...
(gdb) att 6807
Attaching to program: /usr/bin/ldd, process 9732
[New Thread 9732.0x36a4]
[New Thread 9732.0x2bac]
(gdb) i thr
  Id   Target IdFrame
  1Thread 9732.0x31a8 "ldd" 0x7ff8524f0b04 in 
ntdll!ZwWaitForDebugEvent

() from /c/Windows/SYSTEM32/ntdll.dll
  2Thread 9732.0x36a4 "sig" 0x7ff8524ed174 in ntdll!ZwReadFile ()
   from /c/Windows/SYSTEM32/ntdll.dll
* 3Thread 9732.0x2bac   0x7ff8524f0be1 in ntdll!DbgBreakPoint ()
   from /c/Windows/SYSTEM32/ntdll.dll
(gdb) thr 1
[Switching to thread 1 (Thread 9732.0x31a8)]
#0  0x7ff8524f0b04 in ntdll!ZwWaitForDebugEvent ()
   from /c/Windows/SYSTEM32/ntdll.dll
(gdb) bt
#0  0x7ff8524f0b04 in ntdll!ZwWaitForDebugEvent ()
   from /c/Windows/SYSTEM32/ntdll.dll
#1  0x7ff850165796 in WaitForDebugEventEx ()
   from /c/Windows/System32/KERNELBASE.dll
#2  0x000100401ba1 in report (
in_fn=0x89200 "/usr/bin/cygdialog-14.dll",
multiple=multiple@entry=false)
at /usr/src/debug/cygwin-3.5.3-1/winsup/utils/ldd.cc:325
#3  0x0001004026de in main (argc=, argv=0xa04d0)
at /usr/src/debug/cygwin-3.5.3-1/winsup/utils/ldd.cc:439
(gdb) f 2
#2  0x000100401ba1 in report (
in_fn=0x89200 "/usr/bin/cygdialog-14.dll",
multiple=multiple@entry=false)
at /usr/src/debug/cygwin-3.5.3-1/winsup/utils/ldd.cc:325
325   if (!WaitForDebugEvent (, INFINITE))
(gdb) list
320
321   while (1)
322 {
323   bool exitnow = false;
324   DWORD cont = DBG_CONTINUE;
325   if (!WaitForDebugEvent (, INFINITE))
326 break;
327   switch (ev.dwDebugEventCode)
328 {
329 case CREATE_PROCESS_DEBUG_EVENT:
(gdb)

..mark

--
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: Technical reason why 32bit Cygwin cannot be installed on 64bit Windows?

[Mark Geisert via Cygwin]

Is there a technical reason why 32bit Cygwin cannot be installed on
64bit Windows?


https://cygwin.com/install.html has the following...

=A note about 32-bit Cygwin

=The limited address space of 32-bit Windows means that random failures 
=in the fork(2) system call are more likely. Therefore, we recommend 
=using 32-bit Cygwin only in limited scenarios, with only a minimum of 
=necessary packages installed, and only if there's no way to run 64-bit 
=Cygwin instead.


FWIW Although this wording seems to indicate Cygwin is still supported 
on 32-bit Windows, just discouraged, no Cygwin DLL since 3.3.6 has been 
released for 32-bit Windows.  Features of later Cygwin DLLs are unlikely 
to be backported.  I look forward (not) to future discussions about what 
merits a backport or updated release and who should be doing it.


..mark

--
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: util-linux-2.39.3-1: libblkid returns invalid physical_sector_size

[Mark Geisert via Cygwin]

On 4/2/2024 9:50 AM, Christian Franke via Cygwin wrote:

Christian Franke via Cygwin wrote:

,,,
BTW, according to the Linux kernel sources, BLKPBSZGET etc return 
'unsigned int' and not 'unsigned long' since first appearance in 
2.6.32-rc3 (2009?):


https://elixir.bootlin.com/linux/v2.6.32-rc3/source/block/ioctl.c#L276
https://elixir.bootlin.com/linux/v2.6.32-rc3/source/block/compat_ioctl.c#L743
https://elixir.bootlin.com/linux/v6.8.2/source/block/ioctl.c#L533

So I don't understand why the mentioned code would be correct for Linux.



It is likely an upstream regression from an 1+ year old commit. I filed 
a GH issue:

https://github.com/util-linux/util-linux/issues/2904


Thank you Christian for reporting the issue upstream.  I won't be able 
to try out the proposed fix in that issue 2904 as I'm about to be AFK 
for two weeks plus.  I will check in upon my return to keyboard.

Cheers & Regards,

..mark


--
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: Cygwin file prefetch, block sizes?

[Mark Geisert via Cygwin]

On 4/2/2024 3:35 PM, Martin Wege via Cygwin wrote:

On Tue, Apr 2, 2024 at 3:17 PM Corinna Vinschen via Cygwin
 wrote:


On Apr  2 02:04, Martin Wege via Cygwin wrote:

Hello,

Is there any document which describes how Cygwin and Win32 file
prefetch and readahead work, and which sizes are used (e.g. always
read one full page even if only 16 bytes are requested?)?


I'm not aware of any docs, but again, keep in mind that Cygwin is a
usersapce DLL. We basically do what Windows does for low-level file
access.


Quick /usr/bin/stat /etc/profile returns "IO Block: 65536". Does that
mean the file's block size is really 64k? Is this info per filesystem,
or hardcoded in Cygwin?


Hardcoded in Cygwin since 2017, based on a discussion in terms of
file access performance, especially when using stdio.h functions:

   https://cygwin.com/cgit/newlib-cygwin/commit/?id=7bef7db5ccd9c


OUCH.

While I can understand the motivation, FAT32 on multi-GB-devices
having 64k block size, and Win32 API on Win95/98/ME/Win7 being
optimized to that insane block size, it is absolutely WRONG with
today's NTFS and even more so with ReFS. This only works if you stream
files, but as soon as you are doing random read/writes the performance
is terrible due to cache thrashing. That could explain the many
complaints about Cygwin's IO performance.


No comment.


So, what can be done? I'm not a benchmarking guru, so I'd like to
propose to add a tunable called EXPERIMENTAL_PREFERRED_IO_BLKSIZE to
the CYGWIN env variable (marked as "experimental"), so the
benchmarking guys can do performance testing without recompiling
everything, get perf results for Cygwin 3.6, and decide what to do for
Cygwin 3.7.


That kind of experiment is what folks who can build their own 
cygwin1.dll might do.  I doubt we'd want to make a run-time global disk 
I/O strategy changer available like this, even temporarily.


What could make sense is enhancing Cygwin's posix_fadvise() to support 
POSIX_FADV_RANDOM getting mapped to Windows' FILE_RANDOM_ACCESS flag.
Something like this is currently done for POSIX_FADV_SEQUENTIAL -> 
FILE_SEQUENTIAL_ONLY.  These are per-filedescriptor adjustments and due 
to Windows limitations would apply to a whole file rather than having 
the POSIX behavior of being settable for a byte range within a file.


SHTDI, PTC, and all that :-).

..mark


--
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

Updated: util-linux 2.39.3-2

[Mark Geisert]

The following packages have been uploaded to the Cygwin distribution:

* util-linux-2.39.3-2
* util-linux-debuginfo-2.39.3-2
* libblkid-devel-2.39.3-2
* libblkid1-2.39.3-2
* libfdisk-devel-2.39.3-2
* libfdisk1-2.39.3-2
* libsmartcols-devel-2.39.3-2
* libsmartcols1-2.39.3-2
* libuuid-devel-2.39.3-2
* libuuid1-2.39.3-2
* uuidd-2.39.3-2

This rebuild adds a patch suggested by Christian Franke in
https://cygwin.com/pipermail/cygwin/2024-March/255772.html
to correct the output of Cygwin's /sbin/fdisk.exe.

..mark
--
 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: util-linux-2.39.3-1: libblkid returns invalid physical_sector_size

[Mark Geisert via Cygwin]

Hi Christian,

On 3/31/2024 1:11 AM, Christian Franke via Cygwin wrote:

Testcase:

# cygcheck -f /sbin/fdisk.exe
util-linux-2.39.3-1

# /sbin/fdisk.exe -l /dev/sdd
Disk /dev/sdd: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 34359738880 bytes
I/O size (minimum/optimal): 34359738880 bytes / 34359738880 bytes

[...valuable investigation and patch suggestion elided...]

Your suggested patch looks fine to me.  I have added it to the patch 
deck for a new util-linux 2.39.3-2, which has just been uploaded.  The 
patch allows fdisk.exe to report the three correct values in my limited 
testing.

Thanks for the report and the patch!

..mark


--
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

util-linux 2.39.3-1

[Mark Geisert]

Package util-linux 2.39.3-1 has been upgraded from test to current.

..mark

--
 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: Unable to 'git push' to /git/cygwin-packages/*

[Mark Geisert via Cygwin-apps]

On 3/14/2024 11:26 AM, Corinna Vinschen via Cygwin-apps wrote:
[...]


You may also want to use https:// rather than git:// for reading
the repository these days, given the insecurity of the git protocol.


Right. I now remember this recommendation too. I will make the change in 
all the git configs for my projects.

Thanks much,

..mark

Re: Unable to 'git push' to /git/cygwin-packages/*

[Mark Geisert via Cygwin-apps]

On 3/14/2024 9:07 AM, Jon Turney via Cygwin-apps wrote:

On 14/03/2024 15:39, Mark Geisert via Cygwin-apps wrote:

On 3/14/2024 2:42 AM, Jon Turney via Cygwin-apps wrote:

On 14/03/2024 05:45, Mark Geisert via Cygwin-apps wrote:

Hi folks,
I'm getting the error:

fatal: remote error: service not enabled: /git/cygwin-packages/sshfs

when I attempt 'git push' to that repository.  The same happens with 
all the repositories for my packages.  It's been this way for a 
couple days at least.


Have I forgotten some step in the connection at my end?  I'm running 
ssh-agent.



[...]

What is the repository URL you are trying to push to (git remote -v)?


/usr/src/upstaging/sshfs git remote -v
origin git://cygwin.com/git/cygwin-packages/sshfs (fetch)
origin git://cygwin.com/git/cygwin-packages/sshfs (push)


This maybe looks like pilot error.

We don't allow pushing using the git:// protocol (since this protocol 
doesn't do any authorization, pushes with a it are very rarely enabled)



I suggest you need to do

   git push 
ssh://cyg...@cygwin.com:git/cygwin-packages/sshfs


to push successfully.

If that works, I suggest you memorialize that by doing

   git remote set-url origin --push 
ssh://cyg...@cygwin.com:git/cygwin-packages/sshfs


which will cause git to automatically use the ssh URL with a simple 'git 
push'.


With a minor correction ("/git" instead of "git" in the URL) this works 
fine.  I've made the git config change for all my projects.



You might like to review the last time we discussed this at [1]

(Note that's slightly different, as to push to cygwin-apps repositories 
you must present the key as 
yourusername-rdbxbdvo6bxqt0dzr+a...@public.gmane.org, whereas for 
cygwin-packages repositories, you can present the key as 
cygwin-rdbxbdvo6bwxj1p+fo2...@public.gmane.org There are just different 
due to historical reasons.)


[1] https://cygwin.com/pipermail/cygwin-apps/2021-September/041539.html


Thanks very much, Jon.

..mark

Re: Unable to 'git push' to /git/cygwin-packages/*

[Mark Geisert via Cygwin-apps]

On 3/14/2024 2:42 AM, Jon Turney via Cygwin-apps wrote:

On 14/03/2024 05:45, Mark Geisert via Cygwin-apps wrote:

Hi folks,
I'm getting the error:

fatal: remote error: service not enabled: /git/cygwin-packages/sshfs

when I attempt 'git push' to that repository.  The same happens with 
all the repositories for my packages.  It's been this way for a couple 
days at least.


Have I forgotten some step in the connection at my end?  I'm running 
ssh-agent.


This is probably due to some recent changes made on sourceware. 
Apologies for the inconvenience.


What is the repository URL you are trying to push to (git remote -v)?


/usr/src/upstaging/sshfs git remote -v
origin  git://cygwin.com/git/cygwin-packages/sshfs (fetch)
origin  git://cygwin.com/git/cygwin-packages/sshfs (push)

and likewise for packages cygfuse, util-linux, inkscape.
Thanks much, Jon!

..mark

Unable to 'git push' to /git/cygwin-packages/*

[Mark Geisert via Cygwin-apps]

Hi folks,
I'm getting the error:

fatal: remote error: service not enabled: /git/cygwin-packages/sshfs

when I attempt 'git push' to that repository.  The same happens with all 
the repositories for my packages.  It's been this way for a couple days at 
least.


Have I forgotten some step in the connection at my end?  I'm running 
ssh-agent.

Thanks for any advice,

..mark

Re: /usr/bin/fallocate -v -d -l 2 myfile takes forever

[Mark Geisert via Cygwin]

On 3/5/2024 2:43 AM, Mark Geisert via Cygwin wrote:

On 3/5/2024 12:46 AM, Cedric Blancher via Cygwin wrote:
On Mon, 29 Jan 2024 at 10:46, Mark Geisert via Cygwin 
 wrote:


On 1/28/2024 11:56 PM, Mark Geisert via Cygwin wrote:

On 1/28/2024 10:44 PM, Cedric Blancher via Cygwin wrote:

Good morning!

rm -f myfile
touch myfile
/usr/bin/fallocate -v -d -l myfile takes forever with latest Cygwin 
3.5

   ^ length goes here, before filename

I believe you need to
  chattr +S myfile
after the 'touch' to make the file sparsifiable.

Also, I'm unsure if '-d' makes sense when initially allocating a sparse
file.  If I leave it off, fallocate does the right thing.

I'm separately investigating the 'takes forever' report.


It's taking forever because it's in an infinite loop looking for data
followed by a hole, which is not present in a new file being created.
This is due to the '-d' option being specified.  fallocate ought to
diagnose this condition rather than looping forever, but here we are.

It's possible we have an old fallocate from an old util-linux package.
I'll try to investigate this further when I have time.



Any update on this issue?


Thanks for the reminder. I'll check repology to see if we can maybe 
support a newer util-linux. No guarantees its fallocate is any better, 
but lets first see if it builds at all. Give me a couple days, please.


A newer util-linux package has been uploaded. I find that its fallocate 
operates identically to the earlier one for your example.  So, to 
summarize, when allocating a brand new file:

  1) don't specify '-d' option,
  2) after creating file with 'touch', do 'chattr +S' on it,
  3) using fallocate on the file without step 2 won't sparsify it.

It's easier to see fallocate is working properly by giving it a file 
size large enough to make a difference by sparsifying. My testing shows 
that specifying '-l 2m' to create a 2MB file makes the file occupy 64 
blocks if it's sparsified, 2048 blocks if it isn't. Use 'stat ' to 
get the block size of the file. 'ls -l' will show 2MB either way.

HTH,

..mark


--
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

Updated: util-linux 2.39.3-1 (test)

[Mark Geisert via Cygwin]

The following packages have been uploaded to the Cygwin distribution:

* util-linux-2.39.3-1
* util-linux-debuginfo-2.39.3-1
* libblkid-devel-2.39.3-1
* libblkid1-2.39.3-1
* libfdisk-devel-2.39.3-1
* libfdisk1-2.39.3-1
* libsmartcols-devel-2.39.3-1
* libsmartcols1-2.39.3-1
* libuuid-devel-2.39.3-1
* libuuid1-2.39.3-1
* uuidd-2.39.3-1

This brings Cygwin's util-linux up to a recent version that many Linux 
distributions still package.


I would appreciate feedback from any users who can install this test 
version and make sure fallocate, more, script, whereis, rename, or any of 
the other programs that make up the util-linux package work properly. 
Thank you,


..mark

--
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

Updated: util-linux 2.39.3-1 (test)

[Mark Geisert]

The following packages have been uploaded to the Cygwin distribution:

* util-linux-2.39.3-1
* util-linux-debuginfo-2.39.3-1
* libblkid-devel-2.39.3-1
* libblkid1-2.39.3-1
* libfdisk-devel-2.39.3-1
* libfdisk1-2.39.3-1
* libsmartcols-devel-2.39.3-1
* libsmartcols1-2.39.3-1
* libuuid-devel-2.39.3-1
* libuuid1-2.39.3-1
* uuidd-2.39.3-1

This brings Cygwin's util-linux up to a recent version that many Linux 
distributions still package.


I would appreciate feedback from any users who can install this test 
version and make sure fallocate, more, script, whereis, rename, or any of 
the other programs that make up the util-linux package work properly. 
Thank you,


..mark
--
 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: Native posix_spawn() in Cygwin?

[Mark Geisert via Cygwin]

On 3/5/2024 2:42 PM, Dan Shelton via Cygwin wrote:

On Mon, 4 Mar 2024 at 07:45, Mark Geisert via Cygwin  wrote:


On 3/3/2024 7:27 PM, Dan Shelton via Cygwin wrote:

[...]

strace does not help, as I need the Win32 calls BELOW posix_spawn(),
to see the implementation details.


Check the source code, then. It's at:
  https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/fork.cc

Look at line 587; there's the static function dofork(). Look at the
thirty or so lines above that; there's both fork() and
__posix_spawn_fork() calling dofork(). So both those user-level
functions call into the exact same internals. (BTW __posix_spawn_fork()
is called from posix_spawn(); the latter is in newlib and not Cygwin.)

You can even see the reason it's done this way by reading the comment.


Yes, but it is as I feared, Cygwin posix_spawn() does not use Win32
spawn() at all, and instead uses a rather inefficient vfork()
solution.


Cygwin's vfork() is just a wrapper around fork(), so yes. But anyway...


posix_spawn() was added to POSIX so a Win32 implementation can use Win32 spawn()


...now I see what you're getting at:

If posix_spawn() is intended to launch truly unrelated processes, with 
minimal or no coordination with the launching process, why can't it just 
use Windows' CreateProcess? I assume here that's what Win32 spawn() does.


That's an interesting research question for somebody. If somebody steps 
up for that, great, otherwise as usual PTC.

Regards,

..mark


--
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: /usr/bin/fallocate -v -d -l 2 myfile takes forever

[Mark Geisert via Cygwin]

On 3/5/2024 12:46 AM, Cedric Blancher via Cygwin wrote:

On Mon, 29 Jan 2024 at 10:46, Mark Geisert via Cygwin  wrote:


On 1/28/2024 11:56 PM, Mark Geisert via Cygwin wrote:

On 1/28/2024 10:44 PM, Cedric Blancher via Cygwin wrote:

Good morning!

rm -f myfile
touch myfile
/usr/bin/fallocate -v -d -l myfile takes forever with latest Cygwin 3.5

   ^ length goes here, before filename

I believe you need to
  chattr +S myfile
after the 'touch' to make the file sparsifiable.

Also, I'm unsure if '-d' makes sense when initially allocating a sparse
file.  If I leave it off, fallocate does the right thing.

I'm separately investigating the 'takes forever' report.


It's taking forever because it's in an infinite loop looking for data
followed by a hole, which is not present in a new file being created.
This is due to the '-d' option being specified.  fallocate ought to
diagnose this condition rather than looping forever, but here we are.

It's possible we have an old fallocate from an old util-linux package.
I'll try to investigate this further when I have time.



Any update on this issue?


Now that I've reviewed the whole email thread, I don't believe we ever 
received feedback from you on whether leaving off the '-d' option and 
doing the 'chattr +S' made any difference.


..mark


--
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: /usr/bin/fallocate -v -d -l 2 myfile takes forever

[Mark Geisert via Cygwin]

On 3/5/2024 12:46 AM, Cedric Blancher via Cygwin wrote:

On Mon, 29 Jan 2024 at 10:46, Mark Geisert via Cygwin  wrote:


On 1/28/2024 11:56 PM, Mark Geisert via Cygwin wrote:

On 1/28/2024 10:44 PM, Cedric Blancher via Cygwin wrote:

Good morning!

rm -f myfile
touch myfile
/usr/bin/fallocate -v -d -l myfile takes forever with latest Cygwin 3.5

   ^ length goes here, before filename

I believe you need to
  chattr +S myfile
after the 'touch' to make the file sparsifiable.

Also, I'm unsure if '-d' makes sense when initially allocating a sparse
file.  If I leave it off, fallocate does the right thing.

I'm separately investigating the 'takes forever' report.


It's taking forever because it's in an infinite loop looking for data
followed by a hole, which is not present in a new file being created.
This is due to the '-d' option being specified.  fallocate ought to
diagnose this condition rather than looping forever, but here we are.

It's possible we have an old fallocate from an old util-linux package.
I'll try to investigate this further when I have time.



Any update on this issue?


Thanks for the reminder. I'll check repology to see if we can maybe 
support a newer util-linux. No guarantees its fallocate is any better, 
but lets first see if it builds at all. Give me a couple days, please.


..mark



--
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: Convert a file descriptor from Cygwin openat() to Win32 file HANDLE?

[Mark Geisert via Cygwin]

On 3/3/2024 10:16 PM, Cedric Blancher via Cygwin wrote:


How can I convert a file descriptor from Cygwin openat() to Win32 file HANDLE?


In general, this can be done with:
hFile = (HANDLE) _get_osfhandle (int fd);

That works for simple cases such as disk file descriptors. I've learned 
one can't always depend on it because Cygwin can use several handles for 
a specific file or other object in certain situations, which I'm not 
going to list here because I don't know them all.


Try that and see if it works for your case.

..mark

--
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: Native posix_spawn() in Cygwin?

[Mark Geisert via Cygwin]

On 3/3/2024 7:27 PM, Dan Shelton via Cygwin wrote:

On Tue, 27 Feb 2024 at 07:34,  wrote:


On Tue, Feb 27, 2024 at 06:54:42AM +0100, Dan Shelton via Cygwin wrote:

On Tue, 27 Feb 2024 at 06:47, Brian Inglis via Cygwin  wrote:


On 2024-02-26 20:23, Dan Shelton via Cygwin wrote:

Does Cygwin implement a native, i.e. without form(),exec(), implementation of 
posix_spawn()?


Check the API compatibility docs online:

 https://cygwin.com/cygwin-api/compatibility.html#std-susv4

or optional locally installed package cygwin-doc:

 /usr/share/doc/cygwin-doc/html/cygwin-api/compatibility.html#std-susv4


That document does not answer my question.

I know posix_spawn() is there. But the question is: Does it use just
Cygwin fork(),exec(), or the native Win32 spawn() api?

Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd


If you were going to make a small effort to answer the question
yourself, you could use strace, you could step through a debugger, or
you could check the source code.  Have you tried any of these?  What did
you find?  If you are unable to take any of those steps, why does
posix_spawn() matter to you?


strace does not help, as I need the Win32 calls BELOW posix_spawn(),
to see the implementation details.


Check the source code, then. It's at:
https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/fork.cc

Look at line 587; there's the static function dofork(). Look at the
thirty or so lines above that; there's both fork() and 
__posix_spawn_fork() calling dofork(). So both those user-level
functions call into the exact same internals. (BTW __posix_spawn_fork() 
is called from posix_spawn(); the latter is in newlib and not Cygwin.)


You can even see the reason it's done this way by reading the comment.

..mark

--
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: Can util-linux 2.33.1-3 come out of [test] ?

[Mark Geisert via Cygwin]

On 2/2/2024 3:52 AM, Bruce Jerrick via Cygwin wrote:

util-linux 2.33.1-3 depends on cygwin >= 3.5.0 .  The latter has come
out of test, so can util-linux 2.33.1-3 also come out of test?


Done. Note that this means if you select util-linux 2.33.1-3 for 
installation, your Cygwin version will also be upgraded to 3.5.0 unless 
you take measures to prevent it in your setup interactions.


..mark


--
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: /usr/bin/fallocate -v -d -l 2 myfile takes forever

[Mark Geisert via Cygwin]

On 1/28/2024 11:56 PM, Mark Geisert via Cygwin wrote:

On 1/28/2024 10:44 PM, Cedric Blancher via Cygwin wrote:

Good morning!

rm -f myfile
touch myfile
/usr/bin/fallocate -v -d -l myfile takes forever with latest Cygwin 3.5

  ^ length goes here, before filename

I believe you need to
     chattr +S myfile
after the 'touch' to make the file sparsifiable.

Also, I'm unsure if '-d' makes sense when initially allocating a sparse 
file.  If I leave it off, fallocate does the right thing.


I'm separately investigating the 'takes forever' report.


It's taking forever because it's in an infinite loop looking for data 
followed by a hole, which is not present in a new file being created. 
This is due to the '-d' option being specified.  fallocate ought to 
diagnose this condition rather than looping forever, but here we are.


It's possible we have an old fallocate from an old util-linux package. 
I'll try to investigate this further when I have time.


..mark


--
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: /usr/bin/fallocate -v -d -l 2 myfile takes forever

[Mark Geisert via Cygwin]

On 1/28/2024 10:44 PM, Cedric Blancher via Cygwin wrote:

Good morning!

rm -f myfile
touch myfile
/usr/bin/fallocate -v -d -l myfile takes forever with latest Cygwin 3.5

 ^ length goes here, before filename

I believe you need to
chattr +S myfile
after the 'touch' to make the file sparsifiable.

Also, I'm unsure if '-d' makes sense when initially allocating a sparse 
file.  If I leave it off, fallocate does the right thing.


I'm separately investigating the 'takes forever' report.

..mark


--
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

Request for import of git repository history

[Mark Geisert via Cygwin-apps]

Hi folks,
I'm finally getting around to setting up the centralized git repositories 
for the packages I maintain.


There is currently no history for the cygutils package. Could I please 
have its history imported with ctm2git?

Thanks much,

..mark

Re: /usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...

[Mark Geisert via Cygwin]

On 1/27/2024 7:47 AM, Marco Atzeri via Cygwin wrote:

On 27/01/2024 11:06, Mark Geisert via Cygwin wrote:

On 1/26/2024 11:26 PM, ASSI via Cygwin wrote:

Mark Geisert via Cygwin writes:

A new build of the util-linux package, 2.33.1-3, now includes
fallocate and its man page.  The updated package is now making its way
to the Cygwin mirrors.  fallocate requires Cygwin version >= 3.5.0.


It also doesn't work at all on Cygwin 3.4.x and 3.5 isn't yet released,
so please add a dependency for cygwin(>= 3.5) to the hints file.


Done. I guess you answered my unasked question of how to limit one 
executable of a package to specific Cygwin version(s): you don't. You 
limit the whole package instead?

Thanks & Regards,

..mark



yes but put it as test, otherwise Setup will pull cygwin-3.5.0


Done. Thanks for the info Marco.

..mark


--
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: /usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...

[Mark Geisert via Cygwin]

On 1/26/2024 11:26 PM, ASSI via Cygwin wrote:

Mark Geisert via Cygwin writes:

A new build of the util-linux package, 2.33.1-3, now includes
fallocate and its man page.  The updated package is now making its way
to the Cygwin mirrors.  fallocate requires Cygwin version >= 3.5.0.


It also doesn't work at all on Cygwin 3.4.x and 3.5 isn't yet released,
so please add a dependency for cygwin(>= 3.5) to the hints file.


Done. I guess you answered my unasked question of how to limit one 
executable of a package to specific Cygwin version(s): you don't. You 
limit the whole package instead?

Thanks & Regards,

..mark


--
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: /usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...

[Mark Geisert via Cygwin]

On 1/23/2024 4:41 PM, Mark Geisert via Cygwin wrote:

On 1/23/2024 3:36 AM, Roland Mainz via Cygwin wrote:

Small bug report:
Cygwin 3.5. now has support for SEEK_HOLE (thanks! :-) ), but
/usr/bin/fallocate is still missing in the "util-linux" package.

Can someone please enable that tool ?


I'll look into this.


A new build of the util-linux package, 2.33.1-3, now includes fallocate 
and its man page.  The updated package is now making its way to the 
Cygwin mirrors.  fallocate requires Cygwin version >= 3.5.0.

Enjoy,

..mark


--
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

Updated: util-linux 2.33.1-3

[Mark Geisert]

The following packages have been uploaded to the Cygwin distribution:

* util-linux-2.33.1-3
* util-linux-debuginfo-2.33.1-3
* libblkid-devel-2.33.1-3
* libblkid1-2.33.1-3
* libfdisk-devel-2.33.1-3
* libfdisk1-2.33.1-3
* libsmartcols-devel-2.33.1-3
* libsmartcols1-2.33.1-3
* libuuid-devel-2.33.1-3
* libuuid1-2.33.1-3
* uuidd-2.33.1-3

The only changes in this spin are a new executable 'fallocate' and its man 
page.  Fallocate requires Cygwin 3.5.0 or later.


..mark
--
 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: /usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...

[Mark Geisert via Cygwin]

On 1/23/2024 3:36 AM, Roland Mainz via Cygwin wrote:

Small bug report:
Cygwin 3.5. now has support for SEEK_HOLE (thanks! :-) ), but
/usr/bin/fallocate is still missing in the "util-linux" package.

Can someone please enable that tool ?


I'll look into this.

..mark


--
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: [NMU] inkscape 0.92.3-2 (Test)

[Mark Geisert via Cygwin-apps]

This test version of inkscape has been promoted to current.

Apologies to JonT who probably has to help this through again.
Next time I do this will be after I ITA the thing.
Thanks & Regards,

..mark

Re: Unmaintained packages in base package set

[Mark Geisert via Cygwin-apps]

Marco Atzeri via Cygwin-apps wrote:

Is anyone looking at QT5 and QT6 ?


I've "looked at" Qt5 in the past, though not to the point of being able to take it 
over.  I have a patch for the qterminal issue that I'd like to contribute. 
There's issues I've had building this I haven't had the time to resolve or even 
ask about.  Not sure I've tried since Achim last did some work on it.


I haven't looked at Qt6 at all.

Marco, if you've got an itch to see either/both of these through, be my guest as 
far as I'm concerned.


Meanwhile, I'm looking over the Unmaintained list too with some interest.
Regards,

..mark

Re: [NMU] inkscape 0.92.3-2 (Test)

[Mark Geisert via Cygwin-apps]

ASSI via Cygwin-apps wrote:

Mark Geisert via Cygwin-apps writes:

I've uploaded a non-maintainer re-build of the existing inkscape
0.92.3. This attempts to work around a problem with the current
inkscape reported to exit with 127 error code (missing DLL).  This
build was produced with gcc-g++ 7.4 while the current build was
produced with gcc-g++ 6.4.  Newer gcc-g++ releases fail to build
inkscape due to C++ include file evolution.


Since apparently you can compile it with that compiler on an otherwise
current release of Cygwin (I assume), you should be able to request a
previous C++ or G++ standard version and have the current compiler do
the same?  The baseline for gcc-6 until gcc-10 has been C++14 and gcc-11
switched to C++17.  You should also check that the compiler is detected
correctly, there are some configure scripts that fail to take higher
version numbers (esp. double digits for the main gcc version) correctly into
account and then set bogus options.  Inkscape shouldn't have been using
C++11 until 0.93, so the appropriate standard to invoke is probably
C++98 (or thew GNU variant thereof).


Thanks much, Achim, for pointing out that additional dimension. That should help 
with my future builds and/or ITA.


..mark

Re: inkscape installed but does nothing --- solved to my satisfaction

[Mark Geisert via Cygwin]

Hi John,

J.F. Huesman via Cygwin wrote:
[...]

If I call inkscape -V from the prompt, I get an error:(inkscape:1451): 
Gtk-WARNING **: 07:07:30.361: cannot open display: :0


Inkscape is expecting a running X server to display on.  But even for "-V"?  That 
seems a little presumptuous :-).



But if I run inscape on a file to convert the format:inkscape -f testfile.svg 
-e testfile.pngit executes without any error.

When I run my script, it starts with this message:** (inkscape:1422): WARNING 
**: 07:02:30.339: No cc:license metadata found, derived license URI from 
cc:License: http://creativecommons.org/publicdomain/zero/1.0/but the script 
runs and the png output is generated for all *.svg in the folder as expected, 
so I don't care about a warning message.


I haven't seen this; I'll look into it for later.  Glad inkscape now works for 
your use case.  I appreciate the feedback!

Cheers,

..mark


--
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: [NMU] inkscape 0.92.3-2 (Test)

[Mark Geisert via Cygwin-apps]

Hi Jon,

Jon Turney via Cygwin-apps wrote:

On 30/11/2023 00:38, Mark Geisert via Cygwin-apps wrote:
Not sure of the logistical process for doing a non-maintainer update. If I've 
missed something please let me know.

>

Thanks very much for looking into this.


You're welcome.  It was a curious report on the main list and I got hooked.

So, this is all a bit ad-hoc at the moment, but only certain ("trusted") 
  maintainers are currently allowed to do NMUs.


Oops.


If you have ideas about how to make things work better, I'm all ears.

For the moment, I tweaked things to let your upload through.


Thanks Jon.  I have only seen a handful of NMUs go by and it didn't occur to me 
that those doing them were explicitly allowed to.


ISTM the process works fine as it is.  If I happen to have a future itch to do an 
NMU should I handle it as I did this one?  Or say something on cygwin-apps 
beforehand?  I don't expect it will be often.  I'm totally fine not being on the 
"trusted" list for this type of thing.

Thanks,

..mark

Re: inkscape installed but does nothing

[Mark Geisert via Cygwin]

Mark Geisert via Cygwin wrote:
I've found that Cygwin's latest inkscape 0.92.3 cannot be built with either 
gcc-g++ 11.4 or 11.2.  There are incompatibilities with recent C++ include files. 
Inkscape *can* be built with gcc-g++ 7.4; that version even seems to run okay.


So it seems that without finding and installing an intervening gcc-g++ I probably 
cannot build an inkscape that shows the OP's issue for its investigative value: 
building okay but not runnable.


In the meantime I will work towards an NMU (non-maintainer update) of inkscape 
using the gcc-g++ that works... hopefully in the next couple of days or so.


I have uploaded a re-build of inkscape that seems to avoid the issue reported by 
the OP, namely inkscape exiting without doing anything (with exit code 127).


Could the OP please try installing this updated inkscape, shown as 0.92.3-2 (Test) 
in the Cygwin setup app.  Being a test build, setup will not automatically update 
from an older inkscape; you have to manually select the test version from the 
"New" dropdown within setup.


Kindly let us know if that fixes your original issue and/or has any new issues 
when you have a chance.  Thanks for reporting the original issue.

Enjoy,

..mark

--
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

Updated: inkscape 0.92.3-2 (Test)

[Mark Geisert]

I've uploaded a non-maintainer re-build of the existing inkscape 0.92.3. 
This attempts to work around a problem with the current inkscape reported 
to exit with 127 error code (missing DLL entry).


This build was produced with gcc-g++ 7.4 while the current build was 
produced with gcc-g++ 6.4.  Newer gcc-g++ releases than these fail to 
build our existing inkscape due to C++ include file evolution.


The only changes in this test build were to the cygport file:
- inherit python3 rather than 'python'
- supply a BUILD_REQUIRES containing most if not all requirements

..mark
--
 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

[NMU] inkscape 0.92.3-2 (Test)

[Mark Geisert via Cygwin-apps]

I've uploaded a non-maintainer re-build of the existing inkscape 0.92.3. 
This attempts to work around a problem with the current inkscape reported 
to exit with 127 error code (missing DLL).  This build was produced with 
gcc-g++ 7.4 while the current build was produced with gcc-g++ 6.4.  Newer 
gcc-g++ releases fail to build inkscape due to C++ include file evolution.


The only changes in this test build were to the cygport file:
- include python3 rather than 'python'
- supply a BUILD_REQUIRES containing most if not all requirements

Not sure of the logistical process for doing a non-maintainer update.  If 
I've missed something please let me know.  I might consider doing an ITA 
if I have luck with this... we'll see.

Thanks,

..mark

Kindly update my SSH public key

[Mark Geisert via Cygwin-apps]

Name: Mark Geisert
 BEGIN SSH2 PUBLIC KEY 
Comment: "256-bit ED25519, converted by Mark@zotac from OpenSSH"
C3NzaC1lZDI1NTE5IP1ks1stdrx1ofmpCBnQWdJ2zt9qlnNqrCX0y15INZHf
 END SSH2 PUBLIC KEY 

Re: inkscape installed but does nothing

[Mark Geisert via Cygwin]

Mark Geisert via Cygwin wrote:
I'm now going through the laborious process of building inkscape on my test system 
to see if the same issue happens with my build.  I'll give an update when I have 
something to report.


I've found that Cygwin's latest inkscape 0.92.3 cannot be built with either 
gcc-g++ 11.4 or 11.2.  There are incompatibilities with recent C++ include files. 
Inkscape *can* be built with gcc-g++ 7.4; that version even seems to run okay.


So it seems that without finding and installing an intervening gcc-g++ I probably 
cannot build an inkscape that shows the OP's issue for its investigative value: 
building okay but not runnable.


In the meantime I will work towards an NMU (non-maintainer update) of inkscape 
using the gcc-g++ that works... hopefully in the next couple of days or so.


..mark

--
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: inkscape installed but does nothing

[Mark Geisert via Cygwin]

Hi John,

J.F. Huesman via Cygwin wrote:

[...my previous info about reproducing the issue elided here...]

I get those same error codes (of course the process ID and thread numbers are 
different).exception 139 indicates, I think, a missing required file or link. 
Maybe it's an issue with the cygwin64 installer (setup-x86_64.exe) not 
including all the necessary files?
The exception occurs at 7ffaecf324f6 on both our traces, so I grep'd it and 
that address only occurs in that line, so it's no help (at least not to me) 
trying to identify what program could be missing.
This is the list I found of required packages for inkscape:
- curl.
- openssh.
- openssl (Net)
- php.
- php-curl.
- php-json.
- php-phar (PHP)

curl and php (all four) weren't installed. I installed them and made sure 
openssh and openssl were the most recent versions.
Sadly, I get the exact same error list at the end of the strace output.
I'll go through the list of dependencies on the inkscape package summary page. 
Hopefully it's something in that list that didn't get installed by the updater.
Thanks for the guidance. John


Good to hear my experience duplicates yours.  The info I wrote really was intended 
for somebody who knows inkscape internals on Cygwin, i.e., its maintainer or 
somebody like him/her.  But I later discovered our inkscape is orphaned, so I'm 
digging a little deeper now.


It's not a file that's missing from your system.  It has to do with how inkscape 
was built.  One part (or library maybe) of the program refers to some function(s) 
that is/are supposed to be supplied by another part (or library maybe) as the 
program is starting up.  But it/they aren't supplied.  Windows notices this and 
raises an exception to kill the program.


I'm now going through the laborious process of building inkscape on my test system 
to see if the same issue happens with my build.  I'll give an update when I have 
something to report.

Cheers,

..mark

--
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: inkscape installed but does nothing.

[Mark Geisert via Cygwin]

FWIW I can reproduce the issue.  See below...

René Berber via Cygwin wrote:

On 11/22/2023 10:27 PM, J.F. Huesman via Cygwin wrote:


(I tried to reply to this message twice and got mailer-daemon failure
notices both times. My apologies if this is a duplicate message.) Yes, they are 
installed. which xwin xinit/usr/bin/xwin/usr/bin/xinit


When I try to run inkscape, I don't get any errors and there were no
messages about missing programs or dependencies when I ran the
installer. I'm not trying to start a GUI. I have a script that I used
to batch convert svg images in a folder to png. When that script
wouldn't work (I've used it on other machines, including this one
years ago using 32-bit cygwin instead of 64-bit that I'm using now) I
started trying to invoke it from the command line, and that's when I
discovered it's not doing anything. If I start Cygwin64 WindowMaker
and type "inkscape" into the right-click run dialogue, I get a popup
window, ErrorCould not execute command: inkscape


OK, then start from the basics:

$ ldd $(which inkscape)

Look at the output.  Is any dll shown as missing?

In the answer is no, then next check your anti-virus.  Is it blocking the program? 
Is it injecting a dll?


Another set of tests would be, is the program installed correctly? i.e. is it 
executable? Is not corrupt? A bit more difficult: is it loading libraries into 
valid space (non colliding, in available memory).


I installed inkscape and tried running the .exe.  It returns to shell prompt but 
its exit code is 127, indicating a problem starting the process up.  ldd doesn't 
show anything amiss; as an aside that's an unusually long list of DLLs.


I ran 'strace -o inkscape.out inkscape -V' and looked at the traced output.
It ends with:

--- Process 11940 (pid: 11940), exception c139 at 7ffaecf324f6
--- Process 11940 (pid: 11940) thread 1172 exited with status 0xc139
--- Process 11940 (pid: 11940) thread 1888 exited with status 0xc139
--- Process 11940 (pid: 11940) thread 5544 exited with status 0xc139
--- Process 11940 (pid: 11940) exited with status 0xc139

I grep'd /usr/include/w32api/ntstatus.h for that status and got:
#define STATUS_ENTRYPOINT_NOT_FOUND ((NTSTATUS)0xC139)

I then tried running inkscape.exe from a Command Prompt window and got a popup:
"The procedure entry point g_cclosure_marshal_VOID__BOOLEAN could not be located
in the dynamic link library C:\cygwin64\bin\inkscape.exe."

Why this happens, I leave to somebody experienced with building inkscape itself.
HTH,

..mark

--
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

[PATCH v2] Fix profiler error() definition and usage

[Mark Geisert]

Minor updates to profiler and gmondump, which share some code:
- fix operation of error() so it actually works as intended
- resize 4K-size auto buffer reservations to BUFSIZ (==1K)
- remove trailing '\n' from 2nd arg on error() calls everywhere
- provide consistent annotation of Windows error number displays

Fixes: 9887fb27f6126 ("Cygwin: New tool: profiler")
Fixes: 087a3d76d7335 ("Cygwin: New tool: gmondump")
Signed-off-by: Mark Geisert 

---
 winsup/cygwin/release/3.4.10 |  3 +++
 winsup/utils/gmondump.c  |  8 ---
 winsup/utils/profiler.cc | 46 +++-
 3 files changed, 32 insertions(+), 25 deletions(-)

diff --git a/winsup/cygwin/release/3.4.10 b/winsup/cygwin/release/3.4.10
index ec28cdf7e..641c82647 100644
--- a/winsup/cygwin/release/3.4.10
+++ b/winsup/cygwin/release/3.4.10
@@ -9,3 +9,6 @@ Bug Fixes
 
 - Let feraiseexcept actually raise an exception.
   Addresses: https://cygwin.com/pipermail/cygwin/2023-October/254667.html
+
+- Updates to profiler and gmondump: error display mechanics, buffer sizing,
+  and output formatting.
diff --git a/winsup/utils/gmondump.c b/winsup/utils/gmondump.c
index 16b99594a..3472a147e 100644
--- a/winsup/utils/gmondump.c
+++ b/winsup/utils/gmondump.c
@@ -58,7 +58,7 @@ void
 note (const char *fmt, ...)
 {
   va_list args;
-  charbuf[4096];
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
   vsprintf (buf, fmt, args);
@@ -72,7 +72,7 @@ void
 warn (int geterrno, const char *fmt, ...)
 {
   va_list args;
-  charbuf[4096];
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
   sprintf (buf, "%s: ", pgm);
@@ -92,10 +92,12 @@ void __attribute__ ((noreturn))
 error (int geterrno, const char *fmt, ...)
 {
   va_list args;
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
-  warn (geterrno, fmt, args);
+  vsprintf (buf, fmt, args);
   va_end (args);
+  warn (geterrno, "%s", buf);
 
   exit (1);
 }
diff --git a/winsup/utils/profiler.cc b/winsup/utils/profiler.cc
index 520e29d12..b5ce16cf2 100644
--- a/winsup/utils/profiler.cc
+++ b/winsup/utils/profiler.cc
@@ -130,7 +130,7 @@ void
 note (const char *fmt, ...)
 {
   va_list args;
-  charbuf[4096];
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
   vsprintf (buf, fmt, args);
@@ -144,7 +144,7 @@ void
 warn (int geterrno, const char *fmt, ...)
 {
   va_list args;
-  charbuf[4096];
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
   sprintf (buf, "%s: ", pgm);
@@ -164,10 +164,12 @@ void __attribute__ ((noreturn))
 error (int geterrno, const char *fmt, ...)
 {
   va_list args;
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
-  warn (geterrno, fmt, args);
+  vsprintf (buf, fmt, args);
   va_end (args);
+  warn (geterrno, "%s", buf);
 
   exit (1);
 }
@@ -263,15 +265,15 @@ start_profiler (child *c)
 note ("*** start profiler thread on pid %lu\n", (ulong) c->pid);
   c->context = (CONTEXT *) calloc (1, sizeof (CONTEXT));
   if (!c->context)
-error (0, "unable to allocate CONTEXT buffer\n");
+error (0, "unable to allocate CONTEXT buffer");
   c->context->ContextFlags = CONTEXT_CONTROL;
   c->hquitevt = CreateEvent (NULL, TRUE, FALSE, NULL);
   if (!c->hquitevt)
-error (0, "unable to create quit event\n");
+error (0, "unable to create quit event");
   c->profiling = 1;
   c->hprofthr = CreateThread (NULL, 0, profiler, (void *) c, 0, );
   if (!c->hprofthr)
-error (0, "unable to create profiling thread\n");
+error (0, "unable to create profiling thread");
 
   /* There is a temptation to raise the execution priority of the profiling
* threads.  Don't do this, or at least don't do it this way.  Testing
@@ -321,7 +323,7 @@ dump_profile_data (child *c)
 
   fd = open (filename, O_CREAT | O_TRUNC | O_WRONLY | O_BINARY);
   if (fd < 0)
-error (0, "dump_profile_data: unable to create %s\n", filename);
+error (0, "dump_profile_data: unable to create %s", filename);
 
   memset (, 0, sizeof (hdr));
   hdr.lpc = s->textlo;
@@ -427,7 +429,7 @@ add_thread (DWORD pid, DWORD tid, HANDLE h, WCHAR *name)
   child *c = get_child (pid);
 
   if (!c)
-error (0, "add_thread: pid %lu not found\n", (ulong) pid);
+error (0, "add_thread: pid %lu not found", (ulong) pid);
 
   thread_list *t = (thread_list *) calloc (1, sizeof (thread_list));
   t->tid = tid;
@@ -444,7 +446,7 @@ remove_thread (DWORD pid, DWORD tid)
   child *c = get_child (pid);
 
   if (!c)
-error (0, "remove_thread: pid %lu not found\n", (ulong) pid);
+error (0, "remove_thread: pid %lu not found", (ulong) pid);
 
   thread_list *t = c->threads;
   while (t)
@@ -463,7 +465,7 @@ remove_thread (DWORD pid, DWORD tid)
   t = t->next;
 }
 
-  error (0, "remove_thread: pid %lu tid %lu not found\n",
+  error 

Re: [PATCH] Cygwin: Fix profiler error() definition and usage

[Mark Geisert]

Hi Corinna,

On Mon, 13 Nov 2023, Corinna Vinschen wrote:

On Nov 13 01:46, Mark Geisert wrote:

Minor updates to profiler and gmondump, which share some code:
- fix operation of error() so it actually works as intended
- resize 4K-size auto buffer reservations to BUFSIZ (==1K)
- remove trailing '\n' from 2nd arg on error() calls everywhere
- provide consistent annotation of Windows error number displays

Fixes: 9887fb27f6126 ("Cygwin: New tool: profiler")
Fixes: 087a3d76d7335 ("Cygwin: New tool: gmondump")
Signed-off-by: Mark Geisert 


Looks good basically, but I noticed some minor problem already
in the former version of this code:


@@ -650,7 +652,7 @@ ctrl_c (DWORD)
   static int tic = 1;

   if ((tic ^= 1) && !GenerateConsoleCtrlEvent (CTRL_C_EVENT, 0))
-error (0, "couldn't send CTRL-C to child, win32 error %d\n",
+error (0, "couldn't send CTRL-C to child, Windows error %d",
GetLastError ());
   return TRUE;


GetLastError returns a DWORD == unsigned int. %u would be the
right format specifier.  Care to fix that, too?


Thanks for catching this.  Patch v2 is incoming, and it includes a
relnote for 3.4.10.
Cheers & Regards,

..mark

[PATCH] Cygwin: Fix profiler error() definition and usage

[Mark Geisert]

Minor updates to profiler and gmondump, which share some code:
- fix operation of error() so it actually works as intended
- resize 4K-size auto buffer reservations to BUFSIZ (==1K)
- remove trailing '\n' from 2nd arg on error() calls everywhere
- provide consistent annotation of Windows error number displays

Fixes: 9887fb27f6126 ("Cygwin: New tool: profiler")
Fixes: 087a3d76d7335 ("Cygwin: New tool: gmondump")
Signed-off-by: Mark Geisert 

---
 winsup/utils/gmondump.c  |  8 ---
 winsup/utils/profiler.cc | 46 +---
 2 files changed, 29 insertions(+), 25 deletions(-)

diff --git a/winsup/utils/gmondump.c b/winsup/utils/gmondump.c
index 16b99594a..3472a147e 100644
--- a/winsup/utils/gmondump.c
+++ b/winsup/utils/gmondump.c
@@ -58,7 +58,7 @@ void
 note (const char *fmt, ...)
 {
   va_list args;
-  charbuf[4096];
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
   vsprintf (buf, fmt, args);
@@ -72,7 +72,7 @@ void
 warn (int geterrno, const char *fmt, ...)
 {
   va_list args;
-  charbuf[4096];
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
   sprintf (buf, "%s: ", pgm);
@@ -92,10 +92,12 @@ void __attribute__ ((noreturn))
 error (int geterrno, const char *fmt, ...)
 {
   va_list args;
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
-  warn (geterrno, fmt, args);
+  vsprintf (buf, fmt, args);
   va_end (args);
+  warn (geterrno, "%s", buf);
 
   exit (1);
 }
diff --git a/winsup/utils/profiler.cc b/winsup/utils/profiler.cc
index 520e29d12..b2e26d663 100644
--- a/winsup/utils/profiler.cc
+++ b/winsup/utils/profiler.cc
@@ -130,7 +130,7 @@ void
 note (const char *fmt, ...)
 {
   va_list args;
-  charbuf[4096];
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
   vsprintf (buf, fmt, args);
@@ -144,7 +144,7 @@ void
 warn (int geterrno, const char *fmt, ...)
 {
   va_list args;
-  charbuf[4096];
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
   sprintf (buf, "%s: ", pgm);
@@ -164,10 +164,12 @@ void __attribute__ ((noreturn))
 error (int geterrno, const char *fmt, ...)
 {
   va_list args;
+  charbuf[BUFSIZ];
 
   va_start (args, fmt);
-  warn (geterrno, fmt, args);
+  vsprintf (buf, fmt, args);
   va_end (args);
+  warn (geterrno, "%s", buf);
 
   exit (1);
 }
@@ -263,15 +265,15 @@ start_profiler (child *c)
 note ("*** start profiler thread on pid %lu\n", (ulong) c->pid);
   c->context = (CONTEXT *) calloc (1, sizeof (CONTEXT));
   if (!c->context)
-error (0, "unable to allocate CONTEXT buffer\n");
+error (0, "unable to allocate CONTEXT buffer");
   c->context->ContextFlags = CONTEXT_CONTROL;
   c->hquitevt = CreateEvent (NULL, TRUE, FALSE, NULL);
   if (!c->hquitevt)
-error (0, "unable to create quit event\n");
+error (0, "unable to create quit event");
   c->profiling = 1;
   c->hprofthr = CreateThread (NULL, 0, profiler, (void *) c, 0, );
   if (!c->hprofthr)
-error (0, "unable to create profiling thread\n");
+error (0, "unable to create profiling thread");
 
   /* There is a temptation to raise the execution priority of the profiling
* threads.  Don't do this, or at least don't do it this way.  Testing
@@ -321,7 +323,7 @@ dump_profile_data (child *c)
 
   fd = open (filename, O_CREAT | O_TRUNC | O_WRONLY | O_BINARY);
   if (fd < 0)
-error (0, "dump_profile_data: unable to create %s\n", filename);
+error (0, "dump_profile_data: unable to create %s", filename);
 
   memset (, 0, sizeof (hdr));
   hdr.lpc = s->textlo;
@@ -427,7 +429,7 @@ add_thread (DWORD pid, DWORD tid, HANDLE h, WCHAR *name)
   child *c = get_child (pid);
 
   if (!c)
-error (0, "add_thread: pid %lu not found\n", (ulong) pid);
+error (0, "add_thread: pid %lu not found", (ulong) pid);
 
   thread_list *t = (thread_list *) calloc (1, sizeof (thread_list));
   t->tid = tid;
@@ -444,7 +446,7 @@ remove_thread (DWORD pid, DWORD tid)
   child *c = get_child (pid);
 
   if (!c)
-error (0, "remove_thread: pid %lu not found\n", (ulong) pid);
+error (0, "remove_thread: pid %lu not found", (ulong) pid);
 
   thread_list *t = c->threads;
   while (t)
@@ -463,7 +465,7 @@ remove_thread (DWORD pid, DWORD tid)
   t = t->next;
 }
 
-  error (0, "remove_thread: pid %lu tid %lu not found\n",
+  error (0, "remove_thread: pid %lu tid %lu not found",
  (ulong) pid, (ulong) tid);
 }
 
@@ -475,9 +477,9 @@ read_child (void *buf, SIZE_T size, void *addr, HANDLE h)
   if (debugging)
 note ("read %d bytes at %p from handle %d\n", size, addr, h);
   if (0 == ReadProcessMemory (h, addr, buf, size, ))
-error (0, "read_child: failed\n");
+error (0, "read_child: failed");
   if (len != size)
-error (0, "read_

Re: Which git hash to supply on Fixes: line -- never mind

[Mark Geisert]

On Sun, 12 Nov 2023, Mark Geisert wrote:

Hi folks,
I want to submit a patch that fixes 'profiler'.  The Fixes: line of the patch 
commentary should reference the original addition of profiler to the Cygwin 
source tree.


Using the gitweb interface, the commit display of profiler.cc shows:
authorMark Geisert   2021-07-15 21:49:55 -0700
committer Jon Turney  2021-07-19 13:28:37 +0100
commit  9bd6c0b2b1081ae72d8273038309887fb27f6126 (patch)
tree360d7d3cc748683eb9e63729a7e52a62012730e4 /winsup/utils/profiler.cc
parent  Cygwin: cfsetspeed: allow speed to be a numerical baud rate (diff)

Do I use the last 13 nibbles of the "commit" hash or the "tree" hash?


Never mind; I've figured it out.  It's the "commit" hash, which I 
determined by 'git log profiler.cc'.  Obvious in hindsight.

Cheers,

..mark

Which git hash to supply on Fixes: line

[Mark Geisert]

Hi folks,
I want to submit a patch that fixes 'profiler'.  The Fixes: line of the 
patch commentary should reference the original addition of profiler to the 
Cygwin source tree.


Using the gitweb interface, the commit display of profiler.cc shows:
authorMark Geisert   2021-07-15 21:49:55 -0700
committer Jon Turney  2021-07-19 13:28:37 +0100
commit  9bd6c0b2b1081ae72d8273038309887fb27f6126 (patch)
tree360d7d3cc748683eb9e63729a7e52a62012730e4 /winsup/utils/profiler.cc
parent  Cygwin: cfsetspeed: allow speed to be a numerical baud rate (diff)

Do I use the last 13 nibbles of the "commit" hash or the "tree" hash?

First time I've seen both; on previous patches I've supplied a hash but 
I'm not sure which one of these they were because I was relying on some 
other method to find them.

Thanks,

..mark

Re: Qt6 in Cygwin?

[Mark Geisert via Cygwin]

Mark Geisert via Cygwin wrote:



Are there Qt6 - https://www.qt.io/product/qt6 - packages for Cygwin available?


Does setup.exe show it/them as a choice?  No?  No they aren't available.  We could 
use a maintainer for Qt.  Check the Cygwin home page for how to contribute.


Now that I think about it, the package search on the Cygwin home page might be 
faster to check for availability of random packages:


https://cygwin.com/packages/

Just put "Qt6" in the search box (without the quotes) and get a response.

..mark

--
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: Qt6 in Cygwin?

[Mark Geisert via Cygwin]

Are there Qt6 - https://www.qt.io/product/qt6 - packages for Cygwin available?


Does setup.exe show it/them as a choice?  No?  No they aren't available.  We could 
use a maintainer for Qt.  Check the Cygwin home page for how to contribute.


..mark

--
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: Run a Cygwin process with "higher" scheduler priority

[Mark Geisert via Cygwin]

Cedric Blancher via Cygwin wrote:

On Fri, 11 Aug 2023 at 19:14, Brian Inglis  wrote:


On 2023-08-11 09:44, Cedric Blancher via Cygwin wrote:

How can we set the scheduler priority for a Cygwin process to "higher"
than normal on start?

Basically we want a Cygwin compatible script version of the Windows
task manager feature Name/PID--->Details--->Set priority--->Higher


Pretend the system is BSD or Linux and web search e.g. SO for that capability,
facility, or feature, then check Cygwin with Search Packages or:

$ cygcheck -p usr/bin/nice
Found 6 matches for usr/bin/nice


I know about nice and renice, but I don't see whether it is working or not.


OFGS Why not try the command?  If it doesn't seem to do anything then try the 
command with the '-h' or '--help' option.  Or maybe try the canonical doc 'man 
nice'.  You shouldn't always need our help with stuff like this.


..mark

--
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: EXTERNAL SENDER: Re: Fork errors

[Mark Geisert via Cygwin]

Hi Dale,
Something appears to be adding cruft to your outgoing emails.. links to 
urldefense.com that don't work (from outside your workplace maybe) and clutter up 
the Cygwin email archives.  Can you turn that off somehow?  More below...


Dale Lobb via Cygwin wrote:

-Original Message-
From: Cygwin 
On Behalf Of Mark Geisert via Cygwin
Sent: Wednesday, September 6, 2023 6:32 PM
To: Cygwin Mailing List 
Subject: EXTERNAL SENDER: Re: Fork errors

Dale Lobb via Cygwin wrote:

Since upgrading to the latest version of Cygwin a few weeks ago on a

server I manage, I've been experiencing an issue with fork errors.  The
Cygwin installation had not been updated for almost a year before that.


The issue happens every time a script is invoked that purges files from

some temporary directories, but never in the same place in the script.  The
script uses multiple calls to find -exec to remove files over 10 days old from
the directories.  Here is a typical error.  Sometime the issue will assert after
just a  few tens of files deleted, sometimes after hundreds or thousands of
files have been deleted:


  removed '/cygdrive/d/.../obfuscated.datedata.txt'
1 [main] find 20066 dofork: child -1 - forked process 4068 died

unexpectedly, retry 0, exit code 0xC142, errno 11

find: cannot fork: Resource temporarily unavailable

It also happens randomly at other times.  I've seen the bash shell itself 
fail

on the invocation of a mintty.  I've seen it happen on all sorts of interactive
commands entered from bash.


Today, as a test, I updated all the installed Cygwin components.  One of

the post installation scripts failed, so I re-exec'd it:


  $ ./postinstall/0p_update-info-dir.dash
  Rebuilding info directory
  2 [main] dash 2059 dofork: child -1 - forked process 7676 died

unexpectedly, retry 0, exit code 0xC142, errno 11

  ./postinstall/0p_update-info-dir.dash: 22: Cannot fork

A second re-exec then worked fine.

I've tried reinstalling all the components, and I've tried rebaseall.

Is there anything else I can try, or troubleshooting steps to take?


Try the FAQ, specifically
https://urldefense.com/v3/__https://cygwin.com/faq.html*faq.using.fixing-
fork-
failures__;Iw!!PI4dZuVR!iMEVdwUomDN3L1KOsOWkDMmUhiuXarkAyjI6itT-
BSJ5bcjg65VVWHdP7U5Ny2VaBilIz9R3o6SkMqX3$


Example #1 of added cruft above.  Something appears to be rewriting URLs for 
"safety".



Pay attention to the subtleties of running rebaseall, e.g. make sure no Cygwin
processes (background server processes or whatnot) are running.  When the
FAQ gets
to talking about running setup.exe for this situation, it means close any open
Cygwin shell windows and manually run the Cygwin Setup program, just
taking its
defaults all the way through; you needn't install anything it suggests at this
time.  The object is to get to Setup's end where it runs a full rebase.

Speculation: The specific exit code 0xC142 may or may not have
something to do
with Windows error 142, which is ERROR_BUSY_DRIVE.  I cannot help further
on this.


As corrected by another poster, it's hex 142 == decimal 322 == 
ERROR_DEVICE_NO_RESOURCES.




..mark




CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,

is for the sole use of the intended recipients and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.

P.S. You've sent your post to a public mailing list so the above notice does not
apply.  Obfuscate your system particulars if that's a problem.


Can you eliminate this confidentiality notice from your emails to the Cygwin 
mailing list?




--
Problem reports:
https://urldefense.com/v3/__https://cygwin.com/problems.html__;!!PI4dZu
VR!iMEVdwUomDN3L1KOsOWkDMmUhiuXarkAyjI6itT-
BSJ5bcjg65VVWHdP7U5Ny2VaBilIz9R3o_fDJhhS$
FAQ:
https://urldefense.com/v3/__https://cygwin.com/faq/__;!!PI4dZuVR!iMEVd
wUomDN3L1KOsOWkDMmUhiuXarkAyjI6itT-
BSJ5bcjg65VVWHdP7U5Ny2VaBilIz9R3o5GKnVUD$
Documentation:
https://urldefense.com/v3/__https://cygwin.com/docs.html__;!!PI4dZuVR!i
MEVdwUomDN3L1KOsOWkDMmUhiuXarkAyjI6itT-
BSJ5bcjg65VVWHdP7U5Ny2VaBilIz9R3o2A6MIc4$
Unsubscribe info:
https://urldefense.com/v3/__https://cygwin.com/ml/*unsubscribe-
simple__;Iw!!PI4dZuVR!iMEVdwUomDN3L1KOsOWkDMmUhiuXarkAyjI6itT-
BSJ5bcjg65VVWHdP7U5Ny2VaBilIz9R3o4OJCuT7$


Examples #2-#5 of added cruft above.


Hi Mark, thanks for the reply!

   I ran though the rebase-trigger process as outlined in the FAQ.
Unfortunately,  there was no difference afterwards.

   One good thing about reading the FAQ, it lead me to
"/usr/share/doc/rebase/README" which has the parameters for the
rebaseall command.  I'm thinking about running rebaseall manually with a
different base addr

Re: [PATCH] Cygwin: Fix __cpuset_zero_s prototype

[Mark Geisert]

Mark Geisert wrote, and then wrote again:

Corinna Vinschen wrote:

On Sep  7 22:36, Mark Geisert wrote:

Add a missing "void" to the prototype for __cpuset_zero_s().

Reported-by: Marco Mason 
Addresses: https://cygwin.com/pipermail/cygwin/2023-September/254423.html
Signed-off-by: Mark Geisert 
Fixes: c6cfc99648d6 (Cygwin: sys/cpuset.h: add cpuset-specific external 
functions)


Thanks, can you also add an entry to the 3.4.10 release file
(which doesn't exist yet), please?


Done. Here's a link:
https://cygwin.com/pipermail/cygwin/2023-September/254423.html


D'oh again!  Here's the correct link.  Sorry for the continuing noise.
https://cygwin.com/pipermail/cygwin-patches/2023q3/012481.html

..mark

Re: [PATCH] Cygwin: Fix __cpuset_zero_s prototype

[Mark Geisert]

Corinna Vinschen wrote:

On Sep  7 22:36, Mark Geisert wrote:

Add a missing "void" to the prototype for __cpuset_zero_s().

Reported-by: Marco Mason 
Addresses: https://cygwin.com/pipermail/cygwin/2023-September/254423.html
Signed-off-by: Mark Geisert 
Fixes: c6cfc99648d6 (Cygwin: sys/cpuset.h: add cpuset-specific external 
functions)


Thanks, can you also add an entry to the 3.4.10 release file
(which doesn't exist yet), please?


Done. Here's a link:
https://cygwin.com/pipermail/cygwin/2023-September/254423.html
Cheers,

..mark

[PATCH] Cygwin: Add relnote to 3.4.10 release file

[Mark Geisert]

Document the most recent update to include/sys/cpuset.h.

---
 winsup/cygwin/release/3.4.10 | 5 +
 1 file changed, 5 insertions(+)
 create mode 100644 winsup/cygwin/release/3.4.10

diff --git a/winsup/cygwin/release/3.4.10 b/winsup/cygwin/release/3.4.10
new file mode 100644
index 0..f34b131b3
--- /dev/null
+++ b/winsup/cygwin/release/3.4.10
@@ -0,0 +1,5 @@
+Bug Fixes
+-
+
+- Fix missing term in __cpuset_zero_s() prototoype in sys/cpuset.h.
+  Addresses: https://cygwin.com/pipermail/cygwin/2023-September/254423.html
-- 
2.39.0

[PATCH] Cygwin: Fix __cpuset_zero_s prototype

[Mark Geisert]

Add a missing "void" to the prototype for __cpuset_zero_s().

Reported-by: Marco Mason 
Addresses: https://cygwin.com/pipermail/cygwin/2023-September/254423.html
Signed-off-by: Mark Geisert 
Fixes: c6cfc99648d6 (Cygwin: sys/cpuset.h: add cpuset-specific external 
functions)

---
 winsup/cygwin/include/sys/cpuset.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/cygwin/include/sys/cpuset.h 
b/winsup/cygwin/include/sys/cpuset.h
index a5a8fa81e..3d0874880 100644
--- a/winsup/cygwin/include/sys/cpuset.h
+++ b/winsup/cygwin/include/sys/cpuset.h
@@ -48,7 +48,7 @@ void __cpuset_free (cpu_set_t *);
 
 /* These _S macros operate on dynamically-sized cpu sets of size 'siz' bytes */
 #define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
-static __inline
+static __inline void
 __cpuset_zero_s (__size_t siz, cpu_set_t *set)
 {
 #if __GNUC_PREREQ (2, 91)
-- 
2.39.0

Re: [pkg cygwin-devel] /usr/include/sys/cpuset.h:52 error: missing return type

[Mark Geisert via Cygwin]

Hi Marco,

Marco Mason via Cygwin wrote:

I just updated to 3.4.9-1 and compiled some code, and it complained about
cpuset.h.
Specifically, "C++ requires a type specifier for all declarations", and
sure enough, there's no return type on line 52.  So I changed my local copy
to the following, and it cleared things up:

#define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
static __inline /*MCM*/ void /*MCM*/
__cpuset_zero_s (__size_t siz, cpu_set_t *set)
{


Thanks for the report; right you are.


I looked at a couple mailing list archives and saw that the cpuset.h header
was worked on recently, but couldn't track it down any closer.  I also
tried to find a git repository so I could find the commit so I could check
for similar errors on other headers, but couldn't find the repo for
cygwin-devel anywhere.


This error was introduced with the most recent update to cpuset.h.  There is a 
public-visible mirror of the Cygwin tree at

https://github.com/cygwin/cygwin/blob/main/winsup/cygwin
and the problematic file can be found at
include/sys/cpuset.h
within.

Your bug report and proposed correction are all we need for the issue you ran 
into.  I'll submit a patch shortly.

Thanks again,

..mark

--
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: Fork errors

[Mark Geisert via Cygwin]

Bill Stewart via Cygwin wrote:

On Wed, Sep 6, 2023 at 5:32 PM Mark Geisert wrote:
Speculation: The specific exit code 0xC142 may or may not have

something to do
with Windows error 142, which is ERROR_BUSY_DRIVE.  I cannot help further
on this.


Correction: The low word of 0xC142 = hex 142 = decimal 322 =
ERROR_DEVICE_NO_RESOURCES ("The target device has insufficient resources to
complete the operation").


D'oh! Tnx for correction.

..mark

--
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: Fork errors

[Mark Geisert via Cygwin]

Dale Lobb via Cygwin wrote:

   Since upgrading to the latest version of Cygwin a few weeks ago on a server 
I manage, I've been experiencing an issue with fork errors.  The Cygwin 
installation had not been updated for almost a year before that.

   The issue happens every time a script is invoked that purges files from some 
temporary directories, but never in the same place in the script.  The script 
uses multiple calls to find -exec to remove files over 10 days old from the 
directories.  Here is a typical error.  Sometime the issue will assert after 
just a  few tens of files deleted, sometimes after hundreds or thousands of 
files have been deleted:

 removed '/cygdrive/d/.../obfuscated.datedata.txt'
   1 [main] find 20066 dofork: child -1 - forked process 4068 died 
unexpectedly, retry 0, exit code 0xC142, errno 11
   find: cannot fork: Resource temporarily unavailable

   It also happens randomly at other times.  I've seen the bash shell itself 
fail on the invocation of a mintty.  I've seen it happen on all sorts of 
interactive commands entered from bash.

   Today, as a test, I updated all the installed Cygwin components.  One of the 
post installation scripts failed, so I re-exec'd it:

 $ ./postinstall/0p_update-info-dir.dash
 Rebuilding info directory
 2 [main] dash 2059 dofork: child -1 - forked process 7676 died 
unexpectedly, retry 0, exit code 0xC142, errno 11
 ./postinstall/0p_update-info-dir.dash: 22: Cannot fork

   A second re-exec then worked fine.

   I've tried reinstalling all the components, and I've tried rebaseall.

   Is there anything else I can try, or troubleshooting steps to take?


Try the FAQ, specifically
https://cygwin.com/faq.html#faq.using.fixing-fork-failures

Pay attention to the subtleties of running rebaseall, e.g. make sure no Cygwin 
processes (background server processes or whatnot) are running.  When the FAQ gets 
to talking about running setup.exe for this situation, it means close any open 
Cygwin shell windows and manually run the Cygwin Setup program, just taking its 
defaults all the way through; you needn't install anything it suggests at this 
time.  The object is to get to Setup's end where it runs a full rebase.


Speculation: The specific exit code 0xC142 may or may not have something to do 
with Windows error 142, which is ERROR_BUSY_DRIVE.  I cannot help further on this.


..mark




CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipients and may contain confidential and 
privileged information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, please 
contact the sender by reply e-mail and destroy all copies of the original 
message.


P.S. You've sent your post to a public mailing list so the above notice does not 
apply.  Obfuscate your system particulars if that's a problem.


--
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: posix thread scaling issue

[Mark Geisert via Cygwin]

Sorry, I mis-spoke in my previous post...

Mark Geisert via Cygwin wrote:

  Briefly, you can't move a 
thread
outside the processor group it's currently in; you have to move its process to the 
new group first.


That's backward.  You can't add a process to multiple processor groups or move it 
from one group to another.  You can, however, move a process's threads one-by-one 
to a different processor group.


I'm now recalling how hair-pulling it was to get this correct when coding it.
Cheers,

..mark

--
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: posix thread scaling issue

[Mark Geisert via Cygwin]

Hi folks,

Brian Inglis via Cygwin wrote:

On 2023-09-02 12:27, jeff via Cygwin wrote:

[...]
When I run cinebench, I can get to 100% cpu utulization (at around 3ghz) on 
windows.


Chances are the benchmark is designed to handle that:

"When the program is running inside the group, unless it is processor group aware, 
then it can only access other threads in the same group. This means that if a 
multi-threaded program can use 128 threads, if it isn’t built with processor 
groups in mind, then it might only spawn with access to 64."


I also do not know how you would program for that in Cygwin to map onto the 
equivalent Windows function required.


Perhaps one of the developers involved could comment here?


Cygwin doesn't know (at user level) about processor groups as that's a Windows 
construct.  Cygwin does know about processor affinity and treats all available 
processors as a contiguous set, like Linux does, up to 1024 in size.  One uses 
'taskset' from the util-linux package to assign processes to specific processor(s).


One can deal with thread affinity using pthread_get_affinity_np() and 
pthread_set_affinity_np() functions provided by the Cygwin DLL.  These are modeled 
after the same-named functions in Linux.  The internals of these functions do have 
to work within the Windows processor group constraints, so not all plausible 
set-affinity operations are allowed by Windows.  Briefly, you can't move a thread 
outside the processor group it's currently in; you have to move its process to the 
new group first.

HTH,

..mark

--
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: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Mark Geisert via Cygwin-apps]

Corinna Vinschen via Cygwin-apps wrote:

On Sep  1 03:28, Mark Geisert via Cygwin-apps wrote:

I then tried recompiling a CPU affinity test program of mine (that uses
cpusets) but it could not link due to missing __cpuset_alloc and
__cpuset_free.  I think this is likely a local issue of mine in copying
newly-built stuff into place, though I've automated that process and do it
frequently, so...  ?


You missed to copy libcygwin.a to /usr/lib.


That's what I thought at first as well.  However nm showed the __cpuset_* 
functions present in the newly-created libcygwin.a.  Did I mis-copy the new lib 
somewhere incorrect?  Nope.  It turned out I had stale files in 
/usr/x86_64-pc-cygwin/lib that's evidently earlier in the link search path than 
the directory with newest contents.


I just renamed that directory out of the way and now the test program links and 
runs without issues.  I should investigate what populated that directory though.


I saw that you've applied your two patches.  Excellent!

..mark

Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Mark Geisert via Cygwin-apps]

Hi Corinna,

Corinna Vinschen via Cygwin-apps wrote:

On Aug 30 20:10, Corinna Vinschen via Cygwin-apps wrote:

On Aug 30 12:04, Brian Inglis via Cygwin-apps wrote:

On 2023-08-30 06:17, Corinna Vinschen via Cygwin-apps wrote:

On Aug 30 11:57, Corinna Vinschen via Cygwin-apps wrote:

On Aug 30 11:34, Corinna Vinschen via Cygwin-apps wrote:

   #define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
-static __inline void
-__cpuset_zero_s (size_t siz, cpu_set_t *set)
-{
-  (void) memset (set, 0, siz);
-}
+void __cpuset_zero_s (size_t, cpu_set_t *);
   [...]
+__cpuset_zero_s (size_t siz, cpu_set_t *set)
+{
+  (void) memset (set, 0, siz);
+}
+
   } /* extern C */


Also, we can avoid an external __cpuset_zero_s function by just using a
loop, kind of like this:


I attached a matching patch. Please give it a try.


Shouldn't cpuset.h #include  for size_t and  for pid_t?


It shouldn't need that. sys/cpuset.h is a non-standard header which is
only included indirectly via sys/types.h.

We may want to change from size_t to __size_t and from pid_t to __pid_t.
That should eliminate any further dependency.


Try this:


After applying both patches to my system I was able to build coreutils without 
issues.  After updating my local Cygwin tree's sched.cc and cygwin.din I rebuilt 
the Cygwin DLL without issues.


I then tried recompiling a CPU affinity test program of mine (that uses cpusets) 
but it could not link due to missing __cpuset_alloc and __cpuset_free.  I think 
this is likely a local issue of mine in copying newly-built stuff into place, 
though I've automated that process and do it frequently, so...  ?


I believe those two patches you wrote are fine.  Ship when convenient, I say.
Cheers & Regards,

..mark

Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Mark Geisert via Cygwin-apps]

Corinna Vinschen via Cygwin-apps wrote:

On Aug 30 11:57, Corinna Vinschen via Cygwin-apps wrote:

On Aug 30 11:34, Corinna Vinschen via Cygwin-apps wrote:

  #define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
-static __inline void
-__cpuset_zero_s (size_t siz, cpu_set_t *set)
-{
-  (void) memset (set, 0, siz);
-}
+void __cpuset_zero_s (size_t, cpu_set_t *);
  [...]
+__cpuset_zero_s (size_t siz, cpu_set_t *set)
+{
+  (void) memset (set, 0, siz);
+}
+
  } /* extern C */


Also, we can avoid an external __cpuset_zero_s function by just using a
loop, kind of like this:


I attached a matching patch. Please give it a try.


I like where this discussion is going.  Going to need another day to test..

..mark

Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Mark Geisert via Cygwin-apps]

[redirected from the main Cygwin ML]

Hi Corinna,

Corinna Vinschen via Cygwin wrote:

On Aug 25 22:50, Mark Geisert via Cygwin wrote:

Hi Corinna,

Corinna Vinschen via Cygwin wrote:

On Aug 24 14:39, Mark Geisert via Cygwin wrote:

Denis Excoffier via Cygwin wrote:

Hello,
When i try to compile coreutils-9.3 under cygwin-3.4.8 i get the following 
error messages (see below).
There seems to be a kind of loop in the hierarchy of #includes.


It is not a loop.


Moreover, with cygwin-3.4.7, this is ok. Also, if under cygwin-3.4.8 i 
removethe 2 #includes from /usr/include/sys/cpuset.h,
this is also ok.


This is an important clue.



Regards,

Denis Excoffier.


[...compilation log excerpt elided here...]


Usually it's easily fixable. There's typically no loop because
of the guards, e.g.

#ifndef _SYS_CPUSET_H_
#define _SYS_CPUSET_H_

but some guarding can have side effects.

However, somebody needs to come up *at least* with a simple reproducer.


It can be reproduced by running 'cygport coreutils.cygport build' in a
prep'd coreutils source directory e.g. /usr/src/coreutils-9.0-1.src .
Excerpt follows:


This is not what I meant.  A simple reproducer is ideally a piece of
C code which shows ;the problem with a minimum of code.  In this case,
a pice of C code with the #includes required to reproduce the compiler
failing is what I'm looking for.


I've always been supportive of the notion of STCs, but for this issue it would 
mean duplicating a bunch of coreutils-build-built include files (in its lib 
directory) and I decided, why not just cut the coreutils build process back to the 
first compilation that exhibits the error?


So I modified coreutils.cygport to change "cygmake" to "cygmake --trace" and ran 
'cygport build' to see all gcc commands as they're executed.  I then extracted the 
gcc command that compiles chroot.c to a new STC shell script where I could modify 
gcc options at will.  I changed "-c" to "-E" to see the sequence of include file 
usage and where #defines actually happen.


From this I discovered that pthread_attr_t and pthread_t defs are missing because 
sys/_pthreadtypes.h includes sys/cpuset.h which starts a whole include chain 
ending up in sys/signal.h where the defs are needed.  Note they are defined in 
sys/_pthreadtypes.h where we started, but haven't been seen yet because 
sys/cpuset.h has gone off on this detour.


Similarly, the timestruc_t def is missing because sys/_pthreadtypes.h again starts 
an include chain that ends up in sys/stat.h where the def is needed.  Note 
timestruc_t is defined in machine/types.h, which is included (by sys/types.h) 
after sys/_pthreadtypes.h, so the def hasn't been seen yet because of a similar 
detour.


The fix I'm considering is to
(1) move sys/_pthreadtypes.h's "#include sys/cpuset.h" to just before its final 
#endif, and
(2) exchange the positions of "#include " and "#include 
" within sys/types.h.

I could submit for review a patch to do these things.

An alternative would be to somehow massage the coreutils build 
include-file-wrapping to accomplish the same end.  I personally don't have the 
time or skills to figure that out.


I hope this info is usable in one form or another.
Regards,

..mark

Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Mark Geisert via Cygwin]

Corinna Vinschen via Cygwin wrote:

On Aug 25 22:50, Mark Geisert via Cygwin wrote:

Hi Corinna,

Corinna Vinschen via Cygwin wrote:

On Aug 24 14:39, Mark Geisert via Cygwin wrote:

Denis Excoffier via Cygwin wrote:

Hello,
When i try to compile coreutils-9.3 under cygwin-3.4.8 i get the following 
error messages (see below).
There seems to be a kind of loop in the hierarchy of #includes.
Moreover, with cygwin-3.4.7, this is ok. Also, if under cygwin-3.4.8 i remove 
the 2 #includes from /usr/include/sys/cpuset.h,
this is also ok.

Regards,

Denis Excoffier.


[...compilation log excerpt elided here...]


Usually it's easily fixable. There's typically no loop because
of the guards, e.g.

#ifndef _SYS_CPUSET_H_
#define _SYS_CPUSET_H_

but some guarding can have side effects.

However, somebody needs to come up *at least* with a simple reproducer.


It can be reproduced by running 'cygport coreutils.cygport build' in a
prep'd coreutils source directory e.g. /usr/src/coreutils-9.0-1.src .
Excerpt follows:


This is not what I meant.  A simple reproducer is ideally a piece of
C code which shows ;the problem with a minimum of code.  In this case,
a pice of C code with the #includes required to reproduce the compiler
failing is what I'm looking for.


I guess it's the include search order that has ./lib/stdlib.h being included
from sys/cpuset.h rather than the "" coded there.


That should break including any other header file, too, which includes
.  Why does it only break sys/cpuset.h?


I'm not familiar with building coreutils.  But it seems something about the
new #includes added to sys/cpuset.h have upset coreutils' build magic.  My
offer to replace the two problematic #includes with two explicit extern
statements still stands ;-).


Sorry, but this is not the right thing to do to fix such an issue.


Agreed.  Also, given the locus of this issue, coding an STC is problematic.  I'm 
taking this coreutils build issue to the cygwin-apps ML for further discussion.


..mark

--
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: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Mark Geisert via Cygwin]

Hi Corinna,

Corinna Vinschen via Cygwin wrote:

On Aug 24 14:39, Mark Geisert via Cygwin wrote:

Denis Excoffier via Cygwin wrote:

Hello,
When i try to compile coreutils-9.3 under cygwin-3.4.8 i get the following 
error messages (see below).
There seems to be a kind of loop in the hierarchy of #includes.
Moreover, with cygwin-3.4.7, this is ok. Also, if under cygwin-3.4.8 i remove 
the 2 #includes from /usr/include/sys/cpuset.h,
this is also ok.

Regards,

Denis Excoffier.


[...compilation log excerpt elided here...]


Usually it's easily fixable. There's typically no loop because
of the guards, e.g.

   #ifndef _SYS_CPUSET_H_
   #define _SYS_CPUSET_H_

but some guarding can have side effects.

However, somebody needs to come up *at least* with a simple reproducer.


It can be reproduced by running 'cygport coreutils.cygport build' in a prep'd 
coreutils source directory e.g. /usr/src/coreutils-9.0-1.src .  Excerpt follows:


make[3]: Entering directory 
'/usr/src/coreutils-9.0-1.src/coreutils-9.0-1.x86_64/build'

  CC   lib/exclude.o
  CC   lib/exitfail.o
  CC   lib/fadvise.o
  CC   lib/creat-safer.o
In file included from /usr/include/sys/signal.h:23,
 from /usr/include/signal.h:6,
 from ./lib/signal.h:52,
 from /usr/include/time.h:158,
 from ./lib/time.h:47,
 from ./lib/sys/stat.h:44,
 from ./lib/fcntl.h:64,
 from ./lib/unistd.h:81,
 from ./lib/stdlib.h:100,
 from /usr/include/sys/cpuset.h:12,
 from /usr/include/sys/_pthreadtypes.h:12,
 from /usr/include/sys/types.h:221,
 from ./lib/sys/types.h:39,
 from ./lib/stdio.h:58,
 from 
/usr/src/coreutils-9.0-1.src/coreutils-9.0-1.x86_64/src/coreutils-9.0/lib/exclude.c:31:

/usr/include/cygwin/signal.h:121:3: error: unknown type name 'pthread_attr_t'
  121 |   pthread_attr_t *sigev_notify_attributes; /* notification attributes */
  |   ^~
In file included from /usr/include/signal.h:6,
 from ./lib/signal.h:52,
 from /usr/include/time.h:158,
 from ./lib/time.h:47,
 from ./lib/sys/stat.h:44,
 from ./lib/fcntl.h:64,
 from ./lib/unistd.h:81,
 from ./lib/stdlib.h:100,
 from /usr/include/sys/cpuset.h:12,
 from /usr/include/sys/_pthreadtypes.h:12,
 from /usr/include/sys/types.h:221,
 from ./lib/sys/types.h:39,
 from ./lib/stdio.h:58,
 from 
/usr/src/coreutils-9.0-1.src/coreutils-9.0-1.x86_64/src/coreutils-9.0/lib/exclude.c:31:

/usr/include/sys/signal.h:227:29: error: expected ')' before 'int'
  227 | int pthread_kill (pthread_t, int);
  | ^~~~
  | )
In file included from /usr/include/sys/stat.h:22,
 from ./lib/sys/stat.h:47,
 from ./lib/fcntl.h:64,
 from ./lib/unistd.h:81,
 from ./lib/stdlib.h:100,
 from /usr/include/sys/cpuset.h:12,
 from /usr/include/sys/_pthreadtypes.h:12,
 from /usr/include/sys/types.h:221,
 from ./lib/sys/types.h:39,
 from ./lib/stdio.h:58,
 from 
/usr/src/coreutils-9.0-1.src/coreutils-9.0-1.x86_64/src/coreutils-9.0/lib/exclude.c:31:

/usr/include/cygwin/stat.h:27:3: error: unknown type name 'timestruc_t'
   27 |   timestruc_t   st_atim;
  |   ^~~
/usr/include/cygwin/stat.h:28:3: error: unknown type name 'timestruc_t'
   28 |   timestruc_t   st_mtim;
  |   ^~~
/usr/include/cygwin/stat.h:29:3: error: unknown type name 'timestruc_t'
   29 |   timestruc_t   st_ctim;
  |   ^~~
/usr/include/cygwin/stat.h:32:3: error: unknown type name 'timestruc_t'
   32 |   timestruc_t   st_birthtim;
  |   ^~~

I've trimmed the errors back to just those from compiling lib/exclude.c.  This is 
new breakage in 3.4.8 (per Denis) and corresponds to the new in 3.4.8 #includes 
added to /usr/include/sys/cpuset.h.


I guess it's the include search order that has ./lib/stdlib.h being included from 
sys/cpuset.h rather than the "" coded there.


I'm not familiar with building coreutils.  But it seems something about the new 
#includes added to sys/cpuset.h have upset coreutils' build magic.  My offer to 
replace the two problematic #includes with two explicit extern statements still 
stands ;-).


..mark

--
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: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Mark Geisert via Cygwin]

Hi Denis,

Thanks for the report.  More below...

Denis Excoffier via Cygwin wrote:

Hello,
When i try to compile coreutils-9.3 under cygwin-3.4.8 i get the following 
error messages (see below).
There seems to be a kind of loop in the hierarchy of #includes.
Moreover, with cygwin-3.4.7, this is ok. Also, if under cygwin-3.4.8 i remove 
the 2 #includes from /usr/include/sys/cpuset.h,
this is also ok.

Regards,

Denis Excoffier.



In file included from /usr/include/sys/signal.h:23,
  from /usr/include/signal.h:6,
  from ./lib/signal.h:52,
  from /usr/include/time.h:158,
  from ./lib/time.h:47,
  from ./lib/sys/stat.h:44,
  from ./lib/fcntl.h:64,
  from ./lib/unistd.h:99,
  from ./lib/stdlib.h:98,
  from /usr/include/sys/cpuset.h:12,
  from /usr/include/sys/_pthreadtypes.h:12,
  from /usr/include/sys/types.h:221,
  from ./lib/sys/types.h:39,
  from ./lib/stdio.h:69,
  from src/chroot.c:21:
/usr/include/cygwin/signal.h:121:3: error: unknown type name 'pthread_attr_t'
   121 |   pthread_attr_t *sigev_notify_attributes; /* notification attributes 
*/
   |   ^~
In file included from /usr/include/signal.h:6,
  from ./lib/signal.h:52,
  from /usr/include/time.h:158,
  from ./lib/time.h:47,
  from ./lib/sys/stat.h:44,
  from ./lib/fcntl.h:64,
  from ./lib/unistd.h:99,
  from ./lib/stdlib.h:98,
  from /usr/include/sys/cpuset.h:12,
  from /usr/include/sys/_pthreadtypes.h:12,
  from /usr/include/sys/types.h:221,
  from ./lib/sys/#include types.h:39,
  from ./lib/stdio.h:69,
  from src/chroot.c:21:
/usr/include/sys/signal.h:227:29: error: expected ')' before 'int'
   227 | int pthread_kill (pthread_t, int);
   | ^~~~
   | )


ISTM the above could be fixed by moving "#include " after all the 
typedefs in .  That would be an odd location for an #include 
though.  Another approach would be to have explicit external refs for the needed 
two functions in  and remove the #includes there.



In file included from /usr/include/sys/stat.h:22,
  from ./lib/sys/stat.h:47,
  from ./lib/fcntl.h:64,
  from ./lib/unistd.h:99,
  from ./lib/stdlib.h:98,
  from /usr/include/sys/cpuset.h:12,
  from /usr/include/sys/_pthreadtypes.h:12,
  from /usr/include/sys/types.h:221,
  from ./lib/sys/types.h:39,
  from ./lib/stdio.h:69,
  from src/chroot.c:21:
/usr/include/cygwin/stat.h:27:3: error: unknown type name 'timestruc_t'
27 |   timestruc_t   st_atim;
   |   ^~~
/usr/include/cygwin/stat.h:28:3: error: unknown type name 'timestruc_t'
28 |   timestruc_t   st_mtim;
   |   ^~~
/usr/include/cygwin/stat.h:29:3: error: unknown type name 'timestruc_t'
29 |   timestruc_t   st_ctim;
   |   ^~~
/usr/include/cygwin/stat.h:32:3: error: unknown type name 'timestruc_t'
32 |   timestruc_t   st_birthtim;
   |   ^~~


I don't have an answer for these.  Awaiting more input from our wizards.  I'm 
willing to submit the patch for any agreed solution.


..mark

--
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: Test for Windows Administrator permissions from Cygwin terminal|script?

[Mark Geisert via Cygwin]

Mark Geisert via Cygwin wrote:

Backwoods BC via Cygwin wrote:

[...]

I don't know if this is the official method, but it works for me:

# Shell Options
# Elevated privilege windows have $SESSIONNAME set
if [ "$SESSIONNAME" == "" ] ;then
   printf -v adminPmt '[\u2022Admin\u2022] '
else
   export adminPmt=""
fi


I see the opposite on my machine.  Admin window has empty $SESSIONNAME, non-Admin 
window has "Console".


Feh, I mentally reversed the 'if' clauses.  I see the same $SESSIONNAME behavior 
on my machine.  Sorry for the noise.


..mark

--
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: Test for Windows Administrator permissions from Cygwin terminal|script?

[Mark Geisert via Cygwin]

Backwoods BC via Cygwin wrote:

On Thu, Aug 17, 2023 at 7:01 PM Martin Wege via Cygwin
 wrote:

How can I find out whether the current Cygwin terminal has
Administrator rights? I want to safeguard our admin scripts with a
simple test and bail out with an error if someone wants to do admin
stuff (say: regtool) without admin privileges.

Thanks,
Martin


I don't know if this is the official method, but it works for me:

# Shell Options
# Elevated privilege windows have $SESSIONNAME set
if [ "$SESSIONNAME" == "" ] ;then
   printf -v adminPmt '[\u2022Admin\u2022] '
else
   export adminPmt=""
fi


I see the opposite on my machine.  Admin window has empty $SESSIONNAME, non-Admin 
window has "Console".


What I do locally is check the output of the 'id' command.  If group 
544(Administrators) is present, that's a window with Admin rights.  Inside .bashrc 
I have a simple grep test on the output of 'id' to set PS1 (shell prompt) 
appropriately.


..mark

--
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: Linking a native msvc dll library to CYGWIN g++ compiler

[Mark Geisert via Cygwin]

Mümin A. via Cygwin wrote:

Hi,

reminder..

Mümin A. , 11 Tem 2023 Sal, 09:47 tarihinde şunu
yazdı:



Hi,

I'm facing a problem while linking my native dll library into the g++
compiler.

There is a name mangling problem when calling a msvc function from g++
compiler therefore linker gives an error undefined reference.

Is there any method to directly link and call a function from native dll
library from the cygwin compiler ?



For example, I've a fooCls.h header file for a windows library,  I add
link the fooCls.dll to g++ compiler then,

fooNameSpace::fooConnectionCls instance;
instance.FooTest();

gives a linker error , undefined reference.


Thank you in advance,
Mumin AYDI


Did you see Csaba's reply to your initial email?  Check the mail archives.
Does FAQ 6.36 describe your situation?

See the Cygwin home page https://cygwin.com for pointers to those resources.

..mark

--
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: iostream doesn't work (clang++)

[Mark Geisert via Cygwin]

Hi once again,

ggl329 via Cygwin wrote:

On 2023/07/05 12:06, Mark Geisert via Cygwin wrote:

My previous reply addressed the specific error reported by your testcase.
But I am unable to make progress on the root cause because I can't reproduce 
your report.

[... useful info elided from this quote ...]

I was able to build a working clang/clang++ environment and then reproduce your 
report.  A potential solution was discussed on the cygwin-patches mailing list.


Just a quick note to say the root cause has been fixed; the next version of the 
Cygwin DLL (3.4.8) will include the fix.  If you need the fix urgently you can 
find a replacement for your /usr/include/sys/cpuset.h at

https://github.com/cygwin/cygwin/blob/main/winsup/cygwin/include/sys/cpuset.h
I would suggest moving (with 'mv') your existing file out of the way but keeping 
it around in case of any mishap getting the replacement.


Thanks again for reporting this issue,

..mark


--
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

[PATCH] Cygwin: Update release/3.4.8 for latest commit

[Mark Geisert]

---
 winsup/cygwin/release/3.4.8 | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/winsup/cygwin/release/3.4.8 b/winsup/cygwin/release/3.4.8
index d1e34ce3c..3113be8cb 100644
--- a/winsup/cygwin/release/3.4.8
+++ b/winsup/cygwin/release/3.4.8
@@ -3,3 +3,6 @@ Bug Fixes
 
 - Make  safe for c89 compilations.
   Addresses: https://cygwin.com/pipermail/cygwin-patches/2023q3/012308.html
+
+- Make gcc-specific code in  compiler-agnostic.
+  Addresses: https://cygwin.com/pipermail/cygwin/2023-July/253927.html
-- 
2.39.0

Re: Where should relnote updates for Cygwin DLL patches be going?

[Mark Geisert]

Hi Corinna,

Corinna Vinschen wrote:

On Jul 11 01:05, Mark Geisert wrote:

AIUI for cygwin-3_4-branch they currently go to release/3.4.8.
For the main|master branch they currently go where?


release/3.5.0

An entry there is only necessary if it doesn't get picked for 3.4
anyway.


Ah, that helps me understand.


I hope to get it right the first time ;-).


Is the release model confusing?  If so, can you explain why?


I think I haven't been paying close enough attention and have been doing the 
relnote updates by rote.  But there being two active branches and I 
(understandably) don't determine which releases my commits go to means I should 
wait until they show up on the cvs-patches list, then I will know which relnote 
files to update.  That should work OK, right?


Is it preferred that relnote updates should be separate patches from the code 
updates?
Thanks,

..mark

Where should relnote updates for Cygwin DLL patches be going?

[Mark Geisert]

AIUI for cygwin-3_4-branch they currently go to release/3.4.8.
For the main|master branch they currently go where?
I hope to get it right the first time ;-).
Thank you,

..mark

[PATCH v2] Cygwin: Make gcc-specific code in compiler-agnostic

[Mark Geisert]

The current version of  cannot be compiled by Clang due to
the use of builtin versions of malloc, free, and memset.  Their presence
here was a dubious optimization anyway, so their usage has been
converted to standard library functions.

The use of __builtin_popcountl remains because Clang implements it just
like gcc does.  If/when some other compiler (Rust? Go?) runs into this
issue we can deal with specialized handling then.

The "#include " here to define __inline can be removed since
both of the new includes sub-include it.

Addresses: https://cygwin.com/pipermail/cygwin/2023-July/253927.html
Fixes: 9cc910dd33a5 (Cygwin: Make  safe for c89 compilations)
Signed-off-by: Mark Geisert 

---
 winsup/cygwin/include/sys/cpuset.h | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/winsup/cygwin/include/sys/cpuset.h 
b/winsup/cygwin/include/sys/cpuset.h
index 0c95134ff..95c777cfb 100644
--- a/winsup/cygwin/include/sys/cpuset.h
+++ b/winsup/cygwin/include/sys/cpuset.h
@@ -9,7 +9,8 @@ details. */
 #ifndef _SYS_CPUSET_H_
 #define _SYS_CPUSET_H_
 
-#include 
+#include 
+#include 
 
 #ifdef __cplusplus
 extern "C" {
@@ -44,14 +45,14 @@ __cpuset_alloc_size (int num)
 static __inline cpu_set_t *
 __cpuset_alloc (int num)
 {
-  return (cpu_set_t *) __builtin_malloc (CPU_ALLOC_SIZE(num));
+  return (cpu_set_t *) malloc (CPU_ALLOC_SIZE(num));
 }
 
 #define CPU_FREE(set) __cpuset_free (set)
 static __inline void
 __cpuset_free (cpu_set_t *set)
 {
-  __builtin_free (set);
+  free (set);
 }
 
 /* These _S macros operate on dynamically-sized cpu sets of size 'siz' bytes */
@@ -59,7 +60,7 @@ __cpuset_free (cpu_set_t *set)
 static __inline void
 __cpuset_zero_s (size_t siz, cpu_set_t *set)
 {
-  (void) __builtin_memset (set, 0, siz);
+  (void) memset (set, 0, siz);
 }
 
 #define CPU_SET_S(cpu, siz, set) __cpuset_set_s (cpu, siz, set)
-- 
2.39.0

Re: [PATCH] Cygwin: Make gcc-specific code in compiler-agnostic

[Mark Geisert]

Hi all,

Brian Inglis wrote:

On 2023-07-08 15:53, Mark Geisert wrote:

Mark Geisert wrote:
I got tripped up by misspelling and not being able to link clang{,++} programs 
on my test system.  I checked the .o files with objdump: Clang and clang++ both 
support __builtin_popcountl, but they emit code for the Hackers Delight 
algorithm rather than using the single-instruction popcnt.  Sorry for the 
confustion [sic].


That's what I meant - clang 8 "identifies as" gcc 4, and builtin and intrinsic 
function support are almost the same (and fairly close to gcc 11) builtin and 
intrinsic function support.


And as you mentioned, any support for builtins is better than what we can whip up 
off the top of our heads (unless you use HD/2!)


For our purposes, the main differences between clang 8 and current are latest 
language, library, and processor support, but it also supports useful tools like 
the analyzer and formatter, which gcc does not provide.


And it is convenient to be able to run another compiler side by side for 
comparisons without copying files and remoting to another system.


I now understand what you were getting at.  We are in agreement.  Thanks to your 
persistence and everybody elses comments and to my belatedly getting a working 
clang/clang++ build environment, there is a much smaller v2 patch incoming.

Thanks and Regards All,

..mark

Re: [PATCH] Cygwin: Make gcc-specific code in compiler-agnostic

[Mark Geisert]

Mark Geisert wrote:
[... blah blah ...]

I got tripped up by misspelling and not being able to link clang{,++} programs on 
my test system.  I checked the .o files with objdump: Clang and clang++ both 
support __builtin_popcountl, but they emit code for the Hackers Delight algorithm 
rather than using the single-instruction popcnt.  Sorry for the confustion [sic].


..mark

Re: [PATCH] Cygwin: Make gcc-specific code in compiler-agnostic

[Mark Geisert]

Brian Inglis wrote:

On 2023-07-07 12:54, Brian Inglis wrote:

On 2023-07-07 03:44, Corinna Vinschen wrote:

Hi Mark,

On Jul  7 00:41, Mark Geisert wrote:

The current version of  cannot be compiled by Clang due to
the use of __builtin* functions.  Their presence here was a dubious
optimization anyway, so their usage has been converted to standard
library functions.  A popcnt (population count of 1 bits in a word)
function is provided here because there isn't one in the standard library
or elsewhere in the Cygwin DLL.


And clang really doesn't provide it?  That's unfortunate.

Do you really think it's not worth to use it if it's available?

You could workaround it like this:


+/* Modern CPUs have popcnt* instructions but the need here is not worth
+ * worrying about builtins or inline assembler for different compilers. */
+static inline int
+__maskpopcnt (__cpu_mask mask)
+{

#if (__GNUC__ >= 4)
  return __builtin_popcountl (mask);


Missed the difference in spelling, but clang supports the same builtin functions 
__builtin_popcount{,l,ll} et. al. or provides *optimized* inline functions if not 
directly available as an instruction on the architecture.


Clang in its current version 16.0.x has __builtin_popcount*, but not in the 
ancient version 8.0.1 that is currently packaged for Cygwin.  I think that's what 
was behind Jon's earlier comment that perhaps we should remove clang from Cygwin 
unless/until somebody can adopt and maintain an up-to-date version.  :-(.


..mark

Re: [PATCH] Cygwin: Make gcc-specific code in compiler-agnostic

[Mark Geisert]

Hi Corinna,

Corinna Vinschen wrote:

On Jul  7 00:41, Mark Geisert wrote:

The current version of  cannot be compiled by Clang due to
the use of __builtin* functions.  Their presence here was a dubious
optimization anyway, so their usage has been converted to standard
library functions.  A popcnt (population count of 1 bits in a word)
function is provided here because there isn't one in the standard library
or elsewhere in the Cygwin DLL.


And clang really doesn't provide it?  That's unfortunate.

Do you really think it's not worth to use it if it's available?


I don't know for sure.  I'd guess the popcnt op should be optimized if available; 
the others probably don't need it.



You could workaround it like this:


+/* Modern CPUs have popcnt* instructions but the need here is not worth
+ * worrying about builtins or inline assembler for different compilers. */
+static inline int
+__maskpopcnt (__cpu_mask mask)
+{

#if (__GNUC__ >= 4)
  return __builtin_popcountl (mask);
#else

+  int res = 0;
+  unsigned long ulmask = (unsigned long) mask;
+
+  while (ulmask != 0)
+{
+  if (ulmask & 1)
+++res;
+  ulmask >>= 1;
+}
+  return res;

#endif

+}
+


The first version of the patch (unsubmitted) worked something like that, though it 
was a chore figuring out how to tell the difference between gcc and clang.  clang 
#defines __GNUC__ (?!) for example.  I ended up using __GNUC_PREREQ__ with the 
hope clang version numbers stay lower than gcc version numbers.  Has to be a 
better way than that.


On the other hand, one compilation with clang or clang++, I forget which, and with 
some optimization flag, recognized the 'while' loop in that function and turned it 
into the Hackers Delight algorithm for popcnt in ~20 instructions and no loop.


TL;DR let me ponder this over the weekend.
Thanks for listening,

..mark

Re: iostream doesn't work (clang++)

[Mark Geisert via Cygwin]

Brian Inglis via Cygwin wrote:

On 2023-07-05 09:54, ggl329 via Cygwin wrote:

Hi Mark,

On 2023/07/05 12:06, Mark Geisert via Cygwin wrote:

My previous reply addressed the specific error reported by your testcase.
But I am unable to make progress on the root cause because I can't reproduce 
your report.


Hm, it seems to be difficult to track down the root cause...


On my system I try the compilation and see:
~ clang++ sample.cc
sample.cc:1:10: fatal error: 'iostream' file not found
#include 
  ^~
1 error generated.


I tried with clang++ --verbose, and the log showed search paths for #include.
iostream is at /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/iostream.
Can you find it? It comes from gcc-g++.
Or the search path includes /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++?


Package clang pulls in headers and libraries from libc++-devel libclang8 
libunwind-devel gcc-g++ libstdc++6 gcc-core cygwin-devel so the primary include 
paths should be from:
libc++-devel /usr/include/c++/v1/ for most language and library definitions and 
libraries,

libclang8 /usr/lib/clang/8.0.1/include/ for clang intrinsics and builtins,
libunwind-devel /usr/include/ for exception handling definitions and libraries,
gcc-g++ /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/{x86_64-pc-cygwin/,} and 
libstdc++6 for C++ system dependent and low level definitions and libraries,
gcc-core /usr/lib/gcc/x86_64-pc-cygwin/11/include/ for system dependent and low 
level intrinsics and interfaces, and
cygwin-devel /usr/include/{*/,} for system dependent and low level definitions and 
libraries.


Everything clang should be prioritized over anything gcc to prevent such issues, 
so cygcheck -c clang llvm libc++-devel libclang8 libunwind-devel gcc-g++ 
libstdc++6 gcc-core cygwin-devel to ensure eveything has been installed properly.


Unfortunately clang{,++,-cpp} -print-search-dirs does *NOT* show include paths,
but -v and -### complain about nonexistent /usr/include/c++/11 where 
/usr/include/c++/v1 exists!

It appears the search list ignores the directories populated in libc++-devel:
... -resource-dir /usr/lib/clang/8.0.1
-internal-isystem /usr/x86_64-pc-cygwin/include/c++
-internal-isystem /usr/x86_64-pc-cygwin/include/c++/x86_64-pc-cygwin
-internal-isystem /usr/x86_64-pc-cygwin/include/c++/backward
-internal-isystem /usr/x86_64-pc-cygwin/include/c++/11
-internal-isystem /usr/x86_64-pc-cygwin/include/c++/11/x86_64-pc-cygwin 
-internal-isystem /usr/x86_64-pc-cygwin/include/c++/11/backward

-internal-isystem /usr/include/c++/11
-internal-isystem /usr/include/c++/11/x86_64-pc-cygwin
-internal-isystem /usr/include/c++/11/backward
-internal-isystem /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++
-internal-isystem /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin 
-internal-isystem /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/backward

-internal-isystem /usr/lib/clang/8.0.1/include
-internal-isystem /usr/local/include
-internal-isystem /usr/lib/clang/8.0.1/include
-internal-isystem /usr/x86_64-pc-cygwin/include
-internal-isystem /usr/include
-internal-isystem /usr/include/w32api ...
ignoring nonexistent directory "/usr/x86_64-pc-cygwin/include/c++"
ignoring nonexistent directory 
"/usr/x86_64-pc-cygwin/include/c++/x86_64-pc-cygwin"
ignoring nonexistent directory "/usr/x86_64-pc-cygwin/include/c++/backward"
ignoring nonexistent directory "/usr/x86_64-pc-cygwin/include/c++/11"
ignoring nonexistent directory 
"/usr/x86_64-pc-cygwin/include/c++/11/x86_64-pc-cygwin"

ignoring nonexistent directory "/usr/x86_64-pc-cygwin/include/c++/11/backward"
ignoring nonexistent directory "/usr/include/c++/11"
ignoring nonexistent directory "/usr/include/c++/11/x86_64-pc-cygwin"
ignoring nonexistent directory "/usr/include/c++/11/backward"
ignoring nonexistent directory "/usr/x86_64-pc-cygwin/include"
ignoring duplicate directory "/usr/lib/clang/8.0.1/include"
#include "..." search starts here:
#include <...> search starts here:
  /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++
  /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin
  /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/backward
  /usr/lib/clang/8.0.1/include
  /usr/local/include
  /usr/include
  /usr/include/w32api
End of search list.

You may want to try to override the built in includes from -internal-isystem with 
those mentioned above but not built in.


I have no idea why both compilers would include w32api headers as if they were 
building Mingw cross compilers!


Thanks very much Brian for this overview.  I'd rather not delay a fix for the OP 
any longer, so I have submitted a patch for the reported issue.  If it turns out 
that, with the patch, the OP can successfully compile and build his testcase, we 
may be done.


If not, somebody (TM) may have to dig into what's been discovered and how to 
remedy it.  Comparing Cygwin's clang/clang++ inst

[PATCH] Cygwin: Make gcc-specific code in compiler-agnostic

[Mark Geisert]

The current version of  cannot be compiled by Clang due to
the use of __builtin* functions.  Their presence here was a dubious
optimization anyway, so their usage has been converted to standard
library functions.  A popcnt (population count of 1 bits in a word)
function is provided here because there isn't one in the standard library
or elsewhere in the Cygwin DLL.

The "#include " here to define __inline can be removed since
both of the new includes sub-include it.

Addresses: https://cygwin.com/pipermail/cygwin/2023-July/253927.html
Fixes: 9cc910dd33a5 (Cygwin: Make  safe for c89 compilations)
Signed-off-by: Mark Geisert 

---
 winsup/cygwin/include/sys/cpuset.h | 28 +++-
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/winsup/cygwin/include/sys/cpuset.h 
b/winsup/cygwin/include/sys/cpuset.h
index 0c95134ff..f76e788d5 100644
--- a/winsup/cygwin/include/sys/cpuset.h
+++ b/winsup/cygwin/include/sys/cpuset.h
@@ -9,7 +9,8 @@ details. */
 #ifndef _SYS_CPUSET_H_
 #define _SYS_CPUSET_H_
 
-#include 
+#include 
+#include 
 
 #ifdef __cplusplus
 extern "C" {
@@ -31,6 +32,23 @@ typedef struct
 #if __GNU_VISIBLE
 int __sched_getaffinity_sys (pid_t, size_t, cpu_set_t *);
 
+/* Modern CPUs have popcnt* instructions but the need here is not worth
+ * worrying about builtins or inline assembler for different compilers. */ 
+static inline int
+__maskpopcnt (__cpu_mask mask)
+{
+  int res = 0;
+  unsigned long ulmask = (unsigned long) mask;
+
+  while (ulmask != 0)
+{
+  if (ulmask & 1)
+++res;
+  ulmask >>= 1;
+}
+  return res;
+}
+
 /* These macros alloc or free dynamically-sized cpu sets of size 'num' cpus.
Allocations are padded such that full-word operations can be done easily. */
 #define CPU_ALLOC_SIZE(num) __cpuset_alloc_size (num)
@@ -44,14 +62,14 @@ __cpuset_alloc_size (int num)
 static __inline cpu_set_t *
 __cpuset_alloc (int num)
 {
-  return (cpu_set_t *) __builtin_malloc (CPU_ALLOC_SIZE(num));
+  return (cpu_set_t *) malloc (CPU_ALLOC_SIZE(num));
 }
 
 #define CPU_FREE(set) __cpuset_free (set)
 static __inline void
 __cpuset_free (cpu_set_t *set)
 {
-  __builtin_free (set);
+  free (set);
 }
 
 /* These _S macros operate on dynamically-sized cpu sets of size 'siz' bytes */
@@ -59,7 +77,7 @@ __cpuset_free (cpu_set_t *set)
 static __inline void
 __cpuset_zero_s (size_t siz, cpu_set_t *set)
 {
-  (void) __builtin_memset (set, 0, siz);
+  (void) memset (set, 0, siz);
 }
 
 #define CPU_SET_S(cpu, siz, set) __cpuset_set_s (cpu, siz, set)
@@ -94,7 +112,7 @@ __cpuset_count_s (size_t siz, cpu_set_t *set)
 {
   int i, res = 0;
   for (i = 0; i < siz / sizeof (__cpu_mask); i++)
-res += __builtin_popcountl ((set)->__bits[i]);
+res += __maskpopcnt ((set)->__bits[i]);
   return res;
 }
 
-- 
2.39.0

Re: iostream doesn't work (clang++)

[Mark Geisert via Cygwin]

Hi again,

ggl329 via Cygwin wrote:

Hi,

clang++ fails with iostream.
Does it go well in your environment?
# I noticed that clang is orphaned. clang requires a maintainer?


It would indeed be nice to have a clang maintainer.  Until that happens various 
other folks might be able to assist if their schedules allow.



$ cat sample.cc
#include 
int main()
{
     std::cout << "Hello World.\n";
     return 0;
}

$ g++ sample.cc
$ ./a
Hello World.

$ clang++ sample.cc
In file included from sample.cc:1:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/iostream:39:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ostream:38:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ios:42:
In file included from 
/usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/ios_base.h:39:
In file included from 
/usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ext/atomicity.h:35:
In file included from 
/usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr.h:148:
In file included from 
/usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr-default.h:35:

In file included from /usr/include/pthread.h:11:
In file included from /usr/include/sys/types.h:221:
In file included from /usr/include/sys/_pthreadtypes.h:12:
/usr/include/sys/cpuset.h:45:24: error: use of undeclared identifier 
'__builtin_malloc'; did you mean

   '__builtin_alloca'?
   return (cpu_set_t *) __builtin_malloc (CPU_ALLOC_SIZE(num));
    ^
/usr/include/sys/cpuset.h:45:24: note: '__builtin_alloca' declared here
/usr/include/sys/cpuset.h:52:3: error: use of undeclared identifier 
'__builtin_free'
   __builtin_free (set);
   ^
2 errors generated.


Package version information which may be related.

Cygwin Package Information
Package  Version
binutils 2.40-1
clang    8.0.1-1
compiler-rt  8.0.1-1
cygwin   3.4.7-1
cygwin-devel 3.4.7-1
gcc-core 11.4.0-1
gcc-g++  11.4.0-1
libc++-devel 8.0.1-1
libc++1  8.0.1-1
libc++abi-devel  8.0.1-1
libc++abi1   8.0.1-1
libclang-devel   8.0.1-1
libclang8    8.0.1-1
libllvm-devel    8.0.1-1
libllvm8 8.0.1-1
libpolly-devel   8.0.1-1
libpolly8    8.0.1-1
libstdc++6   11.4.0-1
libunwind-devel  8.0.1-1
libunwind1   8.0.1-1
llvm 8.0.1-1


My previous reply addressed the specific error reported by your testcase.  But I 
am unable to make progress on the root cause because I can't reproduce your report.


On my system I try the compilation and see:
~ clang++ sample.cc
sample.cc:1:10: fatal error: 'iostream' file not found
#include 
 ^~
1 error generated.

My list of possibly related package versions looks very similar to yours:
binutils   2.40-1
clang  8.0.1-1
compiler-rt8.0.1-1
cygwin 3.4.7-1
cygwin-devel   3.4.7-1
gcc-core   11.4.0-1
gcc-g++11.4.0-1
libatomic1 11.4.0-1
libc++-devel   8.0.1-1
libc++18.0.1-1
libc++abi-devel8.0.1-1
libc++abi1 8.0.1-1
libclang-devel 8.0.1-1
libclang8  8.0.1-1
libgcc111.4.0-1
libllvm-devel  8.0.1-1
libllvm8   8.0.1-1
libpolly-devel 8.0.1-1
libpolly8  8.0.1-1
libquadmath0   11.4.0-1
libstdc++6 11.4.0-1
libunwind-devel8.0.1-1
libunwind1 8.0.1-1
llvm   8.0.1-1

I'm not a clang user so there might be something fundamentally wrong with my setup 
that I don't see.  Also, do you have a CFLAGS or other environment string(s) that 
would possibly be passed to clang as it would to gcc?  Has "clang++" been aliased 
to something else, perhaps passing options that way?  Also, do you happen to have 
any of the boost libraries installed?


I'm willing to patch the reported error but I'd like to first make sure it is 
legitimate for clang to have gone down the reported include path through what look 
like gcc-related include files.


..mark

--
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: iostream doesn't work (clang++)

[Mark Geisert via Cygwin]

Hi there,

ggl329 via Cygwin wrote:

Hi,

clang++ fails with iostream.
Does it go well in your environment?
# I noticed that clang is orphaned. clang requires a maintainer?


$ cat sample.cc
#include 
int main()
{
     std::cout << "Hello World.\n";
     return 0;
}

$ g++ sample.cc
$ ./a
Hello World.

$ clang++ sample.cc
In file included from sample.cc:1:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/iostream:39:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ostream:38:
In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ios:42:
In file included from 
/usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/ios_base.h:39:
In file included from 
/usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/ext/atomicity.h:35:
In file included from 
/usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr.h:148:
In file included from 
/usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/gthr-default.h:35:

In file included from /usr/include/pthread.h:11:
In file included from /usr/include/sys/types.h:221:
In file included from /usr/include/sys/_pthreadtypes.h:12:
/usr/include/sys/cpuset.h:45:24: error: use of undeclared identifier 
'__builtin_malloc'; did you mean

   '__builtin_alloca'?
   return (cpu_set_t *) __builtin_malloc (CPU_ALLOC_SIZE(num));
    ^
/usr/include/sys/cpuset.h:45:24: note: '__builtin_alloca' declared here
/usr/include/sys/cpuset.h:52:3: error: use of undeclared identifier 
'__builtin_free'
   __builtin_free (set);
   ^
2 errors generated.

[...]

That's not a problem with , but with .  It did not 
anticipate being compiled with clang.  I will submit a patch.

Thanks for the report,

..mark

--
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 v2] Cygwin: Make safe for c89 compilations

[Mark Geisert]

Corinna Vinschen wrote:

On Jul  4 16:33, Corinna Vinschen wrote:

On Jul  3 17:51, Mark Geisert wrote:

Four modifications to include/sys/cpuset.h:
* Change C++-style comments to C-style also supported by C++
* Change "inline" to "__inline" on code lines
* Add "#include " to make sure __inline is defined
* Don't declare loop variables on for-loop init clauses

Tested by first reproducing the reported issue with home-grown test
programs by compiling with gcc option "-std=c89", then compiling again
using the modified . Other "-std=" options tested too.

Addresses: https://cygwin.com/pipermail/cygwin-patches/2023q3/012308.html
Fixes: 315e5fbd99ec ("Cygwin: Fix type mismatch on sys/cpuset.h")
Signed-off-by: Mark Geisert 

---
  winsup/cygwin/include/sys/cpuset.h | 49 --
  winsup/cygwin/release/3.4.7|  3 ++
  2 files changed, 30 insertions(+), 22 deletions(-)


Pushed.


FYI, I missed to notice that you added the release message to the
already existing 3.4.7 release.  I moved it into a new file for 3.4.8.


Thank you for cleaning up after my goof on the version.
Cheers & Regards,

..mark

[PATCH v2] Cygwin: Make safe for c89 compilations

[Mark Geisert]

Four modifications to include/sys/cpuset.h:
* Change C++-style comments to C-style also supported by C++
* Change "inline" to "__inline" on code lines
* Add "#include " to make sure __inline is defined
* Don't declare loop variables on for-loop init clauses

Tested by first reproducing the reported issue with home-grown test
programs by compiling with gcc option "-std=c89", then compiling again
using the modified . Other "-std=" options tested too.

Addresses: https://cygwin.com/pipermail/cygwin-patches/2023q3/012308.html
Fixes: 315e5fbd99ec ("Cygwin: Fix type mismatch on sys/cpuset.h")
Signed-off-by: Mark Geisert 

---
 winsup/cygwin/include/sys/cpuset.h | 49 --
 winsup/cygwin/release/3.4.7|  3 ++
 2 files changed, 30 insertions(+), 22 deletions(-)

diff --git a/winsup/cygwin/include/sys/cpuset.h 
b/winsup/cygwin/include/sys/cpuset.h
index d83359fdf..0c95134ff 100644
--- a/winsup/cygwin/include/sys/cpuset.h
+++ b/winsup/cygwin/include/sys/cpuset.h
@@ -9,14 +9,16 @@ details. */
 #ifndef _SYS_CPUSET_H_
 #define _SYS_CPUSET_H_
 
+#include 
+
 #ifdef __cplusplus
 extern "C" {
 #endif
 
 typedef __SIZE_TYPE__ __cpu_mask;
-#define __CPU_SETSIZE 1024  // maximum number of logical processors tracked
-#define __NCPUBITS (8 * sizeof (__cpu_mask))  // max size of processor group
-#define __CPU_GROUPMAX (__CPU_SETSIZE / __NCPUBITS)  // maximum group number
+#define __CPU_SETSIZE 1024  /* maximum number of logical processors tracked */
+#define __NCPUBITS (8 * sizeof (__cpu_mask))  /* max size of processor group */
+#define __CPU_GROUPMAX (__CPU_SETSIZE / __NCPUBITS)  /* maximum group number */
 
 #define __CPUELT(cpu)  ((cpu) / __NCPUBITS)
 #define __CPUMASK(cpu) ((__cpu_mask) 1 << ((cpu) % __NCPUBITS))
@@ -32,21 +34,21 @@ int __sched_getaffinity_sys (pid_t, size_t, cpu_set_t *);
 /* These macros alloc or free dynamically-sized cpu sets of size 'num' cpus.
Allocations are padded such that full-word operations can be done easily. */
 #define CPU_ALLOC_SIZE(num) __cpuset_alloc_size (num)
-static inline size_t
+static __inline size_t
 __cpuset_alloc_size (int num)
 {
   return (size_t) (((num + __NCPUBITS - 1) / __NCPUBITS) * sizeof 
(__cpu_mask));
 }
 
 #define CPU_ALLOC(num) __cpuset_alloc (num)
-static inline cpu_set_t *
+static __inline cpu_set_t *
 __cpuset_alloc (int num)
 {
   return (cpu_set_t *) __builtin_malloc (CPU_ALLOC_SIZE(num));
 }
 
 #define CPU_FREE(set) __cpuset_free (set)
-static inline void
+static __inline void
 __cpuset_free (cpu_set_t *set)
 {
   __builtin_free (set);
@@ -54,14 +56,14 @@ __cpuset_free (cpu_set_t *set)
 
 /* These _S macros operate on dynamically-sized cpu sets of size 'siz' bytes */
 #define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
-static inline void
+static __inline void
 __cpuset_zero_s (size_t siz, cpu_set_t *set)
 {
   (void) __builtin_memset (set, 0, siz);
 }
 
 #define CPU_SET_S(cpu, siz, set) __cpuset_set_s (cpu, siz, set)
-static inline void
+static __inline void
 __cpuset_set_s (int cpu, size_t siz, cpu_set_t *set)
 {
   if (cpu >= 0 && cpu < 8 * siz)
@@ -69,7 +71,7 @@ __cpuset_set_s (int cpu, size_t siz, cpu_set_t *set)
 }
 
 #define CPU_CLR_S(cpu, siz, set) __cpuset_clr_s (cpu, siz, set)
-static inline void
+static __inline void
 __cpuset_clr_s (int cpu, size_t siz, cpu_set_t *set)
 {
   if (cpu >= 0 && cpu < 8 * siz)
@@ -77,7 +79,7 @@ __cpuset_clr_s (int cpu, size_t siz, cpu_set_t *set)
 }
 
 #define CPU_ISSET_S(cpu, siz, set) __cpuset_isset_s (cpu, siz, set)
-static inline int
+static __inline int
 __cpuset_isset_s (int cpu, size_t siz, cpu_set_t *set)
 {
   int res = 0;
@@ -87,45 +89,48 @@ __cpuset_isset_s (int cpu, size_t siz, cpu_set_t *set)
 }
 
 #define CPU_COUNT_S(siz, set) __cpuset_count_s (siz, set)
-static inline int
+static __inline int
 __cpuset_count_s (size_t siz, cpu_set_t *set)
 {
-  int res = 0;
-  for (int i = 0; i < siz / sizeof (__cpu_mask); i++)
+  int i, res = 0;
+  for (i = 0; i < siz / sizeof (__cpu_mask); i++)
 res += __builtin_popcountl ((set)->__bits[i]);
   return res;
 }
 
 #define CPU_AND_S(siz, dst, src1, src2) __cpuset_and_s (siz, dst, src1, src2)
-static inline void
+static __inline void
 __cpuset_and_s (size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
 {
-  for (int i = 0; i < siz / sizeof (__cpu_mask); i++)
+  int i;
+  for (i = 0; i < siz / sizeof (__cpu_mask); i++)
 (dst)->__bits[i] = (src1)->__bits[i] & (src2)->__bits[i];
 }
 
 #define CPU_OR_S(siz, dst, src1, src2) __cpuset_or_s (siz, dst, src1, src2)
-static inline void
+static __inline void
 __cpuset_or_s (size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
 {
-  for (int i = 0; i < siz / sizeof (__cpu_mask); i++)
+  int i;
+  for (i = 0; i < siz / sizeof (__cpu_mask); i++)
 (dst)->__bits[i] = (src1)->__bits[i] | (src2)->__bits[i];
 }
 
 #define CPU

Re: [PATCH] Cygwin: Make safe for c89 compilations

[Mark Geisert]

Hi Corinna,

Corinna Vinschen wrote:

On Jul  3 02:27, Mark Geisert wrote:

Brian Inglis wrote:

On 2023-07-03 00:17, Mark Geisert wrote:

Three modifications to include/sys/cpuset.h:
* Change C++-style comments to C-style also supported by C++
* Change "inline" to "__inline" on code lines
* Don't declare loop variables on for-loop init clauses

Tested by first reproducing the reported issue with home-grown test
programs by compiling with gcc option "-std=c89", then compiling again
using the modified . Other "-std=" options tested too.

Addresses: https://cygwin.com/pipermail/cygwin-patches/2023q3/012308.html
Fixes: 315e5fbd99ec ("Cygwin: Fix type mismatch on sys/cpuset.h")


Signed-off-by?


Eh, I was unsure if submitter or reviewer provides this.  Submitter it is.


Does this patch need __inline defined e.g.

    +#include 

did you perhaps include this directly in your test cases?


-static inline size_t
+static __inline size_t

...


No, not directly.  The test case with the shortest list of #includes has:
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 

So it's apparently defined by one of those or some sub-include.  But indeed
it's not safe to depend on that so I will try harder to figure out what
other occurrences of __inline in the Cygwin source tree are depending on for
the definition.


In this specific case  includes .  I figure one can't depend 
on what's included, or in what order.  So as Brian suggested, I've added an 
"#include ".  Not every site of __inline within the Cygwin source 
tree does this; I guess those will be fixed if/when reported as a problem.


v2 patch for 3.4.7 is on its way in.  If it's OK I'll then submit it for 3.3.6.
Thanks all for the review comments,

..mark

Re: [PATCH] Cygwin: Make safe for c89 compilations

[Mark Geisert]

Hi Brian,

Brian Inglis wrote:

On 2023-07-03 00:17, Mark Geisert wrote:

Three modifications to include/sys/cpuset.h:
* Change C++-style comments to C-style also supported by C++
* Change "inline" to "__inline" on code lines
* Don't declare loop variables on for-loop init clauses

Tested by first reproducing the reported issue with home-grown test
programs by compiling with gcc option "-std=c89", then compiling again
using the modified . Other "-std=" options tested too.

Addresses: https://cygwin.com/pipermail/cygwin-patches/2023q3/012308.html
Fixes: 315e5fbd99ec ("Cygwin: Fix type mismatch on sys/cpuset.h")

---
  winsup/cygwin/include/sys/cpuset.h | 47 --
  winsup/cygwin/release/3.4.7    |  3 ++
  2 files changed, 28 insertions(+), 22 deletions(-)

diff --git a/winsup/cygwin/include/sys/cpuset.h 
b/winsup/cygwin/include/sys/cpuset.h

index d83359fdf..01576b041 100644
--- a/winsup/cygwin/include/sys/cpuset.h
+++ b/winsup/cygwin/include/sys/cpuset.h
@@ -14,9 +14,9 @@ extern "C" {
  #endif
  typedef __SIZE_TYPE__ __cpu_mask;
-#define __CPU_SETSIZE 1024  // maximum number of logical processors tracked
-#define __NCPUBITS (8 * sizeof (__cpu_mask))  // max size of processor group
-#define __CPU_GROUPMAX (__CPU_SETSIZE / __NCPUBITS)  // maximum group number
+#define __CPU_SETSIZE 1024  /* maximum number of logical processors tracked */
+#define __NCPUBITS (8 * sizeof (__cpu_mask))  /* max size of processor group */
+#define __CPU_GROUPMAX (__CPU_SETSIZE / __NCPUBITS)  /* maximum group number */
  #define __CPUELT(cpu)  ((cpu) / __NCPUBITS)
  #define __CPUMASK(cpu) ((__cpu_mask) 1 << ((cpu) % __NCPUBITS))
@@ -32,21 +32,21 @@ int __sched_getaffinity_sys (pid_t, size_t, cpu_set_t *);
  /* These macros alloc or free dynamically-sized cpu sets of size 'num' cpus.
 Allocations are padded such that full-word operations can be done easily. 
*/
  #define CPU_ALLOC_SIZE(num) __cpuset_alloc_size (num)


Does this patch need __inline defined e.g.

   +#include 

did you perhaps include this directly in your test cases?


-static inline size_t
+static __inline size_t

...


No, not directly.  The test case with the shortest list of #includes has:
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 

So it's apparently defined by one of those or some sub-include.  But indeed it's 
not safe to depend on that so I will try harder to figure out what other 
occurrences of __inline in the Cygwin source tree are depending on for the definition.

Thanks,

..mark

[PATCH] Cygwin: Make safe for c89 compilations

[Mark Geisert]

Three modifications to include/sys/cpuset.h:
* Change C++-style comments to C-style also supported by C++
* Change "inline" to "__inline" on code lines
* Don't declare loop variables on for-loop init clauses

Tested by first reproducing the reported issue with home-grown test
programs by compiling with gcc option "-std=c89", then compiling again
using the modified . Other "-std=" options tested too.

Addresses: https://cygwin.com/pipermail/cygwin-patches/2023q3/012308.html
Fixes: 315e5fbd99ec ("Cygwin: Fix type mismatch on sys/cpuset.h")

---
 winsup/cygwin/include/sys/cpuset.h | 47 --
 winsup/cygwin/release/3.4.7|  3 ++
 2 files changed, 28 insertions(+), 22 deletions(-)

diff --git a/winsup/cygwin/include/sys/cpuset.h 
b/winsup/cygwin/include/sys/cpuset.h
index d83359fdf..01576b041 100644
--- a/winsup/cygwin/include/sys/cpuset.h
+++ b/winsup/cygwin/include/sys/cpuset.h
@@ -14,9 +14,9 @@ extern "C" {
 #endif
 
 typedef __SIZE_TYPE__ __cpu_mask;
-#define __CPU_SETSIZE 1024  // maximum number of logical processors tracked
-#define __NCPUBITS (8 * sizeof (__cpu_mask))  // max size of processor group
-#define __CPU_GROUPMAX (__CPU_SETSIZE / __NCPUBITS)  // maximum group number
+#define __CPU_SETSIZE 1024  /* maximum number of logical processors tracked */
+#define __NCPUBITS (8 * sizeof (__cpu_mask))  /* max size of processor group */
+#define __CPU_GROUPMAX (__CPU_SETSIZE / __NCPUBITS)  /* maximum group number */
 
 #define __CPUELT(cpu)  ((cpu) / __NCPUBITS)
 #define __CPUMASK(cpu) ((__cpu_mask) 1 << ((cpu) % __NCPUBITS))
@@ -32,21 +32,21 @@ int __sched_getaffinity_sys (pid_t, size_t, cpu_set_t *);
 /* These macros alloc or free dynamically-sized cpu sets of size 'num' cpus.
Allocations are padded such that full-word operations can be done easily. */
 #define CPU_ALLOC_SIZE(num) __cpuset_alloc_size (num)
-static inline size_t
+static __inline size_t
 __cpuset_alloc_size (int num)
 {
   return (size_t) (((num + __NCPUBITS - 1) / __NCPUBITS) * sizeof 
(__cpu_mask));
 }
 
 #define CPU_ALLOC(num) __cpuset_alloc (num)
-static inline cpu_set_t *
+static __inline cpu_set_t *
 __cpuset_alloc (int num)
 {
   return (cpu_set_t *) __builtin_malloc (CPU_ALLOC_SIZE(num));
 }
 
 #define CPU_FREE(set) __cpuset_free (set)
-static inline void
+static __inline void
 __cpuset_free (cpu_set_t *set)
 {
   __builtin_free (set);
@@ -54,14 +54,14 @@ __cpuset_free (cpu_set_t *set)
 
 /* These _S macros operate on dynamically-sized cpu sets of size 'siz' bytes */
 #define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
-static inline void
+static __inline void
 __cpuset_zero_s (size_t siz, cpu_set_t *set)
 {
   (void) __builtin_memset (set, 0, siz);
 }
 
 #define CPU_SET_S(cpu, siz, set) __cpuset_set_s (cpu, siz, set)
-static inline void
+static __inline void
 __cpuset_set_s (int cpu, size_t siz, cpu_set_t *set)
 {
   if (cpu >= 0 && cpu < 8 * siz)
@@ -69,7 +69,7 @@ __cpuset_set_s (int cpu, size_t siz, cpu_set_t *set)
 }
 
 #define CPU_CLR_S(cpu, siz, set) __cpuset_clr_s (cpu, siz, set)
-static inline void
+static __inline void
 __cpuset_clr_s (int cpu, size_t siz, cpu_set_t *set)
 {
   if (cpu >= 0 && cpu < 8 * siz)
@@ -77,7 +77,7 @@ __cpuset_clr_s (int cpu, size_t siz, cpu_set_t *set)
 }
 
 #define CPU_ISSET_S(cpu, siz, set) __cpuset_isset_s (cpu, siz, set)
-static inline int
+static __inline int
 __cpuset_isset_s (int cpu, size_t siz, cpu_set_t *set)
 {
   int res = 0;
@@ -87,45 +87,48 @@ __cpuset_isset_s (int cpu, size_t siz, cpu_set_t *set)
 }
 
 #define CPU_COUNT_S(siz, set) __cpuset_count_s (siz, set)
-static inline int
+static __inline int
 __cpuset_count_s (size_t siz, cpu_set_t *set)
 {
-  int res = 0;
-  for (int i = 0; i < siz / sizeof (__cpu_mask); i++)
+  int i, res = 0;
+  for (i = 0; i < siz / sizeof (__cpu_mask); i++)
 res += __builtin_popcountl ((set)->__bits[i]);
   return res;
 }
 
 #define CPU_AND_S(siz, dst, src1, src2) __cpuset_and_s (siz, dst, src1, src2)
-static inline void
+static __inline void
 __cpuset_and_s (size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
 {
-  for (int i = 0; i < siz / sizeof (__cpu_mask); i++)
+  int i;
+  for (i = 0; i < siz / sizeof (__cpu_mask); i++)
 (dst)->__bits[i] = (src1)->__bits[i] & (src2)->__bits[i];
 }
 
 #define CPU_OR_S(siz, dst, src1, src2) __cpuset_or_s (siz, dst, src1, src2)
-static inline void
+static __inline void
 __cpuset_or_s (size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
 {
-  for (int i = 0; i < siz / sizeof (__cpu_mask); i++)
+  int i;
+  for (i = 0; i < siz / sizeof (__cpu_mask); i++)
 (dst)->__bits[i] = (src1)->__bits[i] | (src2)->__bits[i];
 }
 
 #define CPU_XOR_S(siz, dst, src1, src2) __cpuset_xor_s (siz, dst, src1, src2)
-static inline void
+static __inline void
 __cpuset_xor_s (size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
 {
-  for (int i = 0; i < siz / sizeof (__cpu_mask); i++)
+  int i;
+  for (i = 0; i < siz / sizeof (__cpu_mask); i++)
 

Re: [PATCH v2] Cygwin: Fix type mismatch on sys/cpuset.h

[Mark Geisert]

Mark Geisert wrote:
[...]

Thanks for the report and investigations.  I'll address this shortly.


A candidate patch for 3.4.7 is incoming.  If it passes muster I'll fire off a 
patch for 3.3.6.  I don't know why I'm using military terminology.  Independence 
Day soon in the US, I guess.

Cheers,

..mark

Re: [PATCH v2] Cygwin: Fix type mismatch on sys/cpuset.h

[Mark Geisert]

Hi all,

Brian Inglis wrote:

On 2023-07-01 08:20, Jon Turney wrote:

On 14/03/2023 08:56, Mark Geisert wrote:

Addresses https://cygwin.com/pipermail/cygwin/2023-March/253220.html

Take the opportunity to follow FreeBSD's and Linux's lead in recasting
macro inline code as calls to static inline functions.  This allows the
macros to be type-safe.  In addition, added a lower bound check to the
functions that use a cpu number to avoid a potential buffer underrun on
a bad argument.  h/t to Corinna for the advice on recasting.

Fixes: 362b98b49af5 ("Cygwin: Implement CPU_SET(3) macros")


There's been a couple of reports that this leads to compilation failures when 
this header is included in -std=c89 mode.

Solutions are probably something like:
* Use __inline__ rather than inline
* Don't use initial declaration inside the for loop's init-statement
e.g. https://github.com/tinyproxy/tinyproxy/issues/499


/usr/include/sys/cdefs.h appears to support using __inline instead of __inline__ 
or inline, and is included many places __inline is used: it appears to be 
necessary, but may not be sufficient.


Thanks for the report and investigations.  I'll address this shortly.

..mark

Re: cygwin1.dll calls assert before cygwin command hangs

[Mark Geisert via Cygwin]

Sorry, the second gdb command should be
info line *__assert+0x42a4

(Note the change in symbol name: two "_" there)


..mark

--
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: cygwin1.dll calls assert before cygwin command hangs

[Mark Geisert via Cygwin]

Hi Derek,

Derek Pagel via Cygwin wrote:

We've had problems with slow Cygwin commands, so we were able to capture a 
stack trace when the 'cp' program taking a long time to complete, and we 
noticed in the stack trace that the last thing cygwin1.dll does is calls 
assert. What might that suggest? And are there any situations that would cause 
an error on initialization?


This report is not specific enough to investigate at the moment.  Do all commands 
run slow?  If not, which commands run slowly?  Has the problem manifested recently 
or has it always been the case?  More below...



Stack Trace:
Child cmd.exe -> cp.exe -> cmd.exe -> cp.exe:


How exactly are you running Cygwin commands?  From a Command Prompt or a bash 
shell, for instance?  And how do you get the process tree you are indicating? 
What is the 'cp' command doing?  Paste the text of the command, please.



ntoskrnl.exe!KeSynchronizeExecution+0x5a36
ntoskrnl.exe!KeWaitForMutexObject+0x1c27
ntoskrnl.exe!KeWaitForMutexObject+0x1799
ntoskrnl.exe!KeWaitForMutexObject+0x520
ntoskrnl.exe!IoQueueWorkItemEx+0x1a4
ntoskrnl.exe!RtlInitializeSid+0x40d5
ntoskrnl.exe!FsRtlRegisterFltMgrCalls+0x84225
ntoskrnl.exe!SeSetSecurityDescriptorInfo+0x269e
ntoskrnl.exe!SeSetSecurityDescriptorInfo+0x2476
ntoskrnl.exe!SeSetSecurityDescriptorInfo+0x2f05
ntoskrnl.exe!SeSetSecurityDescriptorInfo+0x2af8
ntoskrnl.exe!setjmpex+0x7925
ntdll.dll!ZwQueryObject+0x14
cygwin1.dll!dlfork+0xa0
cygwin1.dll!dlfork+0x24d3
cygwin1.dll!dlfork+0x2a9f
cygwin1.dll!cygwin_dll_init+0x38f
cygwin1.dll!_assert+0x41f6
cygwin1.dll!_assert+0x42a4


Windows tools won't show full Cygwin debug info.  "_assert" in the above just 
happens to be the nearest global symbol below the actual address.  To get the 
actual address in a meaningful fashion, install the cygwin-debuginfo package, then run

gdb -q /usr/lib/debug/usr/bin/cygwin1.dll.dbg
info line __assert+0x42a4
(Note the change in symbol name: two "_" there)
This should work, but this is likely the wrong way to investigate the problem.

..mark

--
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

[PATCH v2] Cygwin: Fix type mismatch on sys/cpuset.h

[Mark Geisert]

Addresses https://cygwin.com/pipermail/cygwin/2023-March/253220.html

Take the opportunity to follow FreeBSD's and Linux's lead in recasting
macro inline code as calls to static inline functions.  This allows the
macros to be type-safe.  In addition, added a lower bound check to the
functions that use a cpu number to avoid a potential buffer underrun on
a bad argument.  h/t to Corinna for the advice on recasting.

Fixes: 362b98b49af5 ("Cygwin: Implement CPU_SET(3) macros")

---
 winsup/cygwin/include/sys/cpuset.h | 138 -
 winsup/cygwin/release/3.4.7|   5 ++
 2 files changed, 101 insertions(+), 42 deletions(-)
 create mode 100644 winsup/cygwin/release/3.4.7

diff --git a/winsup/cygwin/include/sys/cpuset.h 
b/winsup/cygwin/include/sys/cpuset.h
index 572565165..d83359fdf 100644
--- a/winsup/cygwin/include/sys/cpuset.h
+++ b/winsup/cygwin/include/sys/cpuset.h
@@ -31,50 +31,104 @@ int __sched_getaffinity_sys (pid_t, size_t, cpu_set_t *);
 
 /* These macros alloc or free dynamically-sized cpu sets of size 'num' cpus.
Allocations are padded such that full-word operations can be done easily. */
-#define CPU_ALLOC_SIZE(num) ((num+__NCPUBITS-1) / __NCPUBITS) * sizeof 
(__cpu_mask)
-#define CPU_ALLOC(num)  __builtin_malloc (CPU_ALLOC_SIZE(num))
-#define CPU_FREE(set)   __builtin_free (set)
+#define CPU_ALLOC_SIZE(num) __cpuset_alloc_size (num)
+static inline size_t
+__cpuset_alloc_size (int num)
+{
+  return (size_t) (((num + __NCPUBITS - 1) / __NCPUBITS) * sizeof 
(__cpu_mask));
+}
+
+#define CPU_ALLOC(num) __cpuset_alloc (num)
+static inline cpu_set_t *
+__cpuset_alloc (int num)
+{
+  return (cpu_set_t *) __builtin_malloc (CPU_ALLOC_SIZE(num));
+}
+
+#define CPU_FREE(set) __cpuset_free (set)
+static inline void
+__cpuset_free (cpu_set_t *set)
+{
+  __builtin_free (set);
+}
 
 /* These _S macros operate on dynamically-sized cpu sets of size 'siz' bytes */
-#define CPU_ZERO_S(siz, set)__builtin_memset (set, 0, siz)
-
-#define CPU_SET_S(cpu,siz,set) \
-   if (cpu < 8 * siz) \
- (set)->__bits[__CPUELT(cpu)] |= __CPUMASK(cpu);
-
-#define CPU_CLR_S(cpu,siz,set) \
-   if (cpu < 8 * siz) \
- (set)->__bits[__CPUELT(cpu)] &= ~(__CPUMASK(cpu));
-
-#define CPU_ISSET_S(cpu,siz,set) \
-  ({int res = 0; \
-   if (cpu < 8 * siz) \
- res = !!((set)->__bits[__CPUELT(cpu)] & __CPUMASK(cpu)); \
-   res;})
-
-#define CPU_COUNT_S(siz, set) \
-  ({int tot = 0;\
-   for (int i = 0; i < siz / sizeof (__cpu_mask); i++) \
- tot += __builtin_popcountl ((set)->__bits[i]); \
-   tot;})
-
-#define CPU_AND_S(siz, dst, src1, src2) \
-   for (int i = 0; i < siz / sizeof (__cpu_mask); i++) \
- (dst)->__bits[i] = (src1)->__bits[i] & (src2)->__bits[i];
-
-#define CPU_OR_S(siz, dst, src1, src2) \
-   for (int i = 0; i < siz / sizeof (__cpu_mask); i++) \
- (dst)->__bits[i] = (src1)->__bits[i] | (src2)->__bits[i];
-
-#define CPU_XOR_S(siz, dst, src1, src2) \
-   for (int i = 0; i < siz / sizeof (__cpu_mask); i++) \
- (dst)->__bits[i] = (src1)->__bits[i] ^ (src2)->__bits[i];
-
-#define CPU_EQUAL_S(siz, src1, src2) \
-  ({int res = 1; \
-   for (int i = 0; res && i < siz / sizeof (__cpu_mask); i++) \
- res &= (src1)->__bits[i] == (src2)->__bits[i]; \
-   res;})
+#define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
+static inline void
+__cpuset_zero_s (size_t siz, cpu_set_t *set)
+{
+  (void) __builtin_memset (set, 0, siz);
+}
+
+#define CPU_SET_S(cpu, siz, set) __cpuset_set_s (cpu, siz, set)
+static inline void
+__cpuset_set_s (int cpu, size_t siz, cpu_set_t *set)
+{
+  if (cpu >= 0 && cpu < 8 * siz)
+(set)->__bits[__CPUELT(cpu)] |= __CPUMASK(cpu);
+}
+
+#define CPU_CLR_S(cpu, siz, set) __cpuset_clr_s (cpu, siz, set)
+static inline void
+__cpuset_clr_s (int cpu, size_t siz, cpu_set_t *set)
+{
+  if (cpu >= 0 && cpu < 8 * siz)
+(set)->__bits[__CPUELT(cpu)] &= ~(__CPUMASK(cpu));
+}
+
+#define CPU_ISSET_S(cpu, siz, set) __cpuset_isset_s (cpu, siz, set)
+static inline int
+__cpuset_isset_s (int cpu, size_t siz, cpu_set_t *set)
+{
+  int res = 0;
+  if (cpu >= 0 && cpu < 8 * siz)
+res = !!((set)->__bits[__CPUELT(cpu)] & __CPUMASK(cpu));
+  return res;
+}
+
+#define CPU_COUNT_S(siz, set) __cpuset_count_s (siz, set)
+static inline int
+__cpuset_count_s (size_t siz, cpu_set_t *set)
+{
+  int res = 0;
+  for (int i = 0; i < siz / sizeof (__cpu_mask); i++)
+res += __builtin_popcountl ((set)->__bits[i]);
+  return res;
+}
+
+#define CPU_AND_S(siz, dst, src1, src2) __cpuset_and_s (siz, dst, src1, src2)
+static inline void
+__cpuset_and_s (size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
+{
+  for (int i = 0; i < siz / sizeof (__cpu_mask); i++)
+(dst)->__bits[i] = (src1)->__bits[i] & (src2)->__bits[i];
+}
+
+#define CPU_OR_S(siz, dst, src1, src2) __cpuset_or_s (siz, dst, src1, src2)
+static inline void
+__cpuset_or_s (size_t siz, cpu_set_t *dst, cpu_set_t *src1, 

[PATCH] Cygwin: Fix type mismatch on sys/cpuset.h -- relnote 3.4.6

[Mark Geisert]

---
 winsup/cygwin/release/3.4.6 | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/winsup/cygwin/release/3.4.6 b/winsup/cygwin/release/3.4.6
index ccc168a95..ed124ed37 100644
--- a/winsup/cygwin/release/3.4.6
+++ b/winsup/cygwin/release/3.4.6
@@ -12,3 +12,6 @@ Addresses: 
https://cygwin.com/pipermail/cygwin/2023-February/253037.html
 
 Don't accidentally drop the default ACEs when chmod'ing directories.
 Addresses: https://cygwin.com/pipermail/cygwin/2023-February/253037.html
+
+Fix CPU_SET(3) macro type mismatch by making the macros type-safe.
+Addresses https://cygwin.com/pipermail/cygwin/2023-March/253220.html
-- 
2.39.0

[PATCH] Cygwin: Fix type mismatch on sys/cpuset.h

[Mark Geisert]

Addresses https://cygwin.com/pipermail/cygwin/2023-March/253220.html

Take the opportunity to follow FreeBSD's and Linux's lead in recasting
macro inline code as calls to static inline functions.  This allows the
macros to be type-safe.  In addition, added a lower bound check to the
functions that use a cpu number to avoid a potential buffer underrun on
a bad argument.  h/t to Corinna for the advice on recasting.

---
 winsup/cygwin/include/sys/cpuset.h | 138 -
 1 file changed, 96 insertions(+), 42 deletions(-)

diff --git a/winsup/cygwin/include/sys/cpuset.h 
b/winsup/cygwin/include/sys/cpuset.h
index 572565165..d83359fdf 100644
--- a/winsup/cygwin/include/sys/cpuset.h
+++ b/winsup/cygwin/include/sys/cpuset.h
@@ -31,50 +31,104 @@ int __sched_getaffinity_sys (pid_t, size_t, cpu_set_t *);
 
 /* These macros alloc or free dynamically-sized cpu sets of size 'num' cpus.
Allocations are padded such that full-word operations can be done easily. */
-#define CPU_ALLOC_SIZE(num) ((num+__NCPUBITS-1) / __NCPUBITS) * sizeof 
(__cpu_mask)
-#define CPU_ALLOC(num)  __builtin_malloc (CPU_ALLOC_SIZE(num))
-#define CPU_FREE(set)   __builtin_free (set)
+#define CPU_ALLOC_SIZE(num) __cpuset_alloc_size (num)
+static inline size_t
+__cpuset_alloc_size (int num)
+{
+  return (size_t) (((num + __NCPUBITS - 1) / __NCPUBITS) * sizeof 
(__cpu_mask));
+}
+
+#define CPU_ALLOC(num) __cpuset_alloc (num)
+static inline cpu_set_t *
+__cpuset_alloc (int num)
+{
+  return (cpu_set_t *) __builtin_malloc (CPU_ALLOC_SIZE(num));
+}
+
+#define CPU_FREE(set) __cpuset_free (set)
+static inline void
+__cpuset_free (cpu_set_t *set)
+{
+  __builtin_free (set);
+}
 
 /* These _S macros operate on dynamically-sized cpu sets of size 'siz' bytes */
-#define CPU_ZERO_S(siz, set)__builtin_memset (set, 0, siz)
-
-#define CPU_SET_S(cpu,siz,set) \
-   if (cpu < 8 * siz) \
- (set)->__bits[__CPUELT(cpu)] |= __CPUMASK(cpu);
-
-#define CPU_CLR_S(cpu,siz,set) \
-   if (cpu < 8 * siz) \
- (set)->__bits[__CPUELT(cpu)] &= ~(__CPUMASK(cpu));
-
-#define CPU_ISSET_S(cpu,siz,set) \
-  ({int res = 0; \
-   if (cpu < 8 * siz) \
- res = !!((set)->__bits[__CPUELT(cpu)] & __CPUMASK(cpu)); \
-   res;})
-
-#define CPU_COUNT_S(siz, set) \
-  ({int tot = 0;\
-   for (int i = 0; i < siz / sizeof (__cpu_mask); i++) \
- tot += __builtin_popcountl ((set)->__bits[i]); \
-   tot;})
-
-#define CPU_AND_S(siz, dst, src1, src2) \
-   for (int i = 0; i < siz / sizeof (__cpu_mask); i++) \
- (dst)->__bits[i] = (src1)->__bits[i] & (src2)->__bits[i];
-
-#define CPU_OR_S(siz, dst, src1, src2) \
-   for (int i = 0; i < siz / sizeof (__cpu_mask); i++) \
- (dst)->__bits[i] = (src1)->__bits[i] | (src2)->__bits[i];
-
-#define CPU_XOR_S(siz, dst, src1, src2) \
-   for (int i = 0; i < siz / sizeof (__cpu_mask); i++) \
- (dst)->__bits[i] = (src1)->__bits[i] ^ (src2)->__bits[i];
-
-#define CPU_EQUAL_S(siz, src1, src2) \
-  ({int res = 1; \
-   for (int i = 0; res && i < siz / sizeof (__cpu_mask); i++) \
- res &= (src1)->__bits[i] == (src2)->__bits[i]; \
-   res;})
+#define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
+static inline void
+__cpuset_zero_s (size_t siz, cpu_set_t *set)
+{
+  (void) __builtin_memset (set, 0, siz);
+}
+
+#define CPU_SET_S(cpu, siz, set) __cpuset_set_s (cpu, siz, set)
+static inline void
+__cpuset_set_s (int cpu, size_t siz, cpu_set_t *set)
+{
+  if (cpu >= 0 && cpu < 8 * siz)
+(set)->__bits[__CPUELT(cpu)] |= __CPUMASK(cpu);
+}
+
+#define CPU_CLR_S(cpu, siz, set) __cpuset_clr_s (cpu, siz, set)
+static inline void
+__cpuset_clr_s (int cpu, size_t siz, cpu_set_t *set)
+{
+  if (cpu >= 0 && cpu < 8 * siz)
+(set)->__bits[__CPUELT(cpu)] &= ~(__CPUMASK(cpu));
+}
+
+#define CPU_ISSET_S(cpu, siz, set) __cpuset_isset_s (cpu, siz, set)
+static inline int
+__cpuset_isset_s (int cpu, size_t siz, cpu_set_t *set)
+{
+  int res = 0;
+  if (cpu >= 0 && cpu < 8 * siz)
+res = !!((set)->__bits[__CPUELT(cpu)] & __CPUMASK(cpu));
+  return res;
+}
+
+#define CPU_COUNT_S(siz, set) __cpuset_count_s (siz, set)
+static inline int
+__cpuset_count_s (size_t siz, cpu_set_t *set)
+{
+  int res = 0;
+  for (int i = 0; i < siz / sizeof (__cpu_mask); i++)
+res += __builtin_popcountl ((set)->__bits[i]);
+  return res;
+}
+
+#define CPU_AND_S(siz, dst, src1, src2) __cpuset_and_s (siz, dst, src1, src2)
+static inline void
+__cpuset_and_s (size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
+{
+  for (int i = 0; i < siz / sizeof (__cpu_mask); i++)
+(dst)->__bits[i] = (src1)->__bits[i] & (src2)->__bits[i];
+}
+
+#define CPU_OR_S(siz, dst, src1, src2) __cpuset_or_s (siz, dst, src1, src2)
+static inline void
+__cpuset_or_s (size_t siz, cpu_set_t *dst, cpu_set_t *src1, cpu_set_t *src2)
+{
+  for (int i = 0; i < siz / sizeof (__cpu_mask); i++)
+(dst)->__bits[i] = (src1)->__bits[i] | (src2)->__bits[i];
+}
+
+#define 

Re: type mismatch on cpuset.h

[Mark Geisert]

[Redirected here from the main mailing list...]

Hi Corinna,

Corinna Vinschen via Cygwin wrote:

Hi Mark,

On Mar  6 07:57, Marco Atzeri via Cygwin wrote:

Hi,

building latest gdal I noticed a type mismatch, that forced me to build
with "-fpermissive"

on /usr/include/sys/cpuset.h

  #define CPU_ALLOC(num)  __builtin_malloc (CPU_ALLOC_SIZE(num))


but on
https://linux.die.net/man/3/cpu_alloc

  cpu_set_t *CPU_ALLOC(int num_cpus)


so void* versus cpu_set_t*


Marco is correct.  cpuset.h was your pet project a while back.  Would
you like to pick it up?  Maybe we should convert all the macros into
type-safe inline functions, or macros calling type-safe (inline)
functions, as on Linux as well as on BSD?


As far as I can tell from online docs, the CPU_SET(3) macros are still macros on 
Linux, though they are documented with prototypes as if they were functions.  I 
don't immediately see a need to change our cpuset.h for this.


I'm also uncertain what exactly you mean by "type-safe" in this context.  Could 
you please give me an example for one of the macros?


I desk-checked all the macros vs their prototypes and I believe CPU_ALLOC that 
Marco ran into is the only faulty one.  It could be fixed with a cast.  CPU_FREE's 
result is void so I should make sure __builtin_free() corresponds. 
CPU_ALLOC_SIZE's result is size_t and I believe the macro is correct as-is because 
it is an expression using untyped integers and sizeof()s, the latter are 
size_t-returning.


The other few macros that return results return int, and those are precisely the 
ones whose inline code uses an int variable to accumulate a result.


If there is some other consideration I'm not seeing, e.g. readability, please let 
me know.  Otherwise I don't really see a need for changes here (modulo casting 
return values properly where needed).


..mark

Re: type mismatch on cpuset.h

[Mark Geisert via Cygwin]

Hi Corinna, Marco,

I will look into this shortly.  Sorry for the inconvenience.

..mark


On Mon, 6 Mar 2023, Corinna Vinschen wrote:

Hi Mark,

On Mar  6 07:57, Marco Atzeri via Cygwin wrote:

Hi,

building latest gdal I noticed a type mismatch, that forced me to build
with "-fpermissive"

on /usr/include/sys/cpuset.h

 #define CPU_ALLOC(num)  __builtin_malloc (CPU_ALLOC_SIZE(num))


but on
https://linux.die.net/man/3/cpu_alloc

 cpu_set_t *CPU_ALLOC(int num_cpus)


so void* versus cpu_set_t*


Marco is correct.  cpuset.h was your pet project a while back.  Would
you like to pick it up?  Maybe we should convert all the macros into
type-safe inline functions, or macros calling type-safe (inline)
functions, as on Linux as well as on BSD?


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

Test failures from 'cygport python39.cygport test' etc

[Mark Geisert via Cygwin-apps]

Hi Marco,
I'm seeing test failures and hangs on the 'cygport test' step for both 
Python 3.9 and 3.8.  3.9 has 37 failures out of 423 tests, 3.8 has 39 
failures out of 425 tests.  Both releases have 3 tests hanging after as 
much as 20 minutes wait w/no cputime: test_asyncio, test_ssl, test_io.


My procedure is to (with cygport) prep, build, test.  Do I need to 
'install' before 'test'?  I believe I tried that but it made no 
difference.  Is there a different procedure you use to test the Python 
builds?

Thanks & Regards,

..mark

Concerning Python patch 3.6.12-socketmodule.patch -- ping Marco

[Mark Geisert via Cygwin-apps]

Hi Marco,
When I said "could you handle" I meant I would author the revised patch, test it 
locally, and pass it on to you to integrate into the Cygwin Python packages.  Does 
that sound workable to you?

Thank you,

..mark

 Forwarded Message 
Subject: Concerning Python patch 3.6.12-socketmodule.patch
Date: Mon, 7 Nov 2022 23:07:02 -0800
From: Mark Geisert 
To: cygwin-apps@cygwin.com

Hi Marco,
Recently there's been a complaint about that patch on the Cygwin mailing list. The 
patch was meant to allow same-machine communication between Cygwin Python programs 
via an AF_UNIX socket.  The patch works because both ends of the connection are 
Python programs that have the patch.


The problem reported by the user is that when a Python program attempts to 
communicate with ssh-agent, the connection freezes.  This is due to the above 
patch being applied only to the Python end (of course).


Given that we need the patch for Python build tests, could you handle an 
environment variable setting to choose the behavior of the patch?
In other words. a revised patch would consult an environment variable 
PYTHON_NET_DISABLE_CREDENTIALS to decide whether to do what the current patch 
does.  I guess the pythonXX.cygport file would have to define that env var.


Does that sound like a workable scheme to you?
Thanks,

..mark

Concerning Python patch 3.6.12-socketmodule.patch

[Mark Geisert]

Hi Marco,
Recently there's been a complaint about that patch on the Cygwin mailing list. 
The patch was meant to allow same-machine communication between Cygwin Python 
programs via an AF_UNIX socket.  The patch works because both ends of the 
connection are Python programs that have the patch.


The problem reported by the user is that when a Python program attempts to 
communicate with ssh-agent, the connection freezes.  This is due to the above 
patch being applied only to the Python end (of course).


Given that we need the patch for Python build tests, could you handle an 
environment variable setting to choose the behavior of the patch?
In other words. a revised patch would consult an environment variable 
PYTHON_NET_DISABLE_CREDENTIALS to decide whether to do what the current patch 
does.  I guess the pythonXX.cygport file would have to define that env var.


Does that sound like a workable scheme to you?
Thanks,

..mark

Re: Python regression related to unix sockets

[Mark Geisert]

Following up to myself...
Mark Geisert wrote:

Hi Fabian,

Fabian Henze wrote:

Hi all,

This is a follow-up on a mail thread from February 2021.

Mark Geisert via Cygwin wrote:

Fabian Henze via Cygwin wrote:

Hi Cygwin users,
I noticed a regression in the recent Python packages: Between version
3.6.10-1 and 3.6.12-2, accessing the SSH agent via the paramiko python
package broke. When a ssh agent is used, paramiko tries to connect to
it via the unix socket and just freezes. Python 3.8 is also affected,
but I don't know which was the last working one.
I was able to pinpoint that error to 3.6.12-socketmodule.patch [1].
Reverting/removing the patch fixes the ssh agent access.

[...]

Can you please check if you are able to reproduce that? I uploaded a
script [3] for that.

Best regards,
Fabian Henze


Thanks for the report and sorry you've run into this.  The patch is a 
workaround that's evidently too draconian.  I will debug the situation using 
your testcase.

Thank you very much for the testcase.


Did you (or anyone else) make any progress on this that you can share?
Unfortunately the issue still persists in all current python versions.
If no one has time to debug and fix this, would it be an option to remove the
3.6.12-socketmodule.patch that is causing the regression since it only fixes a
theoretical problem in unit tests, but causes real-world issues? Maybe the
upcoming (?) Python 3.10 or 3.11 bump would be a good candidate to do so?

[...]
Let me find my notes for this issue and see if I can improve on the patch or find 
some other solution for now-current versions of Python and/or Cygwin DLL.


Right. I determined there was nothing further I could do. The conclusion I stated 
in the thread you quoted from was this (and it still applies):

8<
It's a limitation of the patch.  It was meant to allow Python programs on the 
same
computer to communicate via AF_UNIX sockets, by working around less than perfect
support in the Cygwin DLL.  But you've got a Python program trying to 
communicate
with a non-Python program, and that fails because the patch is only applied on 
the
Python end of the connection.

If you can continue to run without the problematic patch, that's your best 
option.
>8

BTW, what you called "a theoretical problem in unit tests" was of great concern to 
the Cygwin Python maintainer at the time. We test our Python builds before 
releasing them.


The best "solution" I can think of ATM, and it's not great, is to have the 
behavior you want be the default and an environment variable such as 
PYTHON_NET_DISABLE_CREDENTIALS to choose the other behavior. I will consult the 
Cygwin Python maintainer to see if this is acceptable.


..mark


--
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