Re: Question about HEG warning
On 2018-11-30 04:41, Zixiong Zhang wrote: Dear Sir/Madam, I am trying to use HEG for MODIS data. However, After I installing the HEG, it threw the warning of "WARNING: Couldn't compute FAST_CWD pointer." And I don't know how to deal with it. Hi Zixiong, Your software is using an old version of cygwin1.dll, meaning HEG is using an old version of a library (DLL), called cygwin1.dll You can read about it here: https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings Tell the provider of HEG they should update the library, and provide you with an updated version of the software. Henri Could you please give me some help? Thank you for your time. Best regards, Zixiong -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Question about HEG warning
Dear Sir/Madam, I am trying to use HEG for MODIS data. However, After I installing the HEG, it threw the warning of "WARNING: Couldn't compute FAST_CWD pointer." And I don't know how to deal with it. Could you please give me some help? Thank you for your time. Best regards, Zixiong -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: MinTTY requires gdiplus.dll ? (2)
On 2018-11-29 23:11, Thomas Wolff wrote: On Nov 29 19:41, Houder wrote: [snip] Placing strace in front of this call, results in: 64-@@ strace /usr/bin/mintty --- Process 3112 created --- Process 3112 loaded C:\Windows\System32\ntdll.dll at 777b ... --- Process 3112 loaded C:\Windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757\comc tl32.dll at 07fefb9c --- Process 3112 loaded C:\Windows\System32\gdi32.dll at 07fefdc1 ... --- Process 3112 loaded C:\Windows\winsxs\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_145e10148b8de48e\GdiPlus.dll at 07fefb44 ... --- Process 3112, exception c005 at 000180044bb3 --- Process 3112 exited with status 0xc005 Segmentation fault There's also another dll reported from winsxs rather than System32 in your log. Maybe some files got corrupted on your system? Right. copied this one: c:/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_145e10148b8de48e/GdiPlus.dll ( 2177536 Oct 6 17:58 ) to c:/Windows/system32, on the 64-bits instance of Cygwin, and copied this one: c:/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_5c0b46eba00a0d94/GdiPlus.dll ( 1633280 Oct 6 17:43 ) to c:/Windows/system32, on the 32-bits instance of Cygwin. (and No, normally I do not do these kinds of things. I think Windows should take care of itself -- it does not) Now, "cygcheck mintty" (both on 64-bits and 32-bits) is "happy": all DLL's can be found ... Good Heavens. Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: MinTTY requires gdiplus.dll ? (2)
On 2018-11-29 23:11, Thomas Wolff wrote: On Nov 29 19:41, Houder wrote: [snip] Placing strace in front of this call, results in: 64-@@ strace /usr/bin/mintty --- Process 3112 created --- Process 3112 loaded C:\Windows\System32\ntdll.dll at 777b ... --- Process 3112 loaded C:\Windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757\comc tl32.dll at 07fefb9c --- Process 3112 loaded C:\Windows\System32\gdi32.dll at 07fefdc1 ... --- Process 3112 loaded C:\Windows\winsxs\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_145e10148b8de48e\GdiPlus.dll at 07fefb44 ... --- Process 3112, exception c005 at 000180044bb3 --- Process 3112 exited with status 0xc005 Segmentation fault There's also another dll reported from winsxs rather than System32 in your log. Maybe some files got corrupted on your system? Files corrupted on Windows? Very likely. That is why I stay as much as is possible way from my C:\ drive (in any form or manner) ... And you are right (GdiPlus.dll) ... I missed that. Now that I know how the name must be spelled: 64-@@# find /drv/c/Windows -type f -name GdiPlus.dll /drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.17514_none_3bd2e487d8e769d3/GdiPlus.dll /drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.17514_none_2b24536c71ed437a/GdiPlus.dll /drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.17514_none_83801b5eed6392d9/GdiPlus.dll /drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.17514_none_72d18a4386696c80/GdiPlus.dll /drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.18946_none_8382f002ed61108b/GdiPlus.dll /drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.24234_none_2507449df28cf2b8/GdiPlus.dll /drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.23407_none_2503fd39f28ff711/GdiPlus.dll /drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.18946_none_3bd5b92bd8e4e785/GdiPlus.dll /drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.23149_none_5c0676f9a00e9169/GdiPlus.dll /drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.24280_none_6cb9d807070433ed/GdiPlus.dll /drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.18946_none_2b27281071eac12c/GdiPlus.dll /drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.24280_none_250ca12ff2880ae7/GdiPlus.dll /drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.23149_none_2507d13df28c8ebc/GdiPlus.dll /drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_5c0b46eba00a0d94/GdiPlus.dll /drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.23407_none_14556c1e8b95d0b8/GdiPlus.dll /drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.23407_none_6cb13411070c2017/GdiPlus.dll /drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.23149_none_6cb508150708b7c2/GdiPlus.dll /drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.18946_none_72d45ee78666ea32/GdiPlus.dll /drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.23407_none_5c02a2f5a011f9be/GdiPlus.dll /drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.23149_none_145940228b926863/GdiPlus.dll /drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24234_none_5c05ea59a00ef565/GdiPlus.dll /drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24234_none_1458b3828b92cc5f/GdiPlus.dll /drv/c/Windows/winsxs/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_145e10148b8de48e/GdiPlus.dll /drv/c/Windows/winsxs/x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.0.7601.24234_none_6cb47b7507091bbe/GdiPlus.dll Lot of them! Now I have to find out ... how to select the proper one and put it back in its proper place. ... and I do not even want to know why it got lost :-( Regards, Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early
On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen wrote: > > On Nov 26 17:46, Corinna Vinschen wrote: > > On Nov 26 10:47, James E. King III wrote: > > > On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen > > > wrote: > > > > > > > > On Nov 25 09:01, James E. King III wrote: > > > > > I have isolated a problem in pthread_cond_timedwait when the condattr > > > > > is used to set the clock type to CLOCK_MONOTONIC. In this case even > > > > > though a target time point in the future is specified, the call > > > > > returns ETIMEDOUT but a subsequent call to > > > > > clock_gettime(CLOCK_MONOTONIC) shows the desired time point was not > > > > > reached. > > > > > > > > > > $ gcc timed_wait_short.c -o timed_wait_short > > > > > $ ./timed_wait_short.exe > > > > > [...] > > > > > begin: 521056s 671907500n > > > > > target: 521056s 721907500n > > > > >end: 521056s 721578000n > > > > > ok: false > > > > > > > > > > I have attached the source code. > > > > > > > > Thanks for the testcase. The problem is this: > > > > [...] > > > > At the moment I only have an *ugly* idea: We can always add the > > > > coarsest resolution of the wait functions (typically 15.625 ms) to the > > > > relative timeout value computed from the absolute timeout given to > > > > pthread_cond_timedwait. In my testing this is sufficient since the > > > > difference between target and actual end time is always < 15ms, in > > > > thousands of runs. > > > > > > > > Thoughts? > > > > > > > > > > > > Thanks, > > > > Corinna > > > > > > > > (*) > > > > https://docs.microsoft.com/en-us/windows/desktop/Sync/wait-functions#wait-functions-and-time-out-intervals > > > > > > > > -- > > > > Corinna Vinschen > > > > Cygwin Maintainer > > > > > > Some thoughts: > > > > > > https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/thread.cc;h=0bddaf345d255ae39187458dc6d02b1b4c8087c1;hb=HEAD#l2546 > > > > > > In pthread_convert_abstime, line 2564, care is taken to adjust for > > > rounding errors. > > > At line 2574, the rounding is not accounted for when adjusting for a > > > relative wait because it is a monotonic clock. > > > Wouldn't that rounding error cause it to wait less time? > > > > Au contraire: > > > > - The end time you're waiting for is rounded *up*. > > - The current time is rounded *down* > > - So end time - current time is always bigger than required > > on the 100ns level. > > > > Make sense? > > I created a patch and uploaded new developer snapshots to > https://cygwin.com/snapshots/ Please give them a try. > > > Thanks, > Corinna > This fixed the issue for me. What's the best way to detect cygwin with this support? I see something around "has_precise_interrupt_time". I suppose that would be it? I need to make some changes in Boost.Thread to accomodate it. Thanks, Jim -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: MinTTY requires gdiplus.dll ?
On 2018-11-29 20:53, Michael Wild wrote: On Thu, 29 Nov 2018, 19:14 Houder wrote: [snip] Apparently MinTTY requires this DLL. Q: Should my system (Windows 7) have this DLL? (Is it present on your system?) [snip] Hi GDI+ is a graphics and font rendering engine that has been part of Windows since XP. No surprise there. Michael Michael, Let us start at the beginning ... What is the location of the gdiplus.dll on your system? Do you have Windows 7? I cannot find gdiplus.dll on my system. Yes, I do not know what it is used for ... but that is irrelevant. (if Thomas Wolff thinks I should have it, that is fine with me :-) I invoked: sfc /scannow from a "Dos box", and it basically reported "All is fine!". So if gdiplus.dll is supposed to be present on Windows 7, it is, from _my_ point of view, an useless tool. That why I asked: is it present on your system ? Regards, Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: MinTTY requires gdiplus.dll ? (2)
Am 29.11.2018 um 20:58 schrieb Corinna Vinschen: On Nov 29 19:41, Houder wrote: Hi, As I wrote in the preceding post ... Using Corinna's latest snapshot in a "Dos box" results in a prompt from bash. Once in bash, I can launch MinTTY ( 64-@@ /usr/bin/mintty ) Placing strace in front of this call, results in: 64-@@ strace /usr/bin/mintty --- Process 3112 created --- Process 3112 loaded C:\Windows\System32\ntdll.dll at 777b ... --- Process 3112 loaded C:\Windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757\comc tl32.dll at 07fefb9c --- Process 3112 loaded C:\Windows\System32\gdi32.dll at 07fefdc1 ... --- Process 3112 loaded C:\Windows\winsxs\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_145e10148b8de48e\GdiPlus.dll at 07fefb44 ... --- Process 3112, exception c005 at 000180044bb3 --- Process 3112 exited with status 0xc005 Segmentation fault There's also another dll reported from winsxs rather than System32 in your log. Maybe some files got corrupted on your system? I can reproduce this but while it's clear *where* it happens, it's unclear *when* and *why* it happens. Unclear to me what exactly can be reproduced. With today's snapshot cygwin1.dll, I can start mintty any way, also from Explorer, via shortcut, or directly from cmd.exe (skipping cygwin shell). Thomas It only occurs if mintty is the first process in a process tree. I.e., when starting mintty from a shell running in a DOS window, the problem disappears. Worse, the problem also disappears when running mintty under gdb. Corinna -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: MinTTY requires gdiplus.dll ? (2)
On Nov 29 19:41, Houder wrote: > Hi, > > As I wrote in the preceding post ... > > Using Corinna's latest snapshot in a "Dos box" results in a > prompt from bash. > > Once in bash, I can launch MinTTY ( 64-@@ /usr/bin/mintty ) > > Placing strace in front of this call, results in: > > 64-@@ strace /usr/bin/mintty > --- Process 3112 created > --- Process 3112 loaded C:\Windows\System32\ntdll.dll at 777b > --- Process 3112 loaded C:\Windows\System32\kernel32.dll at 7769 > --- Process 3112 loaded C:\Windows\System32\KernelBase.dll at > 07fefd49 > --- Process 3112 loaded E:\Cygwin64\bin\cygwin1.dll at 00018004 > --- Process 3112 loaded C:\Windows\System32\advapi32.dll at 07fefd75 > --- Process 3112 loaded C:\Windows\System32\msvcrt.dll at 07feff0a > --- Process 3112 loaded C:\Windows\System32\sechost.dll at 07feff91 > --- Process 3112 loaded C:\Windows\System32\rpcrt4.dll at 07feff63 > --- Process 3112 loaded > C:\Windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757\comc > tl32.dll at 07fefb9c > --- Process 3112 loaded C:\Windows\System32\gdi32.dll at 07fefdc1 > --- Process 3112 loaded C:\Windows\System32\user32.dll at 7759 > --- Process 3112 loaded C:\Windows\System32\lpk.dll at 07feff3a > --- Process 3112 loaded C:\Windows\System32\usp10.dll at 07feff9d > --- Process 3112 loaded C:\Windows\System32\shlwapi.dll at 07feff14 > --- Process 3112 loaded C:\Windows\System32\comdlg32.dll at 07fefefa > --- Process 3112 loaded C:\Windows\System32\shell32.dll at 07fefe13 > --- Process 3112 loaded > C:\Windows\winsxs\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_145e10148b8de48e\GdiPlus.dll > at 07fefb44 > --- Process 3112 loaded C:\Windows\System32\ole32.dll at 07feff3b > --- Process 3112 loaded C:\Windows\System32\imm32.dll at 07fefd72 > --- Process 3112 loaded C:\Windows\System32\msctf.dll at 07fefdb0 > --- Process 3112 loaded C:\Windows\System32\winmm.dll at 07fefa04 > --- Process 3112 loaded C:\Windows\System32\winspool.drv at 07fef9f1 > --- Process 3112, exception c005 at 000180044bb3 > --- Process 3112 exited with status 0xc005 > Segmentation fault I can reproduce this but while it's clear *where* it happens, it's unclear *when* and *why* it happens. It only occurs if mintty is the first process in a process tree. I.e., when starting mintty from a shell running in a DOS window, the problem disappears. Worse, the problem also disappears when running mintty under gdb. Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: MinTTY requires gdiplus.dll ?
On Thu, 29 Nov 2018, 19:14 Houder wrote: > Hi, > > Because I have a problem w/ Corinna's latest snapshot (using > MinTTY!), I executed (among others): > > 64-@@ cygcheck mintty > ... >C:\Windows\system32\WINSPOOL.DRV > cygcheck: track_down: could not find gdiplus.dll > > None of the individual DLL's from "cygcheck mintty" requires > the gdiplus.dll ... > > Apparently MinTTY requires this DLL. > > Q: Should my system (Windows 7) have this DLL? (Is it present > on your system?) > > Regards, > > Henri > > - > Using Corinna's latest snapshot in a "Dos box" results in a > prompt from bash > > However launching MinTTY fails (hangs) (on my system) > Hi GDI+ is a graphics and font rendering engine that has been part of Windows since XP. No surprise there. Michael > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
MinTTY requires gdiplus.dll ? (2)
Hi, As I wrote in the preceding post ... Using Corinna's latest snapshot in a "Dos box" results in a prompt from bash. Once in bash, I can launch MinTTY ( 64-@@ /usr/bin/mintty ) Placing strace in front of this call, results in: 64-@@ strace /usr/bin/mintty --- Process 3112 created --- Process 3112 loaded C:\Windows\System32\ntdll.dll at 777b --- Process 3112 loaded C:\Windows\System32\kernel32.dll at 7769 --- Process 3112 loaded C:\Windows\System32\KernelBase.dll at 07fefd49 --- Process 3112 loaded E:\Cygwin64\bin\cygwin1.dll at 00018004 --- Process 3112 loaded C:\Windows\System32\advapi32.dll at 07fefd75 --- Process 3112 loaded C:\Windows\System32\msvcrt.dll at 07feff0a --- Process 3112 loaded C:\Windows\System32\sechost.dll at 07feff91 --- Process 3112 loaded C:\Windows\System32\rpcrt4.dll at 07feff63 --- Process 3112 loaded C:\Windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757\comc tl32.dll at 07fefb9c --- Process 3112 loaded C:\Windows\System32\gdi32.dll at 07fefdc1 --- Process 3112 loaded C:\Windows\System32\user32.dll at 7759 --- Process 3112 loaded C:\Windows\System32\lpk.dll at 07feff3a --- Process 3112 loaded C:\Windows\System32\usp10.dll at 07feff9d --- Process 3112 loaded C:\Windows\System32\shlwapi.dll at 07feff14 --- Process 3112 loaded C:\Windows\System32\comdlg32.dll at 07fefefa --- Process 3112 loaded C:\Windows\System32\shell32.dll at 07fefe13 --- Process 3112 loaded C:\Windows\winsxs\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.24280_none_145e10148b8de48e\GdiPlus.dll at 07fefb44 --- Process 3112 loaded C:\Windows\System32\ole32.dll at 07feff3b --- Process 3112 loaded C:\Windows\System32\imm32.dll at 07fefd72 --- Process 3112 loaded C:\Windows\System32\msctf.dll at 07fefdb0 --- Process 3112 loaded C:\Windows\System32\winmm.dll at 07fefa04 --- Process 3112 loaded C:\Windows\System32\winspool.drv at 07fef9f1 --- Process 3112, exception c005 at 000180044bb3 --- Process 3112 exited with status 0xc005 Segmentation fault 64-@@ uname -a CYGWIN_NT-6.1 Seven 2.12.0(0.330/5/3) x86_64 Cygwin 64-@@ For the expert among us ... = -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
MinTTY requires gdiplus.dll ?
Hi, Because I have a problem w/ Corinna's latest snapshot (using MinTTY!), I executed (among others): 64-@@ cygcheck mintty ... C:\Windows\system32\WINSPOOL.DRV cygcheck: track_down: could not find gdiplus.dll None of the individual DLL's from "cygcheck mintty" requires the gdiplus.dll ... Apparently MinTTY requires this DLL. Q: Should my system (Windows 7) have this DLL? (Is it present on your system?) Regards, Henri - Using Corinna's latest snapshot in a "Dos box" results in a prompt from bash However launching MinTTY fails (hangs) (on my system) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 32 bit vs 64 bit Cygwin, followup
On Nov 29 10:18, Sam Habiel wrote:
> On Thu, Nov 29, 2018 at 3:58 AM Corinna Vinschen wrote:
> > On Nov 28 11:06, Sam Habiel wrote:
> > > On Wed, Nov 28, 2018 at 11:01 AM Yaakov Selkowitz wrote:
> > > > On Mon, 2018-11-26 at 14:07 -0500, Sam Habiel wrote:
> > > > > [...]
> > > > > GT.M contains a large
> > > > > amount of assembly code, written to run on the x32 Linux ABI and the
> > > > > AMD x64 ABI. It's was very easy to get the x32 Linux ABI to run on
> > > > > Cygwin x32; Cygwin x64 on the other hand uses the Windows x64 ABI,
> > > > > which is very different than the AMD ABI (more detail here:
> > > > > https://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64/).
> > > > > I don't have the expertise nor the time to rewrite a lot of assembly
> > > > > code to use the Windows x64 ABI. There are about 100 source code files
> > > > > that are in assembly.
> > > >
> > > > -mabi=sysv ?
> > > >
> > > Are you telling me that gcc has a flag to support AMD ABI on Cygwin
> > > x64? The assembly code is not standalone; it gets called from C code
> > > and calls C code.
> >
> > That's what he's telling you. However, you have to interact with the MS
> > ABI(*) as well as soon as you call external library functions so it
> > makes sense to keep your C code in MS ABI. For the assembler functions,
> > you can just tell the compiler they are in SYSV ABI by adding a function
> > attribute to the declaration:
> >
> > int asm_func (args) __attribute__ ((sysv_abi))
> >
> > Good luck,
> > Corinna
> >
> > (*) Just keep in mind that Cygwin is LP64, not LLP64:
> > https://cygwin.com/faq/faq.html#faq.programming.64bitporting
> > [...]
> [...]
> This sounds very promising, but I would like a clarification; because
> I think you covered 50% of the issue:
>
> 1. There are frequent calls from the C code to Assembly.
> 2. There are also frequent calls from Assembly to C code.
>
> Looks like compiling the .s files with the -mabi=sysv flag and
> declaring the function in C with the __attribute__ ((sysv_abi)) will
> fix #1.
You shouldn't have to use the flag when building the assembler files,
they are using SYSV ABI anyway. In fact, while Yaakov is right,
basically, I think in your scenario you should only use the GCC function
attribute since that allows more fine-grained control. Just stick to MS
ABI by default and only perform the SYSV ABI juggle where required to
interact with the assembler code.
> How about #2? I don't see an easy solution. The assembly code puts
> together the parameters in the registers in the sysv way (rdi, rsi,
> rdx, rcx, r8, r9), not rcx, rdx, r8, and r9.
One way is to create a SYSV wrapper for each C function called from
assembler. Assuming this simple scenario:
There's a C function foo(), which is called from assembler as
well as from other C functions.
extern long foo (long, double, int, long);
For the "normal" (i.e. MS ABI) C code add this in front of the above
declaration:
#define foo(a,b,c,d)__foo((a),(b),(c),(d))
So the C function is renamed to __foo and C code will call __foo.
Add a wrapper C file to add a function foo with SYSV ABI, calling
__foo:
#undef foo
long __attribute__ ((sysv_abi))
foo (long a, double b, int c, long d)
{
return __foo (a,b,c,d);
}
That should do it. Of course there may be more complicated cases,
but I leave them as excercise for the reader, and only you are in
a position to know them ;)
HTH,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
Re: 32 bit vs 64 bit Cygwin, followup
On Thu, Nov 29, 2018 at 3:58 AM Corinna Vinschen wrote: > > Please, no top-posting. > > On Nov 28 11:06, Sam Habiel wrote: > > Yaakov, > > > > On Wed, Nov 28, 2018 at 11:01 AM Yaakov Selkowitz > > wrote: > > > > > > On Mon, 2018-11-26 at 14:07 -0500, Sam Habiel wrote: > > > > Hello everybody, > > > > > > > > In this message > > > > (https://www.sourceware.org/ml/cygwin/2018-11/msg00190.html), Corinna > > > > (Hi Corinna!) says: > > > > > > > > "Don't do that. Use 64 bit Cygwin whenever possible. 32 bit is a lost > > > > cause." > > > > > > > > I would like to mention why I am still using 32 bit Cygwin. > > > > > > > > I maintain a port of a database called GT.M > > > > (https://en.wikipedia.org/wiki/GT.M) on Cygwin. I work with Electronic > > > > Medical Records that run on this database. GT.M contains a large > > > > amount of assembly code, written to run on the x32 Linux ABI and the > > > > AMD x64 ABI. It's was very easy to get the x32 Linux ABI to run on > > > > Cygwin x32; Cygwin x64 on the other hand uses the Windows x64 ABI, > > > > which is very different than the AMD ABI (more detail here: > > > > https://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64/). > > > > I don't have the expertise nor the time to rewrite a lot of assembly > > > > code to use the Windows x64 ABI. There are about 100 source code files > > > > that are in assembly. > > > > > > -mabi=sysv ? > > > > > Are you telling me that gcc has a flag to support AMD ABI on Cygwin > > x64? The assembly code is not standalone; it gets called from C code > > and calls C code. > > That's what he's telling you. However, you have to interact with the MS > ABI(*) as well as soon as you call external library functions so it > makes sense to keep your C code in MS ABI. For the assembler functions, > you can just tell the compiler they are in SYSV ABI by adding a function > attribute to the declaration: > > int asm_func (args) __attribute__ ((sysv_abi)) > > Good luck, > Corinna > > (*) Just keep in mind that Cygwin is LP64, not LLP64: > https://cygwin.com/faq/faq.html#faq.programming.64bitporting > > -- > Corinna Vinschen > Cygwin Maintainer I use Gmail. Woe is me. And I stick with the defaults. A bit hard to not top post due to my typical habits. Sorry! Thank you for your reply Corinna. This sounds very promising, but I would like a clarification; because I think you covered 50% of the issue: 1. There are frequent calls from the C code to Assembly. 2. There are also frequent calls from Assembly to C code. Looks like compiling the .s files with the -mabi=sysv flag and declaring the function in C with the __attribute__ ((sysv_abi)) will fix #1. How about #2? I don't see an easy solution. The assembly code puts together the parameters in the registers in the sysv way (rdi, rsi, rdx, rcx, r8, r9), not rcx, rdx, r8, and r9. Here's an example call: https://github.com/shabiel/fis-gtm/blob/master/sr_x86_64/opp_tstart.s; all the other asm code is in the same folder. --Sam -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
latest lighttpd (1.4.45) not working on Windows 10 Home Edition
Hi, Id like to share that the latest Cygwin lighttpd package does not work for me on Windows 10 Home Edition. Neither 32-bit nor 64-bit package. I had the chance to test it on both architectures because when I first ran into this problem I was running Windows 10 32-bit on this AMD64 PC, but later on I did a fresh install of Windows 10 64-bit; the reason for the architecture mismatch was that PC vendor sold AMD64 PCs with Windows 7 Starter Edition (which was 32-bit only IIRC). Back to lighttpd: the previous version (1.4.41) does run OK with the same config files. I suspected the newer lighttpd might have been somehow incompatible with v 1.4.41 config files, but I have another machine with Windows 7 64-bit and v 1.4.45 does run OK with similar config files. The error is non verbose: when I try to load any web page (static or PHP) the browser just remains *loading* for a long time and later ends with a timeout error page, whereas the previous lighttpd binary just loads the page fast. There are no logs written in access.log error.log or cygrunsrv.log files. I'm not sure, but I'd guess it's a compatibility issue with Windows 10. I have mod_access, mod_redirect, mod_rewrite, mod_magnet, mod_proxy, mod_fastcgi (for PHP integration) enabled. I tried accessing it at every ip (127.0.0.1, lan ip and internet ip) where the previous version succeeds, to no avail. The lighttpd (1.4.45) service also takes too long to stop and sometimes it just fails to do so. I use latest PHP packages for both v 1.4.41 and v 1.4.45 tests. I run Windows 10 April 2018 Update or Windows 10 version 1803. Thanks in advance, -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Not able to open Cygwin
Am 29.11.2018 um 10:33 schrieb Manjunatha Kembodi -X (makv - TERRALOGIC SOLUTIONS INC at Cisco): Hi Team, We are not able to open cygwin in one of the machine. You need to make some effort in explain how you are doing the things, if you want to enable us to help you. Please note that by default all the replies of the cygwin mailing list go only to the mailing list, so some of you should subscribe to it for following the replies. getting below ERROR. what might be the issue here? c:\cygwin\usr\sbin>inetd.exe -d /etc/inetd.conf 1 [main] inetd 2500 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com" This warning says that you are using a very very old version of cygwin. https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings Any chance to upgrade to recent one ? Thanks, Manjunath? Regards Marco --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: _GNU_SOURCE doesn't enable cuserid() declaration
On Nov 29 13:22, Tony Cook wrote:
> Linux stdio.h exposes the declaration of cuserid() both with standard
> version macros and with _GNU_SOURCE:
>
> tony@mars:~/play$ cat testcuserid.c
> #define _GNU_SOURCE
> #include
>
> int main() {
> puts(cuserid(NULL));
> return 0;
> }
> tony@mars:~/play$ gcc -otestcuserid -Werror=all testcuserid.c
> tony@mars:~/play$ ./testcuserid
> tony
> tony@mars:~/play$ uname -a
> Linux mars 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64
> GNU/Linux
>
> while on Cygwin _GNU_SOURCE doesn't expose cuserid():
Thanks, I pushed a patch.
https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=09870c6e958c
Of course, that doesn't make cuserid more portable. The rule given in
the Linux man page still applies: "Do not use cuserid()."
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early
On Nov 26 17:46, Corinna Vinschen wrote: > On Nov 26 10:47, James E. King III wrote: > > On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen > > wrote: > > > > > > On Nov 25 09:01, James E. King III wrote: > > > > I have isolated a problem in pthread_cond_timedwait when the condattr > > > > is used to set the clock type to CLOCK_MONOTONIC. In this case even > > > > though a target time point in the future is specified, the call > > > > returns ETIMEDOUT but a subsequent call to > > > > clock_gettime(CLOCK_MONOTONIC) shows the desired time point was not > > > > reached. > > > > > > > > $ gcc timed_wait_short.c -o timed_wait_short > > > > $ ./timed_wait_short.exe > > > > [...] > > > > begin: 521056s 671907500n > > > > target: 521056s 721907500n > > > >end: 521056s 721578000n > > > > ok: false > > > > > > > > I have attached the source code. > > > > > > Thanks for the testcase. The problem is this: > > > [...] > > > At the moment I only have an *ugly* idea: We can always add the > > > coarsest resolution of the wait functions (typically 15.625 ms) to the > > > relative timeout value computed from the absolute timeout given to > > > pthread_cond_timedwait. In my testing this is sufficient since the > > > difference between target and actual end time is always < 15ms, in > > > thousands of runs. > > > > > > Thoughts? > > > > > > > > > Thanks, > > > Corinna > > > > > > (*) > > > https://docs.microsoft.com/en-us/windows/desktop/Sync/wait-functions#wait-functions-and-time-out-intervals > > > > > > -- > > > Corinna Vinschen > > > Cygwin Maintainer > > > > Some thoughts: > > > > https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/thread.cc;h=0bddaf345d255ae39187458dc6d02b1b4c8087c1;hb=HEAD#l2546 > > > > In pthread_convert_abstime, line 2564, care is taken to adjust for > > rounding errors. > > At line 2574, the rounding is not accounted for when adjusting for a > > relative wait because it is a monotonic clock. > > Wouldn't that rounding error cause it to wait less time? > > Au contraire: > > - The end time you're waiting for is rounded *up*. > - The current time is rounded *down* > - So end time - current time is always bigger than required > on the 100ns level. > > Make sense? I created a patch and uploaded new developer snapshots to https://cygwin.com/snapshots/ Please give them a try. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: Fwd: Regarding Cygwin version Windows 10
Am 29.11.2018 um 09:54 schrieb Aghil Nettodi.Thazhath: Hello Cygwin, I am using Cyqwin 1.7.9 on my Windows 10 machine. It seems to be causing some problem while building my project which does not occur on Windows 7. Thus, I suspect it could be somewhere linked with the Cygwin version being used. Would like to know if there is a recommended Cygwin version and DLL for Windows 10? Good day! Aghil last version is always the recommended one. If after updating you have still problem, please clarify which one and follows https://cygwin.com/problems.html guideline --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Not able to open Cygwin
Hi Team, We are not able to open cygwin in one of the machine. getting below ERROR. what might be the issue here? c:\cygwin\usr\sbin>inetd.exe -d /etc/inetd.conf 1 [main] inetd 2500 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com" Thanks, Manjunath? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ragel 7.0.0.11-3
On Nov 29 10:26, Corinna Vinschen wrote: [nil] Sorry, I screwed up. Nothing to see here (literally). Corinna signature.asc Description: PGP signature
[ANNOUNCEMENT] Test: cmake-3.13.1-1
Test version 3.13.3-1 of cmake cmake-doc cmake-gui emacs-cmake are available in the Cygwin distribution. Please test and report here any issue or problem. Also positive feedback in complex projects are appreciated CHANGES Last upstream release. DESCRIPTION CMake is an open-source, cross-platform family of tools designed to build, test and package software HOMEPAGE http://www.cmake.org/ Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ragel 7.0.0.11-3
-- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 32 bit vs 64 bit Cygwin, followup
Please, no top-posting. On Nov 28 11:06, Sam Habiel wrote: > Yaakov, > > On Wed, Nov 28, 2018 at 11:01 AM Yaakov Selkowitz wrote: > > > > On Mon, 2018-11-26 at 14:07 -0500, Sam Habiel wrote: > > > Hello everybody, > > > > > > In this message > > > (https://www.sourceware.org/ml/cygwin/2018-11/msg00190.html), Corinna > > > (Hi Corinna!) says: > > > > > > "Don't do that. Use 64 bit Cygwin whenever possible. 32 bit is a lost > > > cause." > > > > > > I would like to mention why I am still using 32 bit Cygwin. > > > > > > I maintain a port of a database called GT.M > > > (https://en.wikipedia.org/wiki/GT.M) on Cygwin. I work with Electronic > > > Medical Records that run on this database. GT.M contains a large > > > amount of assembly code, written to run on the x32 Linux ABI and the > > > AMD x64 ABI. It's was very easy to get the x32 Linux ABI to run on > > > Cygwin x32; Cygwin x64 on the other hand uses the Windows x64 ABI, > > > which is very different than the AMD ABI (more detail here: > > > https://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64/). > > > I don't have the expertise nor the time to rewrite a lot of assembly > > > code to use the Windows x64 ABI. There are about 100 source code files > > > that are in assembly. > > > > -mabi=sysv ? > > > Are you telling me that gcc has a flag to support AMD ABI on Cygwin > x64? The assembly code is not standalone; it gets called from C code > and calls C code. That's what he's telling you. However, you have to interact with the MS ABI(*) as well as soon as you call external library functions so it makes sense to keep your C code in MS ABI. For the assembler functions, you can just tell the compiler they are in SYSV ABI by adding a function attribute to the declaration: int asm_func (args) __attribute__ ((sysv_abi)) Good luck, Corinna (*) Just keep in mind that Cygwin is LP64, not LLP64: https://cygwin.com/faq/faq.html#faq.programming.64bitporting -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Fwd: Regarding Cygwin version Windows 10
Hello Cygwin, I am using Cyqwin 1.7.9 on my Windows 10 machine. It seems to be causing some problem while building my project which does not occur on Windows 7. Thus, I suspect it could be somewhere linked with the Cygwin version being used. Would like to know if there is a recommended Cygwin version and DLL for Windows 10? Good day! Aghil -- Warm Regards Aghil Nettodi Thazhath -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
