Re: native Linux userland in Windows 10
On 21. 4. 2016 18:01, John Cowan wrote: > David Macek scripsit: > >> You're assuming LSW will become pre-installed on these workstations and >> UoW will become a Windows Store "app". I'm not saying it can't happen, >> but it seems unlikely at the moment. > > Why unlikely? That is exactly what is the case, if you are running > the current alpha build of Windows 10. Build #14316? You have to switch to developer mode, then install the subsystem which is a "Windows feature". Both require administrator privileges IIRC. Then you can run `bash` or `lxrun /install` to download the Ubuntu tarball, allegedly from the Store. Until I can go to the Store app on a clean Windows install, write "Ubuntu" and click on Install, I won't consider UoW as "available through the Windows Store" as Warren Young wrote. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: native Linux userland in Windows 10
On 22/04/2016 08:02, David Macek wrote: On 21. 4. 2016 18:01, John Cowan wrote: David Macek scripsit: You're assuming LSW will become pre-installed on these workstations and UoW will become a Windows Store "app". I'm not saying it can't happen, but it seems unlikely at the moment. Why unlikely? That is exactly what is the case, if you are running the current alpha build of Windows 10. Build #14316? You have to switch to developer mode, then install the subsystem which is a "Windows feature". Both require administrator privileges IIRC. Then you can run `bash` or `lxrun /install` to download the Ubuntu tarball, allegedly from the Store. Until I can go to the Store app on a clean Windows install, write "Ubuntu" and click on Install, I won't consider UoW as "available through the Windows Store" as Warren Young wrote. You also need a huge pinch of good luck as the process is flaky as hell, often failing to present any preview builds at all. Regards Steve -- 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] Updated: Cygwin 2.5.1-1
Hi Cygwin friends and users, I just released the new Cygwin version 2.5.1-1. 2.5.1 is a bugfix release only. Additionally the cygwin-devel package contains a few more changes to the header files. This is a still ongoing process, revamping the header files to be closer to FreeBSD headers as upstream, as well as being better aligned to POSIX requirements and Glibc expectations. Bug Fixes - - Fix strxfrm/wcsxfrm return value if output buffer is too small. Fix wcsxfrm return value either way. Addresses: https://cygwin.com/ml/cygwin/2016-04/msg00232.html - Fix bug introduced in 2.5.0: Fix condition specifying when to write a NULL SID ACE. Addresses: https://cygwin.com/ml/cygwin/2016-04/msg00400.html - Remove spurious checks for already initialized pthread object in pthread object init functions. Addresses: https://cygwin.com/ml/cygwin/2016-04/msg00473.html Have fun, 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: Process map and fork problems
Marco Atzeri gmail.com> writes: > Octave is a good chuck, but not the only one That gave me an idea... actually, Octave collectively is taking up about 60% of the address space on my installation. Or rather octave-forge is and more specifically just one package: octave-tisean. So I guess I should blacklist that since I don't think anybody around here uses it. I'm not sure why these dynamic modules are as large as they are, but they are by far the largest ones in the whole install, followed distantly by the netcdf DLL. Regards, Achim. -- 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
Program start blocked / mintty?
I had one machine where a few applications, including mintty, would stubbornly not start, mostly without any trace of a problem. Only in one case, I got an error message 0 [sig] -bash 1164536 get_proc_lock: Couldn't acquire sync_proc_subproc for(5,1), last 7, Win32 error 0 2537 [sig] -bash 1164536 proc_subproc: couldn't get proc lock. what 5, val 1 This was reported in https://sourceware.org/ml/cygwin/2013-05/msg00026.html already, where cgf answered it should be fixed in the next shapshot. But only a few months later, it was reported again: https://cygwin.com/ml/cygwin/2013-12/msg00128.html By help of google, I got aware of an association to the Avast virus scanner, so I temporarily disabled it's runtime checking feature and voilà – seamless operation! So my questions: What change back in 2013 may cgf have referred to that could have fixed the issue (and maybe was broken later again, or could be repolished to really fix it)? If there is nothing cygwin can do, how could Avast be convinced to rectify this issue? -- Thomas -- 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: Process map and fork problems
On 22/04/2016 13:58, Achim Gratz wrote:
Marco Atzeri gmail.com> writes:
Octave is a good chuck, but not the only one
That gave me an idea... actually, Octave collectively is taking up about 60%
of the address space on my installation. Or rather octave-forge is and more
specifically just one package: octave-tisean. So I guess I should blacklist
that since I don't think anybody around here uses it. I'm not sure why
these dynamic modules are as large as they are, but they are by far the
largest ones in the whole install, followed distantly by the netcdf DLL.
Regards,
Achim.
the dll's are small
$ cd /usr/lib/octave/packages/tisean-0.2.3/x86_64-unknown-cygwin-api-v50+/
$ du -hs
1.6M.
but clearly, there is something wrong in them:
$ rebase -si | awk '{print $5, $1}' |sort
...
0x01038000 /usr/bin/cygoctinterp-3.dll
0x0104f000 /usr/bin/cygoctave-3.dll
0x0123a000 /usr/bin/cyggcj-16.dll
0x0126e000 /usr/bin/cyggcj-15.dll
0x012ad000 /usr/bin/cygLLVM-3.5.dll
0x017ed000 /usr/bin/cygicudata56.dll
0x01834000 /usr/bin/cygicudata54.dll
0x01885000 /usr/bin/cygicudata57.dll
0x01f98000 /usr/bin/cygQt5WebKit-5.dll
0x03126000 /usr/bin/cygnetcdf-11.dll
0x0cb25000
/usr/lib/octave/packages/tisean-0.2.3/i686-pc-cygwin-api-v50+/__surrogates__.oct
0x0cb25000
/usr/lib/octave/packages/tisean-0.2.3/i686-pc-cygwin-api-v50+/__upo__.oct
0x0cb25000
/usr/lib/octave/packages/tisean-0.2.3/i686-pc-cygwin-api-v50+/lazy.oct
0x0cb26000
/usr/lib/octave/packages/tisean-0.2.3/i686-pc-cygwin-api-v50+/__c1__.oct
I will investigate.
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: Process map and fork problems
Marco Atzeri gmail.com> writes: > the dll's are small > > $ cd /usr/lib/octave/packages/tisean-0.2.3/x86_64-unknown-cygwin-api-v50+/ > > $ du -hs > 1.6M. > > but clearly, there is something wrong in them: Static data? The bss segment is taking up much space... $ objdump -h tisean-0.2.3/x86_64-unknown-cygwin-api-v50+/__surrogates__.oct tisean-0.2.3/x86_64-unknown-cygwin-api-v50+/__surrogates__.oct: file format pei-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .text 000154e0 0003ca061000 0003ca061000 0400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 01f8 0003ca077000 0003ca077000 00015a00 2**6 CONTENTS, ALLOC, LOAD, DATA 2 .rdata190c 0003ca078000 0003ca078000 00015c00 2**6 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .buildid 0035 0003ca07a000 0003ca07a000 00017600 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .pdata05ac 0003ca07b000 0003ca07b000 00017800 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .xdata0bd4 0003ca07c000 0003ca07c000 00017e00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .bss 0cb050f0 0003ca07d000 0003ca07d000 2**6 ALLOC 7 .edata0e8e 0003d6b83000 0003d6b83000 00018a00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .idata0fb4 0003d6b84000 0003d6b84000 00019a00 2**2 CONTENTS, ALLOC, LOAD, DATA 9 .reloc00b8 0003d6b85000 0003d6b85000 0001aa00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA Regards, Achim. -- 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: Process map and fork problems
Achim Gratz NexGo.DE> writes: > Static data? The bss segment is taking up much space... Yup, the F77 parts apparently use COMMON arrays "the sizes are chosen generously for normal purposes". Ugh. Regards, Achim. -- 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: XWin startup crash x86_64 Windows 10
On 21/04/2016 17:31, Sergio Gomez wrote:
Hi,
Thanks for reporting this problem.
After a fresh installation of Cygwin x86_64 in a Windows 10 machine, XWin
crashes during startup (rest of Cygwin seems OK). Here is the backtrace:
[...]
(gdb) r
Starting program: /usr/bin/XWin -multiwindow
[New Thread 10320.0xd2c]
[New Thread 10320.0x2370]
[New Thread 10320.0x280]
[New Thread 10320.0x243c]
[New Thread 10320.0x1050]
gdb: unknown target exception 0x8001 at 0x180071a71
This is STATUS_GUARD_PAGE_VIOLATION
Program received signal ?, Unknown signal.
[Switching to Thread 10320.0x1050]
0x000180071a71 in myfault_altstack_handler (exc=0x1cb050)
at /usr/src/debug/cygwin-2.5.0-1/winsup/cygwin/exceptions.cc:615
615 {
(gdb) bt full
#0 0x000180071a71 in myfault_altstack_handler (exc=0x1cb050)
at /usr/src/debug/cygwin-2.5.0-1/winsup/cygwin/exceptions.cc:615
me =
[...]
#8 0x7ffc24b25c5f in ntdll!RtlAllocateHeap () from
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
No symbol table info available.
#9 0x76145cff in ?? ()
from
/cygdrive/c/WINDOWS/system32/tmumh/20019/TmMon/1.6.0.1112/tmmon64.dll
No symbol table info available.
#10 0x76145a37 in ?? ()
This DLL apparently belongs to Trend Micro.
Unless you can reproduce this issue with that software uninstalled, I
suggest you raise it with them.
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
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: Program start blocked / mintty?
On 22. 4. 2016 14:12, Thomas Wolff wrote: > If there is nothing cygwin can do, how could Avast be convinced to rectify > this issue? I have not used Avast for some time now (mostly due to its other bugs), but you can definitely add an exception for everything under cygwin/bin. I'm not sure if the sandboxing feature respects these exceptions, but you can always disable it completely. -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
RE: XWin startup crash x86_64 Windows 10
Thanks Jon!
You're right, after adding the Cygwin bin folder to the exception list of
TrendMicro, everything works fine. The strange thing is that it worked for the
32 bit installation of Cygwin/X, maybe the problem was after an update of TM
with XWin.exe already running. Anyway, now it works and it seems it is not a
problem of Cygwin :-)
Thank you very much!
Sergio.
-Mensaje original-
De: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] En nombre de Jon
Turney
Enviado el: divendres, 22 d’abril de 2016 16:20
Para: cygwin@cygwin.com
CC: Sergio Gomez
Asunto: Re: XWin startup crash x86_64 Windows 10
On 21/04/2016 17:31, Sergio Gomez wrote:
> Hi,
Thanks for reporting this problem.
> After a fresh installation of Cygwin x86_64 in a Windows 10 machine,
> XWin crashes during startup (rest of Cygwin seems OK). Here is the backtrace:
[...]
> (gdb) r
> Starting program: /usr/bin/XWin -multiwindow [New Thread 10320.0xd2c]
> [New Thread 10320.0x2370] [New Thread 10320.0x280] [New Thread
> 10320.0x243c] [New Thread 10320.0x1050]
> gdb: unknown target exception 0x8001 at 0x180071a71
This is STATUS_GUARD_PAGE_VIOLATION
> Program received signal ?, Unknown signal.
> [Switching to Thread 10320.0x1050]
> 0x000180071a71 in myfault_altstack_handler (exc=0x1cb050)
> at /usr/src/debug/cygwin-2.5.0-1/winsup/cygwin/exceptions.cc:615
> 615 {
> (gdb) bt full
> #0 0x000180071a71 in myfault_altstack_handler (exc=0x1cb050)
> at /usr/src/debug/cygwin-2.5.0-1/winsup/cygwin/exceptions.cc:615
> me =
[...]
> #8 0x7ffc24b25c5f in ntdll!RtlAllocateHeap () from
> /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> No symbol table info available.
> #9 0x76145cff in ?? ()
> from
> /cygdrive/c/WINDOWS/system32/tmumh/20019/TmMon/1.6.0.1112/tmmon64.dll
> No symbol table info available.
> #10 0x76145a37 in ?? ()
This DLL apparently belongs to Trend Micro.
Unless you can reproduce this issue with that software uninstalled, I suggest
you raise it with them.
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
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
Re: Process map and fork problems
On 22/04/2016 15:23, Achim Gratz wrote: Achim Gratz NexGo.DE> writes: Static data? The bss segment is taking up much space... Yup, the F77 parts apparently use COMMON arrays "the sizes are chosen generously for normal purposes". Ugh. Regards, Achim. I opened a ticket upstream https://savannah.gnu.org/bugs/index.php?47761 As it is reusing a third library I do not expect a fast correction. I will report also on netcdf the same issue. Thanks 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
ld randomly assigns wrong user and group IDs to executable
This is a strange one.
cygwin 2.5.1-1
binutils 2.25-4
Lately my attempt to build fish keeps failing, and I've traced it to the
following problem:
During configure, a particular c++ program compiles fine, but the generated
executable has the wrong user and group IDs and permissions, so the
configure test fails and my build fails.
Here are the source files and generated executable:
$ ls -l conftest*
-rw-r--r-- 1 ASchulma Domain Users 1911 Apr 22 13:11 conftest.cpp
-rw-r--r-- 1 ASchulma Domain Users466 Apr 22 13:11 conftest.err
-rwxr-x--- 1 Unknown+User Unknown+Group 62152 Apr 22 13:11 conftest.exe
$ ls -ln conftest.exe
-rwxr-x--- 1 4294967295 4294967295 62152 Apr 22 13:11 conftest.exe
Note the strange, apparently random user and group ID numbers for
conftest.exe.
* This happens about half the time. The other half of the time, the user
and group IDs are mine and so the build succeeds. I haven't been able to
figure out when it will fail.
* The user and group IDs are always the same, 4294967295, when the problem
happens.
* It only happens with this one program - other tests in configure work
fine.
* When I compile the program on my own, outside of configure, it builds
fine, two compiler warnings aside.
An excerpt of config.log is below.
What could be causing this? Is it a problem with ld, or with Cygwin?
Thanks,
Andrew
--
config.log
--
configure:5219: checking if struct winsize and TIOCGWINSZ exist
configure:5246: g++ -o conftest.exe -ggdb -O2 -pipe
-fdebug-prefix-map=/home/ASchulma/dev/cygwin/fish/fish-2.3b1-1.x86_64/build=/usr/src/debug/fish-2.3b1-1
-fdebug-prefix-map=/home/ASchulma/dev/cygwin/fish/fish-2.3b1-1.x86_64/src/fish-2.3b1=/usr/src/debug/fish-2.3b1-1
-D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 -fno-exceptions -Wall
-Wno-sign-compare conftest.cpp -lintl -lncurses >&5
conftest.cpp: In function 'int main()':
conftest.cpp:80:19: warning: statement has no effect [-Wunused-value]
TIOCGWINSZ;
^
conftest.cpp:79:24: warning: unused variable 'termsize' [-Wunused-variable]
struct winsize termsize = {0};
^
/usr/lib/gcc/x86_64-pc-cygwin/5.3.0/../../../../x86_64-pc-cygwin/bin/ld:
cannot open output file conftest.exe: Permission denied
collect2: error: ld returned 1 exit status
configure:5246: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "fish"
| #define PACKAGE_TARNAME "fish"
| #define PACKAGE_VERSION "2.3b1"
| #define PACKAGE_STRING "fish 2.3b1"
| #define PACKAGE_BUGREPORT "fish-us...@lists.sourceforge.net"
| #define PACKAGE_URL ""
| #define USE_GETTEXT 1
| #define HAVE__PROC_SELF_STAT 1
| #define HAVE_TRANSLATE_H 1
| #define NCURSES_NOMACROS 1
| #define NOMACROS 1
| #define HAVE_NAN 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_GETOPT_H 1
| #define HAVE_TERMIOS_H 1
| #define HAVE_SYS_RESOURCE_H 1
| #define HAVE_TERM_H 1
| #define HAVE_NCURSES_TERM_H 1
| #define HAVE_NCURSES_H 1
| #define HAVE_NCURSES_CURSES_H 1
| #define HAVE_CURSES_H 1
| #define HAVE_SYS_SELECT_H 1
| #define HAVE_SYS_IOCTL_H 1
| #define HAVE_SPAWN_H 1
| #define HAVE_LIBINTL_H 1
| #define SIZEOF_WCHAR_T 2
| #define WCHAR_T_BITS 16
| #define HAVE_STRUCT_STAT_ST_MTIM_TV_NSEC 1
| #define HAVE_DIRENT_H 1
| #define HAVE_STRUCT_DIRENT_D_TYPE 1
| #define HAVE_WCSDUP 1
| #define HAVE_WCSLEN 1
| #define HAVE_WCSCASECMP 1
| #define HAVE_WCSNCASECMP 1
| #define HAVE_FWPRINTF 1
| #define HAVE_FUTIMES 1
| #define HAVE_WCWIDTH 1
| #define HAVE_WCSWIDTH 1
| #define HAVE_WCSTOK 1
| #define HAVE_FPUTWC 1
| #define HAVE_FGETWC 1
| #define HAVE_WCSTOL 1
| #define HAVE_WCSLCAT 1
| #define HAVE_WCSLCPY 1
| #define HAVE_KILLPG 1
| #define HAVE_MKOSTEMP 1
| #define HAVE_SYSCONF 1
| #define HAVE_GETIFADDRS 1
| #define HAVE_FUTIMENS 1
| #define HAVE_CLOCK_GETTIME 1
| #define HAVE_GETTEXT 1
| #define HAVE_DCGETTEXT 1
| #define HAVE_REALPATH_NULL 1
| /* end confdefs.h. */
|
|
| #ifdef HAVE_TERMIOS_H
| #include
| #endif
|
| #ifdef HAVE_SYS_IOCTL_H
| #include
| #endif
|
| int
| main ()
| {
|
| struct winsize termsize = {0};
| TIOCGWINSZ;
|
|
| ;
| return 0;
| }
|
configure:5256: result: no
--
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: ld randomly assigns wrong user and group IDs to executable
> During configure, a particular c++ program compiles fine, but the generated > executable has the wrong user and group IDs and permissions, so the > configure test fails and my build fails. > > Here are the source files and generated executable: > > $ ls -l conftest* > -rw-r--r-- 1 ASchulma Domain Users 1911 Apr 22 13:11 conftest.cpp > -rw-r--r-- 1 ASchulma Domain Users466 Apr 22 13:11 conftest.err > -rwxr-x--- 1 Unknown+User Unknown+Group 62152 Apr 22 13:11 conftest.exe > > $ ls -ln conftest.exe > -rwxr-x--- 1 4294967295 4294967295 62152 Apr 22 13:11 conftest.exe > > Note the strange, apparently random user and group ID numbers for > conftest.exe. > > * This happens about half the time. The other half of the time, the user > and group IDs are mine and so the build succeeds. I haven't been able to > figure out when it will fail. > > * The user and group IDs are always the same, 4294967295, when the problem > happens. > > * It only happens with this one program - other tests in configure work > fine. > > * When I compile the program on my own, outside of configure, it builds > fine, two compiler warnings aside. A few more notes: * As Sergio Gomez points out, the ID 4294967295 isn't random but is 2^32-1. * Configure is now starting to fail on other tests, in exactly the same way: by generating an executable with those IDs that I then can't read, causing the test to fail. Again it seems to be random which test fails and when. -- 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
Cygwin website / docs
Hi folks, Is the website source for cygwin.com (including the documentation) in a public git repo? Thanks Brian -- 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
