help compilation qemu
Good morning, in a previous post I was debating with some nice users (for technical reasons I can't retrieve that thread)The point is that although the qemu wiki says it can't compile with cygwin for 64-bit it actually can, and for technical reasons I haven't been able to communicate it before,The case is that making a couple of adjustments when looking for all the mingw packages if they can be found, but there is a problem,Well, really two problems.1 the compiler is extremely slow, gcc on Linux is about 10 times faster, How could I speed up the compilation process?. 2 the executables produced are too fat, for example qemu-system-i386 is 65 MB, but it should be 10.5 MB, if I use the -s option in configure returns an unknown error message, how could I fix it? Thank you -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK
On 2020-05-23 09:50, Marco Atzeri via Cygwin wrote: > On 23.05.2020 17:09, Kagami Rosylight via Cygwin wrote: >> I found that Cygwin can’t run UWP based CLI tools, as they expose their >> executables as reparse points with the tag IO_REPARSE_TAG_APPEXECLINK which >> Cygwin does not support. >> >> Way to reproduce this issue on Cygwin: >> >> 1. Install Python from Microsoft Store: >> https://www.microsoft.com/en-us/p/python-38/9mssztt1n39l (assuming you don’t >> already have python3.8 on your PATH.) >> 2. Try running `python3.8` on Cygwin. It will say >> “/cygdrive/c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8: >> Permission denied” >> 3. Check it’s real path by `get-childitem -path >> C:/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8.exe` on >> PowerShell. It’s `C:\Program >> Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1008.0_x64__qbz5n2kfra8p0\python3.8.exe`. >> >> 4. Try running python again with that path. This succeeds. >> >> I posted this issue on MSYS2 GitHub repo >> (https://github.com/msys2/MSYS2-packages/issues/1943) but I think Cygwin is >> the right place to file this. >> >> Relevant prior works: >> >> * Python >> https://github.com/python/cpython/commit/df2d4a6f3d5da2839c4fc11d31511c8e028daf2c >> * libuv >> https://github.com/libuv/libuv/commit/e7ebae26247d2fee0a04547eb7f9aa8f78d4a642 >> * PowerShell https://github.com/PowerShell/PowerShell/pull/10331 > Not clear why you expect that a Windows specific tag as > IO_REPARSE_TAG_APPEXECLINK should be supported on a Posix platform ? > > Moreover all the documentation from MS seems > > https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4 > > that seems a bit short to help third party in properly using it. I think the general point being made is that /some/ Windows tools can not be run from Cygwin. I wonder what happens if the OP runs "cygstart python3.8"? -- 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 IEC 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
Re: Updating glib2.0
On 5/22/2020 7:18 PM, Ken Brown via Cygwin-apps wrote: I've been planning to adopt gimp and some related build dependencies. My reason is that I use gimp and would like to see it kept up to date. I thought I had all the prerequisites I needed. But when I built gimp, I discovered that it used two functions, g_set_weak_pointer and g_date_time_new_from_iso8601, that were introduced in glib-2.56. [gimp's configure.ac says that it only requires glib 2.54.2, but this seems to be wrong. Cygwin's glib is at 2.54.3. Fedora's is at 2.64.3, which is the latest upstream release.] I'd appreciate some advice about how to proceed. I'm not interested in adopting all of GNOME, and it probably doesn't make sense for different components of GNOME to be adopted by different people. A short-term solution (from my personal POV) would be for me to do a non-maintainer update of glib to 2.56, assuming that's doable without messing up other GNOME components. A better solution (again from my personal POV) would be for someone to adopt GNOME and update it to its latest release. To focus the discussion a little better, I've built and installed glib2.0-2.56.4. My cygport file and patches are attached. I can now build gimp-2.10.18, and it seems to run fine in limited testing. Ken Fix for -Werror=nested-externs --- origsrc/glib-2.34.3/m4macros/glib-gettext.m42012-11-20 08:27:12.0 -0600 +++ src/glib-2.34.3/m4macros/glib-gettext.m42013-04-15 02:04:25.707401500 -0500 @@ -222,8 +222,8 @@ msgstr "" AC_PATH_PROG(GMSGFMT, gmsgfmt, $MSGFMT) GLIB_PATH_PROG_WITH_TEST(XGETTEXT, xgettext, [test -z "`$ac_dir/$ac_word -h 2>&1 | grep '(HELP)'`"], :) - AC_TRY_LINK(, [extern int _nl_msg_cat_cntr; -return _nl_msg_cat_cntr], + AC_TRY_LINK([extern int _nl_msg_cat_cntr;], + [return _nl_msg_cat_cntr], [CATOBJEXT=.gmo DATADIRNAME=share], [case $host in --- origsrc/glib-2.36.3/configure.ac2013-08-04 20:21:20.808722600 -0500 +++ src/glib-2.36.3/configure.ac2013-08-04 18:30:21.852852200 -0500 @@ -1880,7 +1880,7 @@ dnl AC_MSG_CHECKING(for platform-dependent source) case "$host" in - *-*-cygwin*|*-*-mingw*) + *-*-mingw*) PLATFORMDEP=gwin32.lo ;; *) @@ -2594,9 +2594,6 @@ dnl *** Win32 API libs *** dnl ** case $host in - *-*-cygwin*) - G_LIBS_EXTRA="-luser32 -lkernel32" -;; *-*-mingw*) G_LIBS_EXTRA="-lws2_32 -lole32 -lwinmm -lshlwapi" ;; --- origsrc/glib-2.36.3/docs/reference/gio/Makefile.am 2013-08-04 20:21:20.849725000 -0500 +++ src/glib-2.36.3/docs/reference/gio/Makefile.am 2013-08-04 18:11:14.0 -0500 @@ -77,6 +77,8 @@ IGNORE_HFILES = \ gunixvolume.h \ gunixvolumemonitor.h\ gwin32appinfo.h \ + gwin32inputstream.h \ + gwin32outputstream.h\ gwin32mount.h \ gwin32resolver.h\ gwin32volumemonitor.h --- origsrc/glib-2.36.3/gio/giomodule-priv.h2013-08-04 20:21:20.877726600 -0500 +++ src/glib-2.36.3/gio/giomodule-priv.h2013-08-04 18:11:14.0 -0500 @@ -39,7 +39,7 @@ GType_g_io_module_get_default_type ( const gchar *envvar, guintis_supported_offset); -#ifdef G_PLATFORM_WIN32 +#ifdef G_OS_WIN32 void *_g_io_win32_get_module (void); #endif --- origsrc/glib-2.36.3/gio/giomodule.c 2013-08-04 20:21:20.886727100 -0500 +++ src/glib-2.36.3/gio/giomodule.c 2013-08-04 18:11:14.0 -0500 @@ -894,7 +894,7 @@ extern GType g_network_monitor_base_get_ extern GType _g_network_monitor_netlink_get_type (void); #endif -#ifdef G_PLATFORM_WIN32 +#ifdef G_OS_WIN32 #include --- origsrc/glib-2.36.3/gio/tests/live-g-file.c 2013-08-04 20:21:20.898727800 -0500 +++ src/glib-2.36.3/gio/tests/live-g-file.c 2013-08-04 18:11:14.0 -0500 @@ -1282,7 +1282,7 @@ main (int argc, char *argv[]) write_test = TRUE; only_create_struct = FALSE; target_path = DEFAULT_TEST_DIR; -#ifdef G_PLATFORM_WIN32 +#ifdef G_OS_WIN32 posix_compat = FALSE; #else posix_compat = TRUE; --- origsrc/glib-2.36.3/glib/gatomic.c 2013-08-04 20:21:20.907728300 -0500 +++ src/glib-2.36.3/glib/gatomic.c 2013-08-04 18:11:14.0 -0500 @@ -464,7 +464,7 @@ gsize return g_atomic_pointer_xor ((volatile gpointer *) atomic, val); } -#elif defined (G_PLATFORM_WIN32) +#elif defined (G_OS_WIN32) #include #if !defined(_M_AMD64) && !defined (_M_IA64) && !defined(_M_X64) && !(defined _MSC_VER && _MSC_VER <= 1200) --- origsrc/glib-2.36.3/glib/gcharset.c 2013-08-04 20:21:20.925729300 -0500 +++ src/glib-2.36.3/glib/gcharset.c 2013-08-04 18:11:14.0
Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK
On 23.05.2020 17:09, Kagami Rosylight via Cygwin wrote: Hi Cygwin community, I found that Cygwin can’t run UWP based CLI tools, as they expose their executables as reparse points with the tag IO_REPARSE_TAG_APPEXECLINK which Cygwin does not support. Way to reproduce this issue on Cygwin: 1. Install Python from Microsoft Store: https://www.microsoft.com/en-us/p/python-38/9mssztt1n39l (assuming you don’t already have python3.8 on your PATH.) 2. Try running `python3.8` on Cygwin. It will say “/cygdrive/c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8: Permission denied” 3. Check it’s real path by `get-childitem -path C:/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8.exe` on PowerShell. It’s `C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1008.0_x64__qbz5n2kfra8p0\python3.8.exe`. 4. Try running python again with that path. This succeeds. I posted this issue on MSYS2 GitHub repo (https://github.com/msys2/MSYS2-packages/issues/1943) but I think Cygwin is the right place to file this. Relevant prior works: * Python https://github.com/python/cpython/commit/df2d4a6f3d5da2839c4fc11d31511c8e028daf2c * libuv https://github.com/libuv/libuv/commit/e7ebae26247d2fee0a04547eb7f9aa8f78d4a642 * PowerShell https://github.com/PowerShell/PowerShell/pull/10331 Thanks, -Kagami Not clear why you expect that a Windows specific tag as IO_REPARSE_TAG_APPEXECLINK should be supported on a Posix platform ? Moreover all the documentation from MS seems https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4 that seems a bit short to help third party in properly using it. Regards Marco PS: Python 3.8 is available as Cygwin binary -- 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: update on python refreshing
On 23.05.2020 10:48, Marco Atzeri wrote: As I am blocked on the python update, I would like to inform you about the issue On i686 arch and only on that, in all versions 3.8.3 and 2.7.18 the sh.exe segfaults during configure The logs on 3.8.3 and also rebuilding 3.8.2 --- checking for use_env... yes configure: checking for device files checking for /dev/ptmx... yes make: *** No targets specified and no makefile found. Stop. *** ERROR: make failed --- on 2.7.18: --- checking for /dev/ptmx... yes checking for /dev/ptc... no checking for %lld and %llu printf() format support... make: *** No targets specified and no makefile found. Stop. ESC[1;31m*** ERROR:ESC[0;0m make failed 15 [main] sh 6354 D:\cygwin32\bin\sh.exe: *** fatal error in forked process - WFSO timed out after longjmp 80937 [main] sh 6354 cygwin_exception::open_stackdumpfile: Dumping stack trace to sh.exe.stackdump --- In one of the 3 cases no stack dump is produced, while for the other two I have: $ cat sh.exe.stackdump Stack trace: Frame Function Args 006DC078 61084F28 (, 77BE6DD2, 00777E68, 0077) $ cat sh.exe.stackdump Stack trace: Frame Function Args 006DC438 61084F28 (0148, , , 0018) End of stack trace $ addr2line.exe -a 61084F28 -e /usr/bin/cygwin1.dll 0x61084f28 /usr/src/debug/cygwin-3.1.4-1/winsup/cygwin/fork.cc:650 As 3.8.2 was built before, it seems a recent change in Cygwin is impacting the 32bit platform. It seems I forgot the announce, but last build was 10th of April https://cygwin.com/packages/x86/python38/python38-3.8.2-1 so I will try to bisect Cygwin to see when this problem arose. Crossing finger Marco It seems I was lucky, current git does not have the problem so I was able to build both 3.8.3 and 2.7.18 without any need for a bisect. Give me some time for the packaging and I will update both Regards Marco
update on python refreshing
As I am blocked on the python update, I would like to inform you about the issue On i686 arch and only on that, in all versions 3.8.3 and 2.7.18 the sh.exe segfaults during configure The logs on 3.8.3 and also rebuilding 3.8.2 --- checking for use_env... yes configure: checking for device files checking for /dev/ptmx... yes make: *** No targets specified and no makefile found. Stop. *** ERROR: make failed --- on 2.7.18: --- checking for /dev/ptmx... yes checking for /dev/ptc... no checking for %lld and %llu printf() format support... make: *** No targets specified and no makefile found. Stop. ESC[1;31m*** ERROR:ESC[0;0m make failed 15 [main] sh 6354 D:\cygwin32\bin\sh.exe: *** fatal error in forked process - WFSO timed out after longjmp 80937 [main] sh 6354 cygwin_exception::open_stackdumpfile: Dumping stack trace to sh.exe.stackdump --- In one of the 3 cases no stack dump is produced, while for the other two I have: $ cat sh.exe.stackdump Stack trace: Frame Function Args 006DC078 61084F28 (, 77BE6DD2, 00777E68, 0077) $ cat sh.exe.stackdump Stack trace: Frame Function Args 006DC438 61084F28 (0148, , , 0018) End of stack trace $ addr2line.exe -a 61084F28 -e /usr/bin/cygwin1.dll 0x61084f28 /usr/src/debug/cygwin-3.1.4-1/winsup/cygwin/fork.cc:650 As 3.8.2 was built before, it seems a recent change in Cygwin is impacting the 32bit platform. It seems I forgot the announce, but last build was 10th of April https://cygwin.com/packages/x86/python38/python38-3.8.2-1 so I will try to bisect Cygwin to see when this problem arose. Crossing finger Marco
