Re: Midnight Commander is very slow when starting and changing directories
On 25. 7. 2016 17:34, Krzysztof Bociurko wrote: > I have found this issue in a new incarnation - and this time it is NOT > with midnight commander but basic gnu utils. > Again it's the 4 seconds lost. > > $ time ls /cygdrive/ > c d > > real0m4.065s > user0m0.000s > sys 0m0.015s > > `ls /cygdrive/c` or `ls /cygdrive/d` take around 0.013s. Is it possible there's another -- unavailable -- drive letter, and the driver needs to wait 4 seconds before declaring it unavailable/disconnected? -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: problem building with cmake under cygwin (need clang)
On 26/07/2016 02:45, LMH wrote: Hello, I am trying to compute the convex hull of a high dimensional space (46D x 2000 rows). The qhull app available in cygwin/math is based on relatively old code and runs out of memory. I found another version the is supposed to be able to do higher dimensions. https://bitbucket.org/tomilov/quickhull/src This version is set up to build with cmake, so I installed cmake in cygwin and ran it as, cmake ./src Note, I had to copy CMakeLists.txt into the src directory to get this to work. If I don't do that, I get the error, CMake Error: The source directory "/cygdrive/g/shared_data/SMD/ATomilov_quickhull/tomilov-quickhull-7faf277d6cc2_cmake/src" does not appear to contain CMakeLists.txt. When I have copied the CMakeLists.txt file into ./src, cmake runs but I get the error, CMake Error at CMakeLists.txt:11 (message): only clang supported currently this comes from the conditional, if(NOT "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang") message(FATAL_ERROR "only clang supported currently") endif() in CMakeLists.txt. I have installed clang from cygwin, but I still get the same error. I added the following line to CMakeLists.txt, message(STATUS "${CMAKE_CXX_COMPILER_ID}") and I get "GNU" as the value for CMAKE_CXX_COMPILER_ID, at least that is the value if I got the syntax correct for the message statement. It looks like I need to point CMAKE_CXX_COMPILER_ID to clang, but I am not sure how to do that. I don't know if the problem is with the CMakeLists.txt file, the way I am calling cmake, or with my local cygwin configuration. Suggestions would be appreciated. LMH the build system of quickhull has some serious problem. set CMAKE_CXX_COMPILER /usr/bin/clang-3.8.exe CMAKE_C_COMPILER /usr/bin/clang-3.8.exe after you will hit CMake Error at CMakeLists.txt:22 (message): Compiler does not support C++1z standard if you look on CMakeLists.txt you will find is expecting a flag as "-std=gnu++1z" that looks a bit strange for a not gnu compiler I you want to build this program on cygwin, you need to learn a bit of cmake and debug the CMakeLists wrong assumptions Regards Marco -- 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: problem building with cmake under cygwin (need clang)
LMH molconn.com> writes: > It looks like I need to point CMAKE_CXX_COMPILER_ID to clang, but I am not sure how > to do that. I don't know if the problem is with the CMakeLists.txt file, the way I am > calling cmake, or with my local cygwin configuration. Are you setting -DCMAKE_CXX_COMPILER=clang ? -- 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
[ANNOUNCEMENT] glm 0.9.7.6-1
The following packages have been uploaded to the Cygwin distribution: * glm-devel-0.9.7.6-1 * glm-doc-0.9.7.6-1 * mingw64-i686-glm-0.9.7.6-1 * mingw64-x86_64-glm-0.9.7.6-1 OpenGL Mathematics (GLM) is a header only C++ mathematics library for graphics software based on the OpenGL Shading Language specifications. -- Yaakov -- 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
[ANNOUNCEMENT] liblangtag 0.6.0-1
The following packages have been uploaded to the Cygwin distribution: * liblangtag1-0.6.0-1 * liblangtag-common-0.6.0-1 * liblangtag-devel-0.6.0-1 * liblangtag-doc-0.6.0-1 * liblangtag-gobject0-0.6.0-1 * liblangtag-gobject-devel-0.6.0-1 * girepository-LangTag0.6-0.6.0-1 * mingw64-i686-liblangtag-0.6.0-1 * mingw64-x86_64-liblangtag-0.6.0-1 liblangtag is an interface library to access/deal with tags for identifying languages, which is described in RFC 5646. This is an initial release for Cygwin, added as a new dependency of libetonyek. -- Yaakov -- 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
[ANNOUNCEMENT] writerperfect 0.9.5-1 and dependencies
The following packages (and their subpackages) have been uploaded to the Cygwin distribution: * writerperfect-0.9.5-1 * libcdr0.1-0.1.3-1 * libe-book0.1-0.1.2-4 * libeot-0.01-1 * libetonyek0.1-0.1.6-1 * libfreehand0.1-0.1.1-1 * libmspub0.1-0.1.2-4 * libmwaw0.3-0.3.8-1 * libodfgen0.1-0.1.6-1 * libpagemaker0.0-0.0.3-1 * librevenge0.0-0.0.4-1 * librvngabw0.0-0.0.1-1 * libstaroffice0.0-0.0.1-1 * libvisio0.1-0.1.5-1 * libwpd0.10-0.10.1-1 * libwpg0.3-0.3.1-1 * libwps0.4-0.4.3-1 * mingw64-i686-libcdr0.1-0.1.3-1 * mingw64-i686-libetonyek0.1-0.1.6-1 * mingw64-i686-libfreehand0.1-0.1.1-1 * mingw64-i686-libmwaw0.3-0.3.8-1 * mingw64-i686-libodfgen0.1-0.1.6-1 * mingw64-i686-libpagemaker0.0-0.0.3-1 * mingw64-i686-librevenge0.0-0.0.4-1 * mingw64-i686-librvngabw0.0-0.0.1-1 * mingw64-i686-libstaroffice0.0-0.0.1-1 * mingw64-i686-libvisio0.1-0.1.5-1 * mingw64-i686-libwpd0.10-0.10.1-1 * mingw64-i686-libwpg0.3-0.3.1-1 * mingw64-i686-libwps0.4-0.4.3-1 * mingw64-x86_64-libcdr0.1-0.1.3-1 * mingw64-x86_64-libetonyek0.1-0.1.6-1 * mingw64-x86_64-libfreehand0.1-0.1.1-1 * mingw64-x86_64-libmwaw0.3-0.3.8-1 * mingw64-x86_64-libodfgen0.1-0.1.6-1 * mingw64-x86_64-libpagemaker0.0-0.0.3-1 * mingw64-x86_64-librevenge0.0-0.0.4-1 * mingw64-x86_64-librvngabw0.0-0.0.1-1 * mingw64-x86_64-libstaroffice0.0-0.0.1-1 * mingw64-x86_64-libvisio0.1-0.1.5-1 * mingw64-x86_64-libwpd0.10-0.10.1-1 * mingw64-x86_64-libwpg0.3-0.3.1-1 * mingw64-x86_64-libwps0.4-0.4.3-1 These utilities and libraries allow opening multiple office suite file formats and saving to OpenDocument, EPUB, AbiWord, or plain text and graphics formats. * libetonyek has several new build dependencies. * librvngabw and libstaroffice have been added. * libwps has been bumped to 0.4; the 0.3 version is now deprecated and will be removed once packages dependent thereon have been rebuilt. -- Yaakov -- 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 building with cmake under cygwin (need clang)
Hello, I am trying to compute the convex hull of a high dimensional space (46D x 2000 rows). The qhull app available in cygwin/math is based on relatively old code and runs out of memory. I found another version the is supposed to be able to do higher dimensions. https://bitbucket.org/tomilov/quickhull/src This version is set up to build with cmake, so I installed cmake in cygwin and ran it as, cmake ./src Note, I had to copy CMakeLists.txt into the src directory to get this to work. If I don't do that, I get the error, CMake Error: The source directory "/cygdrive/g/shared_data/SMD/ATomilov_quickhull/tomilov-quickhull-7faf277d6cc2_cmake/src" does not appear to contain CMakeLists.txt. When I have copied the CMakeLists.txt file into ./src, cmake runs but I get the error, CMake Error at CMakeLists.txt:11 (message): only clang supported currently this comes from the conditional, if(NOT "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang") message(FATAL_ERROR "only clang supported currently") endif() in CMakeLists.txt. I have installed clang from cygwin, but I still get the same error. I added the following line to CMakeLists.txt, message(STATUS "${CMAKE_CXX_COMPILER_ID}") and I get "GNU" as the value for CMAKE_CXX_COMPILER_ID, at least that is the value if I got the syntax correct for the message statement. It looks like I need to point CMAKE_CXX_COMPILER_ID to clang, but I am not sure how to do that. I don't know if the problem is with the CMakeLists.txt file, the way I am calling cmake, or with my local cygwin configuration. Suggestions would be appreciated. LMH -- 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
httpd-2.4.23 notice "No slotmem from mod_heartmonitor"
After obtaining the upgrade of the httpd package from 2.4.22 to 2.4.23, I received the following error on attempted startup: [Mon Jul 25 08:22:26.529504 2016] [proxy_balancer:emerg] [pid 1234] AH01177: Failed to lookup provider 'shm' for 'slotmem': is mod_slotmem_shm loaded?? Activating mod_slotmem_shm (as a shared module) resolved this issue and allowed httpd to start. However, httpd now produces the following notice on (successful) startup: [Mon Jul 25 09:27:40.718810 2016] [lbmethod_heartbeat:notice] [pid 2345] AH02282: No slotmem from mod_heartmonitor I'm wondering if there changes to the static modules included in the new version's package. The changelog for httpd itself didn't suggest any changes between these two versions that would cause configuration differences. I have tried activating mod_heartmonitor and mod_heartbeat from my configuration file, but the notice still appeared. I also tried activating mod_slotmem_plain with the same result. - Dominic R. Jones, Ph.D. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.1
On Mon, Jul 25, 2016 at 1:49 PM, Ken Brown wrote: > I'm also unable to start xterm from the xwin-xdg-menu (under System Tools). > Nothing happens when I click on XTerm, and I see the following error > message: > > $ cat .xsession-errors > executing 'xterm', pid 9928 > (pid 9928 stderr) execl failed: No such file or directory > pid 9928 exited with status 127 Same here. "Cygwin Terminal" won't launch from xdg either, but I can start a stand-alone Cygwin Terminal from *outside* of xdg. /etc/X11/xinit/startxwinrc: line 32: [: too many arguments /etc/X11/xinit/xinitrc-common: line 20: [: too many arguments Excessive file argument "Sync/Home/.Xresources" 1 error in preprocessor. Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box Sync/Home/Desktop Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box Sync/Home/Downloads Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box Sync/Home/Templates Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box Sync/Home/Public Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box Sync/Home/Documents Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box Sync/Home/Music Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box Sync/Home/Pictures Can't create dir /cygdrive/c/Users/reisert/Desktop/Box Sync/Box Sync/Home/Videos executing 'xterm', pid 4560 (pid 4560 stderr) execl failed: No such file or directory pid 4560 exited with status 127 -- Jim Reisert AD1C, , http://www.ad1c.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
Re: System tray menu tuning & Xwin0.log in mintty console with startx
Hello Marco, Excuse me but I don't specify before that I try to use Cygwin-Portable version that I find on the web. I put it in my pendrive. I use in various exam the program VIM EMACS & GCC so to have a them in portable cyg version is very confortable. Sorry if I forgot to add this information :-( However, I have essentially only one problem: when I run "startx" on mintty bash environment I see on the screen like a splash log file directly. Why? What can I erase the echoin on the screen when it execs the script "startx?" I don't reach to put off the stdout on the screen when I call "startx". Could I solve this? (take into account that there is a difference with startxwin. When I run "startxwin",It starts without echo-splash on the screen the X-server message). With reference to the other question, I solve it. Thank you again Alessandro -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.1
On 7/25/2016 3:13 PM, Ken Brown wrote: On 7/25/2016 11:43 AM, Corinna Vinschen wrote: Hi Cygwin developers and maintainers, Hi everyone else, I uploaded a new Cygwin test release 2.6.0-0.1. I'm unable to start Cygwin services (cygserver and sshd) with this release. The Windows Application Log just says "service `sshd' failed: signal 11 raised", and the same thing for cygserver. Does cygrunsrv have to be rebuilt? I'm on Windows 10, 64-bit Cygwin. I'm also unable to start xterm from the xwin-xdg-menu (under System Tools). Nothing happens when I click on XTerm, and I see the following error message: $ cat .xsession-errors executing 'xterm', pid 9928 (pid 9928 stderr) execl failed: No such file or directory pid 9928 exited with status 127 Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.1
On 7/25/2016 11:43 AM, Corinna Vinschen wrote: Hi Cygwin developers and maintainers, Hi everyone else, I uploaded a new Cygwin test release 2.6.0-0.1. I'm unable to start Cygwin services (cygserver and sshd) with this release. The Windows Application Log just says "service `sshd' failed: signal 11 raised", and the same thing for cygserver. Does cygrunsrv have to be rebuilt? I'm on Windows 10, 64-bit Cygwin. Ken -- 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
cygport : A[CM]_CONFIG_HEADERS extraction fault
Hi Yaakov, building librsb I hit a very unusual AC_CONFIG_HEADERS definition where the extraction logic implemented in /usr/share/cygport/cygclass/autotools.cygclass is failing. Attached file with examples -- $ grep 'A[CM]_CONFIG_HEADERS*' configure.ac | sed -e 's!A[CM]_CONFIG_HEADERS*(\[*\(.*\))!\1!g' -e 's!\]*!!g' config.h:config.in.h rsb-config.h,[sed 's/^#define /#define RSB_/g;s/ RSB_RSB_/ RSB_/g' rsb-config.h > rsb-config.h.tmp ; echo '#endif /* RSB_CONFIG_H_INCLUDED */' >> rsb-config.h.tmp ; cat $srcdir/rsb_license_header.inc $srcdir/rsb-config.h.hin rsb-config.h.tmp > rsb-config.h ; rm rsb-config.h.tmp --- The first is from a very standard definition, the second from the unusual one. I suppose the expected behavior is to catch only "rsb-config.h" and not all the rest. No clue how to solve Regards Marco AC_CONFIG_HEADERS([config.h:config.in.h]) AC_CONFIG_HEADERS([rsb-config.h],[sed 's/^#define /#define RSB_/g;s/ RSB_RSB_/ RSB_/g' rsb-config.h > rsb-config.h.tmp ; echo '#endif /* RSB_CONFIG_H_INCLUDED */' >> rsb-config.h.tmp ; cat $srcdir/rsb_license_header.inc $srcdir/rsb-config.h.hin rsb-config.h.tmp > rsb-config.h ; rm rsb-config.h.tmp]) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.1
On Jul 25 12:25, Erik Soderquist wrote: > On Mon, Jul 25, 2016 at 11:43 AM, Corinna Vinschen wrote: > > Hi Cygwin developers and maintainers, > > Hi everyone else, > > > > > > I uploaded a new Cygwin test release 2.6.0-0.1. > > > If I recall correctly, this is also the release that is expected to > break XP compatibility, yes? Yes. 2.6.0 will only run on Vista and later. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
G++ and OpenMP Issues
Hi We've been testing the -fopenmp feature of G++ in Cygwin. We can't get the CPU cores to go to 100% when compiling with the GCC version of G++. If we compile with the MinGW version, the CPUs go to 100%. I've tried several versions of GCC. I started with recent 5.4 version and worked back to 4.8.2. None of the versions will run 100%. In Linux the same code works correctly, going 100% CPU in the parallel sections of the code. Is there something I'm missing in the Cygwin that prevents -fopenmp from running 100% across all the CPUs? Please, any assistance would be greatly appreciated. Thanks, Charlie -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.1
On Mon, Jul 25, 2016 at 11:43 AM, Corinna Vinschen wrote: > Hi Cygwin developers and maintainers, > Hi everyone else, > > > I uploaded a new Cygwin test release 2.6.0-0.1. If I recall correctly, this is also the release that is expected to break XP compatibility, yes? -- Erik -- 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
[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.1
Hi Cygwin developers and maintainers, Hi everyone else, I uploaded a new Cygwin test release 2.6.0-0.1. === For those building Cygwin from source, the new code is only available in the topic/locales branch yet. === The 2.6.0 release is going to introducing the locale_t datatype, as well as all functions related to locale_t locales and per-thread locales per POSIX-1.2008. So, rather than just providing a single, per-process locale, you can now create new locales ("newlocale") and set it as locale for the current thread ("uselocale") or use it directly with one of the new functions taking a locale_t as parameter (i.e. isalpha_l). The full list of new interfaces is: newlocale, freelocale, duplocale, uselocale isalnum_l, isalpha_l, isascii_l, isblank_l, iscntrl_l, isdigit_l, isgraph_l, islower_l, isprint_l, ispunct_l, isspace_l, isupper_l, iswalnum_l, iswalpha_l, iswblank_l, iswcntrl_l, iswctype_l, iswdigit_l, iswgraph_l, iswlower_l, iswprint_l, iswpunct_l, iswspace_l, iswupper_l, iswxdigit_l, isxdigit_l toascii_l, tolower_l, toupper_l, towctrans_l, towlower_l, towupper_l, wctrans_l, wctype_l strcasecmp_l, strcoll_l, strncasecmp_l, strxfrm_l wcscasecmp_l, wcscoll_l, wcstrncasecmp_l, wcstrxfrm_l strfmon_l, strftime_l === Since this is brand-new code, this code *will* have bugs. It would be very helpful if interested developers and Cygwin package maintainers could give this new stuff some good testing. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: Midnight Commander is very slow when starting and changing directories
I have found this issue in a new incarnation - and this time it is NOT with midnight commander but basic gnu utils. Again it's the 4 seconds lost. $ time ls /cygdrive/ c d real0m4.065s user0m0.000s sys 0m0.015s `ls /cygdrive/c` or `ls /cygdrive/d` take around 0.013s. Interesting part from strace (full log attached): 18 11803 [main] ls 4804 symlink_info::check: 0 = symlink.check(D:\, 0xB4D0) (0x406000) 19 11822 [main] ls 4804 path_conv::check: this->path(D:\), has_acls(0) 29 11851 [main] ls 4804 fhandler_cygdrive::readdir: 0xC870 = readdir (0x60003EFD0) (d) 4061656 4073507 [main] ls 4804 normalize_posix_path: src /cygdrive/.. 77 4073584 [main] ls 4804 normalize_posix_path: checking /cygdrive before '..' 84 4073668 [main] ls 4804 normalize_posix_path: src /cygdrive 18 4073686 [main] ls 4804 normalize_posix_path: /cygdrive = normalize_posix_path (/cygdrive) Also `mount`: $ time mount C:/cygwin64/bin on /usr/bin type ntfs (binary,auto) C:/cygwin64/lib on /usr/lib type ntfs (binary,auto) C:/cygwin64 on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) real0m4.073s user0m0.000s sys 0m0.000s Interesting strace part (full log attached): 20 11447 [main] mount 3876 write: 64 = write(1, 0x60003A320, 64) 178 11625 [main] mount 3876 fhandler_pty_slave::write: pty2, write(0x60003A320, 64) 18 11643 [main] mount 3876 fhandler_pty_common::process_opost_output: (1909): pty output_mutex (0x100): waiting -1 ms 18 11661 [main] mount 3876 fhandler_pty_common::process_opost_output: (1909): pty output_mutex: acquired 18 11679 [main] mount 3876 fhandler_pty_common::process_opost_output: (1948): pty output_mutex(0x100) released 20 11699 [main] mount 3876 write: 64 = write(1, 0x60003A320, 64) 4055597 4067296 [main] mount 3876 do_exit: do_exit (0), exit_state 1 47 4067343 [main] mount 3876 void: 0x0 = signal (20, 0x1) 19 4067362 [main] mount 3876 void: 0x0 = signal (1, 0x1) 18 4067380 [main] mount 3876 void: 0x0 = signal (2, 0x1) 17 4067397 [main] mount 3876 void: 0x0 = signal (3, 0x1) 2016-07-12 15:41 GMT+02:00 Marco Atzeri : > On 12/07/2016 15:24, Krzysztof Bociurko wrote: >> >> Recompiled mc on cygwin with default and --without-vfs, did not fix issue >> >> Tried to install the unofficial win32 mc build that is not using >> cygwin - and this issue is still there! > > > I guess it is some BLODA. > Cygwin can not really slow down a native application. > >> >> I think this is not an issue with cygwin. Will try with MC's issue >> tracker/mailing list/whatever they got. >> >> Could someone verify that the unofficial windows build of mc does not >> use cygwin? >> https://sourceforge.net/projects/mcwin32/ >> > > the description says > > "Windows XP+/32 bit native port of GNU Midnight Commander, based on the > current 4.8.13/14 development stream." > > So I doubt was ever a cygwin one. > > I am not aware that there is another mc cygwin build around > than then > https://sourceware.org/ml/cygwin-announce/2016-05/msg00033.html > > > Regards > Marco > > > > > -- > 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 > --- Process 4804 created --- Process 4804 loaded C:\Windows\System32\ntdll.dll at 7FFA14A1 --- Process 4804 loaded C:\Windows\System32\kernel32.dll at 7FFA13DB --- Process 4804 loaded C:\Windows\System32\KernelBase.dll at 7FFA1113 --- Process 4804 thread 7632 created --- Process 4804 thread 5672 created --- Process 4804 loaded C:\cygwin64\bin\cygwin1.dll at 00018004 --- Process 4804 loaded C:\cygwin64\bin\cygintl-8.dll at 0003F6D1 --- Process 4804 thread 19060 created --- Process 4804 loaded C:\cygwin64\bin\cygiconv-2.dll at 0003FA61 1 1 [main] ls (4804) ** 167 168 [main] ls (4804) Program name: C:\cygwin64\bin\ls.exe (windows pid 4804) 172 340 [main] ls (4804) OS version: Windows NT-10.0 27 367 [main] ls (4804) ** 85 452 [main] ls (4804) sigprocmask: 0 = sigprocmask (0, 0x0, 0x18031CBA8) 320 772 [main] ls 4804 open_shared: name shared.5, n 5, shared 0x18003 (wanted 0x18003), h 0xB4, *m 6 70 842 [main] ls 4804 user_heap_info::init: heap base 0x6, heap top 0x6, heap size 0x2000 (536870912) 34 876 [main] ls 4804 open_shared: name S-1-5-21-223587051-61534812-2133103721-1001.1, n 1, shared 0x18002 (wanted 0x18002), h 0xB0, *m 6 20 896 [main] ls 4804 user_info::create: opening user shared for 'S-1-5-21-223