Problem with mingw64-x86_64-qt5ct
My apologies for sending this request to the wrong list (cygwin-apps). I have been trying to run the following command from my cygwin environment: /usr/x86_64-w64-mingw32/sys-root/mingw/bin/qt5ct.exe This results in a dialog saying that the following library could not be found: libqt5ct-style.so I did a search for this file both here and online and could not find it. Is there a solution for this issue? Sincerely, David R. Bergstein -- 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: no regular expressions in less
Yes, 32bit. On 21.07.2021 21:18, Takashi Yano wrote: > On Wed, 21 Jul 2021 20:43:54 +0300 > Basin Ilya via Cygwin wrote: >> Hi list. >> I've just noticed that regexp search works identically to exact match search >> in less and it prints this: >> >> $ /usr/bin/less --version >> less 581.2 (no regular expressions) > > Are you using 32bit version of cygwin? > In my environment, this only happens in 32bit cygwin. > > In 64 bit cygwin, it says: > > less 581.2 (PCRE2 regular expressions) > Copyright (C) 1984-2021 Mark Nudelman > > -- 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: bug
>rm *.log > 0 [main] rm 15584 find_fast_cwd: WARNING: Couldn't compute FAST_CWD >pointer. Please report this problem to >the public mailing list cygwin@cygwin.com >I was using Cmder through powershell on windows 10. I cannot find the logs. https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings -- 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
bug
rm *.log 0 [main] rm 15584 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com I was using Cmder through powershell on windows 10. I cannot find the logs. -- 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: postinstall: fontconfig abnormal exit
On 7/20/2021 1:00 PM, Brian Inglis wrote:
> On 2020-09-12 06:56, Ken Brown via Cygwin wrote:
For fontconfig fc-cache-1 appears to have been creating thousands (on Cygwin 64
millions) of small <1KB
/var/cache/fontconfig/%8x-%4x-%4x-%4x-%12x-le{64,32d8}.cache-7 files.
The problems could have originally been caused by an old bug:
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/107
combined with many font additions around that time, mainly working on Cygwin 64,
where I use X, and manually run fontconfig postinstall script, to try to avoid
long setup postinstalls, whereas on Cygwin 32 I don't use X or manually run
postinstall scripts, just get run after setup.
I have about 200 Windows MS font files, 1000 non-MS font files, and about 800
Cygwin font files, from multiple distros and elsewhere, including some with full
BMP coverage, some with SMP coverage, some for fallback code points, others with
group ranges.
I rm'ed -rf /var/cache/fontconfig/ with a few thousand files on Cygwin 32 and
rebuilt it okay with only 65 cache files.
I tried rm -rf /var/cache/fontconfig/ on Cygwin 64 but got many permission
errors and killed it.
The preremove script for libfontconfig1 should remove all those cache files
every time libfontconfig1 is updated, so you should have gotten a fresh start
every once in a while. Apparently something went wrong.
I gave up waiting for ls -U to show any results on Cygwin 64 or Explorer on that
dir to show any file details, but cmd /c dir | less displays the base info for
hundreds of thousands of files, and wc reports millions.
I am still waiting for an elevated cmd to rmdir /s /q fontconfig there!
Do you know why fc-cache-1 is run rather than fc-cache and what the difference
is?
They're identical. It's just a packaging issue. fc-cache is in the fontconfig
package, and fc-cache-1 is in the libfontconfig1 package. That way fc-cache-1
is available for use in postinstall scripts for users who install libfontconfig1
(probably because something requires it) but not fontconfig.
What would give you useful information once I have the fontconfig cache cleared?
Might running FC_DEBUG=65535 fc-cache-1 -fsv provide useful info?
Or do so with strace?
Would running file on the font files give enough info about properties to be of
any help?
I'm not an expert on fontconfig, so I probably can't help.
What is the best approach to get the minimal cache files recreated?
I would expect that this would always happen as a result of running setup and
letting the preremove/postinstall scripts do their job. I don't know what went
wrong in your case.
What is the best approach to avoid thousand of cache files in future?
Again, I don't know why that happened in the first place.
Ken
--
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: no regular expressions in less
On 21.07.2021 20:21, Marco Atzeri wrote: On 21.07.2021 19:43, Basin Ilya via Cygwin wrote: Hi list. I've just noticed that regexp search works identically to exact match search in less and it prints this: $ /usr/bin/less --version less 581.2 (no regular expressions) How to solve this? Hi Basin, it seems missing for the 32bit version, on 64bit it is present. new 32bit version less-581.2-2 is on the way. Regards Marco -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: no regular expressions in less
On 21.07.2021 19:43, Basin Ilya via Cygwin wrote: Hi list. I've just noticed that regexp search works identically to exact match search in less and it prints this: $ /usr/bin/less --version less 581.2 (no regular expressions) Copyright (C) 1984-2021 Mark Nudelman less comes with NO WARRANTY, to the extent permitted by law. For information about the terms of redistribution, see the file named README in the less distribution. Home page: https://greenwoodsoftware.com/less How to solve this? Hi Basin, it seems missing for the 32bit version, on 64bit it is present. $ less --version less 581.2 (PCRE2 regular expressions) Copyright (C) 1984-2021 Mark Nudelman But for both the library is present $ cygcheck -cd |grep "pcre.*devel" libpcre-devel 8.45-1 libpcre2-devel 10.37-1 let me investigate why the 32bit has such issue. Regards Marco -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: no regular expressions in less
On Wed, 21 Jul 2021 20:43:54 +0300 Basin Ilya via Cygwin wrote: > Hi list. > I've just noticed that regexp search works identically to exact match search > in less and it prints this: > > $ /usr/bin/less --version > less 581.2 (no regular expressions) Are you using 32bit version of cygwin? In my environment, this only happens in 32bit cygwin. In 64 bit cygwin, it says: less 581.2 (PCRE2 regular expressions) Copyright (C) 1984-2021 Mark Nudelman -- Takashi Yano -- 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: Fix nanosleep returning negative rem
> I can get it easily get this on my desktop (AMD Ryzen Threadripper 3990X) but
> not at all on my laptop (Intel Core i7-8650U)
Not sure if that's really related but:
Have you checked what is your default Windows timer resolution? Some
applications change it from the default
100HZ to 1000HZ (by e.g. using timeBeginPeriod(1) -- MS Edge does this, and
Chrome, I think, but not Firefox -- yet
the change is actually _global_ as documented).
The following code shows the timer resolution:
#include
#include
#include
#include
int main()
{
unsigned int prev = timeGetTime(), next;
Sleep(1);
next = timeGetTime();
printf("Sleep(1) = %u\n", next - prev);
return 0;
}
Output:
Sleep(1) = 10
means the default 100HZ
Sleep(1) = 1
means the increased resolution of 1ms
Anton Lavrentiev
Contractor NIH/NLM/NCBI
P.S. timeBeginPeriod():
This function affects a global Windows setting. Windows uses the lowest value
(that is, highest
resolution) requested by any process. Setting a higher resolution can improve
the accuracy of
time-out intervals in wait functions. However, it can also reduce overall
system performance,
because the thread scheduler switches tasks more often. High resolutions can
also prevent the
CPU power management system from entering power-saving modes.
no regular expressions in less
Hi list. I've just noticed that regexp search works identically to exact match search in less and it prints this: $ /usr/bin/less --version less 581.2 (no regular expressions) Copyright (C) 1984-2021 Mark Nudelman less comes with NO WARRANTY, to the extent permitted by law. For information about the terms of redistribution, see the file named README in the less distribution. Home page: https://greenwoodsoftware.com/less How to solve this? -- 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: Incorrect expansion of a program argument that is a special character?
On 2021-07-21 05:42, Ev Drikos via Cygwin wrote: When I run the program below from my home directory in a PowerShell Console (Windows 8-1) I've to use an extra backslash character as shown below or the star is expanded. Which happens only when the program has been compiled in Cygwin. Is this a bug or a known feature? It's a feature which emulates the argument expansions normally performed by shells under Unix like systems. If a Cygwin program is not run from a Cygwin shell, then the Cygwin program startup argument parsing obeys the quoting rules and performs the argument expansions which running from a Cygwin shell would normally perform, so the program sees the same arguments as running from a Cygwin shell would generate. Run "info bash 'pattern matching'" then press u (Up) and repeat to see other argument expansions and processing performed; tab and press Enter to view Topics; press q to Quit. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- 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
Fwd: Incorrect expansion of a program argument that is a special character?
-- Forwarded message -- From: Ev Drikos Date: Wed, 21 Jul 2021 17:17:50 +0300 Subject: Re: Incorrect expansion of a program argument that is a special character? To: Russell VT On 7/21/21, Russell VT wrote: > ... > Do you have an example of where the program functions as-expected, along > with examples as to how the identical binary functions differently in > other environments? > ... Hello, In example, the program runs as expected if any of the following situations: 1. I run it in another directory (ie C:\Users\suser\tmp) 2. I run it in a classic Windows terminal (but no Greek characters) 3. I've compiled the program with cl (MS VC++) It's the third test I made (compile with MS VC++) that made me wonder if I face some Cygwin bug. Clearly, it's a question, not a bug report. Thank you, Ev. Drikos -- 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: [ITP] Qemu
Am 20.07.21 um 15:11 schrieb Jon Turney: On 30/06/2021 14:35, Helge Konetzka wrote: Hello, I would like to package Qemu for Cygwin. See https://www.qemu.org/ Thanks for looking into this, and sorry for the delay in responding. Qemu is included in Debian. See https://packages.debian.org/source/buster/qemu Qemu is released under the GNU General Public License, version 2. Parts of Qemu have specific licenses, see file LICENSE. See https://qemu-project.gitlab.io/qemu/system/license.html I've prepared cygports for the packages as a POC. See https://gitlab.com/hejko-cygwin/cygports Qemu binaries and resources were packaged in mingw64-x86_64-qemu and mingw64-i686-qemu. To make Qemu accessible in a transparent way, I've created qemu-integration. It mainly consists of a wrapper and a setup script. See https://gitlab.com/hejko-cygwin/qemu-integration I assume that it's not straightforward to build cygwin executables of QEMU, but mentioning some of this issues would help. Given that: do we really need to build our own MinGW QEMU packages? Can the integration script just rely on the official Windows packages being installed? I've never tried to build Qemu using the Cygwin toolchain. It's not documented and IMHO it's not supported. qemu-integration can be configured to execute the official Qemu distribution easily. I've already provided a configuration example for this case. If you think this would be useful, I could create an updated version of qemu-integration which also defaults to the standard installation path of the "official" Qemu Windows package. For download of POC packages see https://www.zapateado.de/cygwin/ Any interest for Qemu packages in Cygwin? If so, I would split Qemu into several packages and add all licenses included in Qemu source before final upload.
Re: Incorrect expansion of a program argument that is a special character?
Note that Powershell and BASH wildcard (globbing) may be notably different,
which includes how items may be "escaped" to prevent such globbing
operations.
Moreover, in a UN*X shell, it is generally thought that it's the user's
responsibility to declare how how file expansion should work, generally
defaulting to the "one or more" presence (where true regular expressions
use an asterisk as "zero or more"). In this way, shells and general regular
expressions may differ.
TLDR; In any environment, "arguments" are different between the command
line, and the program itself.
Basically, you need to understand how any given shell will pass arguments
to your program, and that exercise is generally outside of general
executable-type discussion (ie. it is almost a "religious war" as to how
various shells may process arguments, regular expressions, or wildcards ...
along with what options a user may specify to change the behaviour)
Do you have an example of where the program functions as-expected, along
with examples as to how the identical binary functions differently in
other environments?
Hope that lights a few lightbulbs for ya!
Russell VT
On Wed, Jul 21, 2021 at 4:44 AM Ev Drikos via Cygwin
wrote:
> Hello,
>
> When I run the program below from my home directory in a PowerShell
> Console (Windows 8-1) I've to use an extra backslash character as
> shown below or the star is expanded. Which happens only when the
> program has been compiled in Cygwin.
>
> Is this a bug or a known feature?
>
> Ev. Drikos
>
> --
> PS C:\Users\suser> .\args.exe '\*'
>
> *
> argc=1
> PS C:\Users\suser>
> --
>
> #include
> int main(int argc, char *argv[]){
> int i;
> for (i=1; i < argc; i++) {
> printf("\n%s",argv[i]);
> }//for
> printf("\nargc=%d\n",argc-1);
> return 0;
> }
>
> --
> 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
>
--
Russell M. Van Tassell
--
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
Incorrect expansion of a program argument that is a special character?
Hello,
When I run the program below from my home directory in a PowerShell
Console (Windows 8-1) I've to use an extra backslash character as
shown below or the star is expanded. Which happens only when the
program has been compiled in Cygwin.
Is this a bug or a known feature?
Ev. Drikos
--
PS C:\Users\suser> .\args.exe '\*'
*
argc=1
PS C:\Users\suser>
--
#include
int main(int argc, char *argv[]){
int i;
for (i=1; i < argc; i++) {
printf("\n%s",argv[i]);
}//for
printf("\nargc=%d\n",argc-1);
return 0;
}
--
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: Fix nanosleep returning negative rem
On Jul 21 11:30, Corinna Vinschen wrote:
> I wrote a quick STC using the NT API calls and I can't reproduce the
> problem with this code either. The output is either
>
> SignalState: 1 TimeRemaining: -5354077459183
>
> or
>
> SignalState: 0 TimeRemaining: 653
>
> I never get a small negative value in the latter case. Can you
> reproduce your problem with this testcase or tweak it to reproduce it?
Now I actually attached the code :}
Corinna
#include
#include
#include
#include
typedef enum _TIMER_INFORMATION_CLASS {
TimerBasicInformation = 0
} TIMER_INFORMATION_CLASS, *PTIMER_INFORMATION_CLASS;
typedef struct _TIMER_BASIC_INFORMATION {
LARGE_INTEGER TimeRemaining;
BOOLEAN SignalState;
} TIMER_BASIC_INFORMATION, *PTIMER_BASIC_INFORMATION;
NTSTATUS NTAPI NtCreateTimer(PHANDLE, ACCESS_MASK, POBJECT_ATTRIBUTES,
TIMER_TYPE);
NTSTATUS NTAPI NtCancelTimer(HANDLE, PBOOLEAN);
NTSTATUS NTAPI NtSetTimer(HANDLE, PLARGE_INTEGER, PVOID, PVOID,
BOOLEAN, LONG, PBOOLEAN);
NTSTATUS NTAPI NtQueryTimer (HANDLE, TIMER_INFORMATION_CLASS, PVOID,
ULONG, PULONG);
int
main ()
{
HANDLE event;
HANDLE timer;
NTSTATUS status;
LARGE_INTEGER timeout;
TIMER_BASIC_INFORMATION tbi;
event = CreateEvent (NULL, TRUE, FALSE, NULL);
status = NtCreateTimer (, TIMER_ALL_ACCESS, NULL, NotificationTimer);
if (!NT_SUCCESS (status))
{
fprintf (stderr, "NtCreateTimer: 0x%08lx\n", status);
return 1;
}
timeout.QuadPart = -1000LL; /* 1 sec */
status = NtSetTimer (timer, , NULL, NULL, FALSE, 0, NULL);
if (!NT_SUCCESS (status))
{
fprintf (stderr, "NtSetTimer: 0x%08lx\n", status);
return 1;
}
WaitForSingleObject (event, 985L);
NtQueryTimer (timer, TimerBasicInformation, , sizeof tbi, NULL);
printf ("SignalState: %d TimeRemaining: %lld\n", tbi.SignalState,
tbi.TimeRemaining.QuadPart);
NtCancelTimer (timer, NULL);
NtClose (timer);
return 0;
}
Re: Fix nanosleep returning negative rem
On Jul 21 09:07, David Allsopp wrote: > > On Jul 20 16:16, David Allsopp wrote: > > > I've pushed a repro case for this to > > > https://github.com/dra27/cygwin-nanosleep-bug.git > > > > > > Originally noticed as the main CI system for OCaml has been failing > > > sporadically for the signal.ml test mentioned in that repo. This > > > morning I tried hammering that test on my dev machine and discovered > > > that it fails very frequently. No idea if that's drivers, Windows 10 > > > updates, number of cores or what, but it was definitely happening, and > > > easily. > > > > > > Drilling further, it appears that NtQueryTimer is able to return a > > > negative value in the TimeRemaining field even when SignalState is > > > false. The values I've seen have always been < 15ms - i.e. less than > > > the timer resolution, so I wonder if there is a point at which the > > > timer has elapsed but has not been signalled, but WaitForMultipleObjects > > returns because of the EINTR signal. > > > Mildly surprising that it seems to be so reproducible. > > > > > > Anyway, a patch is attached which simply guards a negative return > > > value. The test on tbi.SignalState is in theory unnecessary. > > > > Thanks for the patch, I think your patch is fine. However, I'd like to > > dig a bit into this to see what exactly happens. Do you have a very > > simple testcase in plain C, by any chance? > > https://github.com/dra27/cygwin-nanosleep-bug/blob/main/signal.c was > as simple as I'd gone at this stage (eliminating OCaml from the > equation!). It might be possible to get it to happen without all the > pthreads stuff: having confirmed it definitely wasn't OCaml and been > able to put the appropriate system_printf's into cygwait to see that > NtQueryTimer really was returning this small negative value, I stopped > simplifying. > > Does that repro case trigger on your system too? I'm not sure. Would the output " - nanosleep failed: ..." indicate the bug has been triggered? If so, no, I can't reproduce this on my system. I wrote a quick STC using the NT API calls and I can't reproduce the problem with this code either. The output is either SignalState: 1 TimeRemaining: -5354077459183 or SignalState: 0 TimeRemaining: 653 I never get a small negative value in the latter case. Can you reproduce your problem with this testcase or tweak it to reproduce it? Either way, your patch as safe guard should be ok. Thanks, Corinna
RE: Fix nanosleep returning negative rem
> On Jul 20 16:16, David Allsopp wrote: > > I've pushed a repro case for this to > > https://github.com/dra27/cygwin-nanosleep-bug.git > > > > Originally noticed as the main CI system for OCaml has been failing > > sporadically for the signal.ml test mentioned in that repo. This > > morning I tried hammering that test on my dev machine and discovered > > that it fails very frequently. No idea if that's drivers, Windows 10 > > updates, number of cores or what, but it was definitely happening, and > > easily. > > > > Drilling further, it appears that NtQueryTimer is able to return a > > negative value in the TimeRemaining field even when SignalState is > > false. The values I've seen have always been < 15ms - i.e. less than > > the timer resolution, so I wonder if there is a point at which the > > timer has elapsed but has not been signalled, but WaitForMultipleObjects > returns because of the EINTR signal. > > Mildly surprising that it seems to be so reproducible. > > > > Anyway, a patch is attached which simply guards a negative return > > value. The test on tbi.SignalState is in theory unnecessary. > > Thanks for the patch, I think your patch is fine. However, I'd like to > dig a bit into this to see what exactly happens. Do you have a very > simple testcase in plain C, by any chance? https://github.com/dra27/cygwin-nanosleep-bug/blob/main/signal.c was as simple as I'd gone at this stage (eliminating OCaml from the equation!). It might be possible to get it to happen without all the pthreads stuff: having confirmed it definitely wasn't OCaml and been able to put the appropriate system_printf's into cygwait to see that NtQueryTimer really was returning this small negative value, I stopped simplifying. Does that repro case trigger on your system too? Best, D
Re: Fix nanosleep returning negative rem
Hi David, On Jul 20 16:16, David Allsopp wrote: > I've pushed a repro case for this to > https://github.com/dra27/cygwin-nanosleep-bug.git > > Originally noticed as the main CI system for OCaml has been failing > sporadically for the signal.ml test mentioned in that repo. This morning I > tried hammering that test on my dev machine and discovered that it fails > very frequently. No idea if that's drivers, Windows 10 updates, number of > cores or what, but it was definitely happening, and easily. > > Drilling further, it appears that NtQueryTimer is able to return a negative > value in the TimeRemaining field even when SignalState is false. The values > I've seen have always been < 15ms - i.e. less than the timer resolution, so > I wonder if there is a point at which the timer has elapsed but has not been > signalled, but WaitForMultipleObjects returns because of the EINTR signal. > Mildly surprising that it seems to be so reproducible. > > Anyway, a patch is attached which simply guards a negative return value. The > test on tbi.SignalState is in theory unnecessary. Thanks for the patch, I think your patch is fine. However, I'd like to dig a bit into this to see what exactly happens. Do you have a very simple testcase in plain C, by any chance? Thanks, Corinna
Re: Debugging PHP with GDB and php-debuginfo
Greetings, Jim Hyslop! > I've installed the php-debuginfo extension for gdb, but I can't figure > out how to set a breakpoint with it. Is there a manual for > php-debuginfo? All I can find is the package information. > I'm trying to debug why a unit test is passing (it should fail). I'm > using the CakePHP framework (www.cakephp.org). From the command line, I > normally just execute `vendor/bin/phpunit`. You're confusing debugging PHP code (i.e. website) with debudding PHP itself. php-debuginfo is for the latter. > With gdb, I execute `gdb $(which php)`, then at the command line in GDB > I type ` b ./tests/TestCase/Controller/UsersControllerTest.php:80` > GDB responds with: > No source file named > ./tests/TestCase/Controller/UsersControllerTest.php. > Make breakpoint pending on future shared library load? (y or [n]) Entirely predictable. PHP is written in C, not PHP. > The file name is valid. I've tried using the full path instead of the > relative path. > When I run the tests with `r vendor/bin/phpunit` the unit tests all > execute, but GDB doesn't stop at the breakpoint. > Do I need to modify php.ini to use gdb? Any pointers? You need to install xdebug. And for that, you need to install native PHP, as there's no PECL modules built for Cygwin. Then use any suitable IDE (VS Code, PHPStorm, etc.) to step through the code. Read phpunit instructions about allowing it running under debugger. -- With best regards, Andrey Repin Wednesday, July 21, 2021 11:03:04 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH 0/3] Add more winsymlinks values
On Jul 19 17:31, Jon Turney wrote: > I'm not sure this is the best idea, since it adds more configurations that > aren't going to get tested often, but the idea is that this would enable > proper and consistent control of the symlink type used from setup, as > discussed in [1]. > > [1] https://cygwin.com/pipermail/cygwin-apps/2021-May/041327.html Why isn't it sufficient to use 'winsymlinks:native' from setup? The way we express symlinks shouldn't be a user choice, really. The winsymlinks thingy was only ever introduced in a desperate attempt to improve access to symlinks from native tools, and I still don't see a way around that. But either way, what's the advantage in allowing the user complete control over the type, even if the type is only useful in Cygwin? Corinna
Re: [PATCH] Cygwin: fix format warnings in profiler.cc
On Jul 21 01:00, Mark Geisert wrote: > Use new typedef to normalize pids for printing on both 32- and 64-bit Cygwin. I pushed my patch before I saw yours. If you want to use ulong, please send a followup patch which introduces the typedef. Thanks, Corinna
Re: [PATCH 1/3] Cygwin: New tool: profiler
On Jul 19 16:43, Jon Turney wrote: > On 19/07/2021 15:23, Jon Turney wrote: > > On 19/07/2021 11:04, Corinna Vinschen wrote: > > > Hi Matt, > > > > > > On Jul 15 21:49, Mark Geisert wrote: > > > > The new tool formerly known as cygmon is renamed to 'profiler'. For the > > > > name I considered 'ipsampler' and could not think of any > > > > others. I'm open > > > > to a different name if any is suggested. > > > > > > > > I decided that a discussion of the pros and cons of this profiler vs the > > > > existing ssp should probably be in the "Profiling Cygwin > > > > Programs" section > > > > of the Cygwin User's Guide rather than in the help for either. That > > > > material will be supplied at some point. > > > > > > > > CONTEXT buffers are made child-specific and thus thread-specific since > > > > there is one profiler thread for each child program being profiled. > > > > > > > > The SetThreadPriority() warning comment has been expanded. > > > > > > > > chmod() works on Cygwin so the "//XXX ineffective" comment is gone. > > > > > > > > I decided to make the "sample all executable sections" and "sample > > > > dynamically generated code" suggestions simply expanded comments > > > > for now. > > > > > > > > The profiler program is now a Cygwin exe rather than a native exe. > > > > > > The patchset LGTM, but for the details I'd like jturney to have a look > > > and approve it eventually. > > > > Thanks. I applied these patches. > > > > A few small issues you might consider addressing in follow-ups. > > It also seems there are some format warnings on x86, see > > https://ci.appveyor.com/project/cygwin/cygwin/builds/40046785/job/fie6x4ta11v5nrjo Given that we build with -Werror, these warnings are fatal. I pushed a patch to fix this. Corinna
[PATCH] Cygwin: fix format warnings in profiler.cc
Use new typedef to normalize pids for printing on both 32- and 64-bit Cygwin.
---
winsup/utils/profiler.cc | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/winsup/utils/profiler.cc b/winsup/utils/profiler.cc
index d1a01c3a2..152bf1cca 100644
--- a/winsup/utils/profiler.cc
+++ b/winsup/utils/profiler.cc
@@ -29,6 +29,7 @@
#include "cygwin/version.h"
#include "cygtls_padsize.h"
#include "gcc_seh.h"
+typedef unsigned long ulong;
typedef unsigned short ushort;
typedef uint16_t u_int16_t; // Non-standard sized type needed by ancient gmon.h
#define NO_GLOBALS_H
@@ -312,10 +313,10 @@ dump_profile_data (child *c)
if (s->name)
{
WCHAR *name = 1 + wcsrchr (s->name, L'\\');
- sprintf (filename, "%s.%u.%ls", prefix, c->pid, name);
+ sprintf (filename, "%s.%lu.%ls", prefix, (ulong) c->pid, name);
}
else
-sprintf (filename, "%s.%u", prefix, c->pid);
+sprintf (filename, "%s.%lu", prefix, (ulong) c->pid);
fd = open (filename, O_CREAT | O_TRUNC | O_WRONLY | O_BINARY);
if (fd < 0)
@@ -804,9 +805,9 @@ cygwin_pid (DWORD winpid)
cygpid = (DWORD) cygwin_internal (CW_WINPID_TO_CYGWIN_PID, winpid);
if (cygpid >= max_cygpid)
-snprintf (buf, sizeof buf, "%u", winpid);
+snprintf (buf, sizeof buf, "%lu", (ulong) winpid);
else
-snprintf (buf, sizeof buf, "%u (pid: %u)", winpid, cygpid);
+snprintf (buf, sizeof buf, "%lu (pid: %lu)", (ulong) winpid, (ulong)
cygpid);
return buf;
}
--
2.32.0
