[ITA] postgresql-9.2.2-1
following Reini's request: http://cygwin.com/ml/cygwin/2013-01/msg00134.html to download (remove the index.html's) : wget -r -np -nH --cut-dirs=1 \ http://matzeri.altervista.org/cygwin-1.7/postgresql/index.html find postgresql -name index.html -o -name md5.sum | xargs rm File list: libecpg-compat2/libecpg-compat2-9.2.2-1.tar.bz2 libecpg-compat2/setup.hint libecpg-devel/libecpg-devel-9.2.2-1.tar.bz2 libecpg-devel/setup.hint libecpg5/libecpg5-9.2.2-1.tar.bz2 libecpg5/setup.hint libpgtypes2/libpgtypes2-9.2.2-1.tar.bz2 libpgtypes2/setup.hint libpq-devel/libpq-devel-9.2.2-1.tar.bz2 libpq-devel/setup.hint libpq5/libpq5-9.2.2-1.tar.bz2 libpq5/setup.hint postgresql-9.2.2-1-src.tar.bz2 postgresql-9.2.2-1.tar.bz2 postgresql-client/postgresql-client-9.2.2-1.tar.bz2 postgresql-client/setup.hint postgresql-contrib/postgresql-contrib-9.2.2-1.tar.bz2 postgresql-contrib/setup.hint postgresql-debuginfo/postgresql-debuginfo-9.2.2-1.tar.bz2 postgresql-debuginfo/setup.hint postgresql-devel/postgresql-devel-9.2.2-1.tar.bz2 postgresql-devel/setup.hint postgresql-doc/postgresql-doc-9.2.2-1.tar.bz2 postgresql-doc/setup.hint postgresql-plperl/postgresql-plperl-9.2.2-1.tar.bz2 postgresql-plperl/setup.hint postgresql-plpython/postgresql-plpython-9.2.2-1.tar.bz2 postgresql-plpython/setup.hint setup.hint Of the 132 checks I see only 1) a failure on tsearch that looks like some strange character encoding difference. 2) a freeze on prepared_xacts that I skipped Regards Marco
Re: [ITA] postgresql-9.2.2-1
On Mon, Jan 14, 2013 at 12:40 AM, marco atzeri wrote: wget -r -np -nH --cut-dirs=1 \ http://matzeri.altervista.org/cygwin-1.7/postgresql/index.html /etc/rc.d/init.d/postgresql needs an +x, and the .exe in DAEMON is wrong ls -al /usr/sbin/postmaster /usr/sbin/postmaster - postgres.exe /usr/sbin/initdb -D /usr/share/postgresql/data required a rebaseall $ psql Segmentation fault (core dumped) 891446 [main] psql 960 fhandler_pipe::create: name \\.\pipe\cygwin-c5e39b7a9d22bafb-960-sigwait, size 164, mode PIPE_TYPE_MESSAGE 1021548 [main] psql 960 fhandler_pipe::create: pipe read handle 0x788 4501998 [main] psql 960 fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-c5e39b7a9d22bafb-960-sigwait 712069 [main] psql 960 fhandler_pipe::create: pipe write handle 0x784 652134 [main] psql 960 dll_crt0_0: finished dll_crt0_0 initialization 32675401 [sig] psql 960 wait_sig: entering ReadFile loop, my_readsig 0x788, my_sendsig 0x784 7756176 [main] psql 960 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\rurban, no-keep-rel, no-add-slash) 3436519 [main] psql 960 normalize_win32_path: C:\cygwin\home\rurban = normalize_win32_path (C:\cygwin\home\rurban) 756594 [main] psql 960 mount_info::conv_to_posix_path: /home/rurban = conv_to_posix_path (C:\cygwin\home\rurban) --- Process 960, exception C005 at F8D3 1526746 [main] psql 960 exception::handle: In cygwin_except_handler exception 0xC005 at 0xF8D3 sp 0x22AC7C 526798 [main] psql 960 exception::handle: In cygwin_except_handler signal 11 at 0xF8D3 3847182 [main] psql 960 exception::handle: In cygwin_except_handler calling 0x0 7237 [main] psql 960 exception::handle: Exception: STATUS_ACCESS_VIOLATION 557237 [main] psql 960 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1637400 [main] psql 960 try_to_debug: debugger_command '' 8116 [main] psql 960 open_stackdumpfile: Dumping stack trace to psql.exe.stackdump $ gdb psql Program received signal SIGSEGV, Segmentation fault. 0xf8d3 in ?? () (gdb) bt #0 0xf8d3 in ?? () #1 0x610fc95c in pthread::init_mainthread () at /usr/src/cygwin/src/winsup/cygwin/thread.cc:336 #2 0x61006cf5 in dll_crt0_1 () at /usr/src/cygwin/src/winsup/cygwin/dcrt0.cc:832 #3 0x6100533d in _cygtls::call2 (this=optimized out, func=0x61006c50 dll_crt0_1(void*), arg=0x0, buf=0x610054cb _cygtls::call(unsigned long (*)(void*, void*), void*)+91) at /usr/src/cygwin/src/winsup/cygwin/cygtls.cc:99 #4 0x0022ff78 in ?? () #5 0x004330c2 in ?? () #6 0x00401015 in ?? () #7 0x7c81776f in RegisterWaitForInputIdle () from /cygdrive/c/windows/system32/kernel32.dll #8 0x in ?? () Can we have a gold star please. BTW: We have a nice GNU extension find postgresql -name index.html -o -name md5.sum -delete I checked the md5 sums. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
Re: [ITA] postgresql-9.2.2-1
On 1/14/2013 10:28 PM, Reini Urban wrote: On Mon, Jan 14, 2013 at 12:40 AM, marco atzeri wrote: wget -r -np -nH --cut-dirs=1 \ http://matzeri.altervista.org/cygwin-1.7/postgresql/index.html /etc/rc.d/init.d/postgresql needs an +x, added and the .exe in DAEMON is wrong ls -al /usr/sbin/postmaster /usr/sbin/postmaster - postgres.exe What you mean, that postmaster need an exe as extention ? It seems a fault of cygport post install that strip the .exe from the postmaster.exe link. /usr/sbin/initdb -D /usr/share/postgresql/data required a rebaseall rebase is already part of setup post installation standard. However I noticed that during rebaseall there is a segfault in rebase /usr/lib/postgresql/dict_xsyn.dll: fixing bad relocations /usr/lib/postgresql/dict_xsyn.dll: new base = 5209, new size = 1 /usr/lib/postgresql/dict_snowball.dll: fixing bad relocations Segmentation fault (core dumped) And dict_snowball.dll (like dict_xsyn.dll on others) is one of the dll with link to the demon $ objdump -x /usr/lib/postgresql/dict_snowball.dll |grep DLL Name: DLL Name: postgres.exe DLL Name: cygwin1.dll DLL Name: KERNEL32.dll It seems similar on 8.x version $ psql Segmentation fault (core dumped) $ psql psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket /tmp/.s.PGSQL.5432? re-uploading just in case I uploaded the wrong build. 891446 [main] psql 960 fhandler_pipe::create: name \\.\pipe\cygwin-c5e39b7a9d22bafb-960-sigwait, size 164, mode PIPE_TYPE_MESSAGE 1021548 [main] psql 960 fhandler_pipe::create: pipe read handle 0x788 4501998 [main] psql 960 fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-c5e39b7a9d22bafb-960-sigwait 712069 [main] psql 960 fhandler_pipe::create: pipe write handle 0x784 652134 [main] psql 960 dll_crt0_0: finished dll_crt0_0 initialization 32675401 [sig] psql 960 wait_sig: entering ReadFile loop, my_readsig 0x788, my_sendsig 0x784 7756176 [main] psql 960 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\rurban, no-keep-rel, no-add-slash) 3436519 [main] psql 960 normalize_win32_path: C:\cygwin\home\rurban = normalize_win32_path (C:\cygwin\home\rurban) 756594 [main] psql 960 mount_info::conv_to_posix_path: /home/rurban = conv_to_posix_path (C:\cygwin\home\rurban) --- Process 960, exception C005 at F8D3 1526746 [main] psql 960 exception::handle: In cygwin_except_handler exception 0xC005 at 0xF8D3 sp 0x22AC7C 526798 [main] psql 960 exception::handle: In cygwin_except_handler signal 11 at 0xF8D3 3847182 [main] psql 960 exception::handle: In cygwin_except_handler calling 0x0 7237 [main] psql 960 exception::handle: Exception: STATUS_ACCESS_VIOLATION 557237 [main] psql 960 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1637400 [main] psql 960 try_to_debug: debugger_command '' 8116 [main] psql 960 open_stackdumpfile: Dumping stack trace to psql.exe.stackdump $ gdb psql Program received signal SIGSEGV, Segmentation fault. 0xf8d3 in ?? () (gdb) bt #0 0xf8d3 in ?? () #1 0x610fc95c in pthread::init_mainthread () at /usr/src/cygwin/src/winsup/cygwin/thread.cc:336 #2 0x61006cf5 in dll_crt0_1 () at /usr/src/cygwin/src/winsup/cygwin/dcrt0.cc:832 #3 0x6100533d in _cygtls::call2 (this=optimized out, func=0x61006c50 dll_crt0_1(void*), arg=0x0, buf=0x610054cb _cygtls::call(unsigned long (*)(void*, void*), void*)+91) at /usr/src/cygwin/src/winsup/cygwin/cygtls.cc:99 #4 0x0022ff78 in ?? () #5 0x004330c2 in ?? () #6 0x00401015 in ?? () #7 0x7c81776f in RegisterWaitForInputIdle () from /cygdrive/c/windows/system32/kernel32.dll #8 0x in ?? () Can we have a gold star please. wait until it is working
src/winsup/cygwin ChangeLog DevNotes exception ...
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2013-01-14 12:57:05 Modified files: winsup/cygwin : ChangeLog DevNotes exceptions.cc globals.cc pinfo.cc select.cc sigproc.cc sigproc.h sync.h Log message: Pull in changes from HEAD Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.5939.2.44r2=1.5939.2.45 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/DevNotes.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.20.2.3r2=1.20.2.4 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/exceptions.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.391.2.9r2=1.391.2.10 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/globals.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.40.2.4r2=1.40.2.5 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/pinfo.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.309.2.8r2=1.309.2.9 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/select.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.207.2.7r2=1.207.2.8 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/sigproc.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.388.2.8r2=1.388.2.9 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/sigproc.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.112.2.6r2=1.112.2.7 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/sync.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.41.2.2r2=1.41.2.3
src/winsup/cygwin/release 1.7.18
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2013-01-14 13:23:56 Modified files: winsup/cygwin/release: 1.7.18 Log message: Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/release/1.7.18.diff?cvsroot=srcr1=1.1r2=1.2
src/winsup/cygwin cygerrno.h fhandler.h fhandl ...
CVSROOT:/cvs/src Module name:src Branch: cygwin-64bit-branch Changes by: cori...@sourceware.org 2013-01-14 17:16:31 Modified files: winsup/cygwin : cygerrno.h fhandler.h fhandler_console.cc path.h pinfo.cc sync.h Log message: Fix copyrights Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygerrno.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.21.2.1r2=1.21.2.2 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.473.2.9r2=1.473.2.10 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_console.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.275.2.5r2=1.275.2.6 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.171.2.6r2=1.171.2.7 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/pinfo.cc.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.309.2.9r2=1.309.2.10 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/sync.h.diff?cvsroot=srconly_with_tag=cygwin-64bit-branchr1=1.41.2.3r2=1.41.2.4
winsup/cygwin DevNotes
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2013-01-14 18:10:29 Modified files: cygwin : DevNotes Log message: fix typo Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/DevNotes.diff?cvsroot=uberbaumr1=1.27r2=1.28
winsup/cygwin ChangeLog include/pthread.h
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2013-01-14 21:17:37 Modified files: cygwin : ChangeLog cygwin/include : pthread.h Log message: * include/pthread.h (pthread_exit): Mark as noreturn. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.6036r2=1.6037 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/include/pthread.h.diff?cvsroot=uberbaumr1=1.36r2=1.37
winsup/cygwin ChangeLog
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2013-01-14 22:24:38 Modified files: cygwin : ChangeLog Log message: fix typo Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.6037r2=1.6038
Re: stat() and tilde prefix (was bad bash tab completion)
On Jan 14 01:17, Christopher Faylor wrote: On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote: In investigating this, I believe the issue I am having is due to how stat() handles tilde prefixed paths. On linux we see: linux$ $ python -c 'import os; print os.stat(~/..)' Traceback (most recent call last): File string, line 1, in module OSError: [Errno 2] No such file or directory: '~/..' and on cygwin we see: cygwin$ python -c 'import os; print os.stat(~/..)' posix.stat_result(st_mode=16832, st_ino=562949953496729L, st_dev=4174909669L, st_nlink=1, st_uid=42037, st_gid=10513, st_size=0L, st_atime=1357616166, st_mtime=1357616166, st_ctime=1357616166) It is a bug. It's not just ~. Any nonexistent directory will work, like foo/... And it's a bug which isn't easily fixed. Since about the dawn of time, Cygwin's core path handling evaluates the path in a non-POSIX manner, mainly for performance reasons. POSIX demands to evaluate a path from left to right (thus tripping over the non-existant ~ or foo directory). Windows OTOH skips testing all parent directories of a path, and while this can be changed(*), it's the default setting since the earliest Windows NT versions. So, since Cygwin can't rely on the OS to this job when it has to convert a POSIX path to a Windows path internally, Cygwin would have to check the existence of every single path component from left to right to emulate the POSIX requirements. But that would be a big performance hit, so Cygwin's path handling code tries to be clever to avoid having to call too many OS functions: The first step of converting a POSIX path to a Windows path is to normalize the path. . and .. components are simply dropped: a/b/./c - a\b\c a/b/../c - a\c Then the path prefix is replaced by the matching mount point. Eventually it evaluates the path from right to left. Consider a valid, normalized path with 10 components. Under POSIX rules this requires 10 checks for existence. No problem for the Linux kernel since it has everything under control anyway and the test is blazingly fast. But Cygwin is not the OS so it has to call the necessary OS functions 10 times. By checking from right to left, Cygwin has to call the OS functions only once, if the file exists, two times if the file does not exist, but its parent dir exists, and so on. On top of that, the entire chore has to restart when tripping over a symbolic link. Since the predominant number of file operations are performed on existing paths, or at least paths for which the parent dir exists, Cygwin reduces the number of OS operations to convert a POSIX to a Windows path. The price we're paying is this very deviation from the POSIX standard. Corinna (*) User right Bypass Traverse Checking, by default enabled for everyone. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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: Another issue with CLANG
Il 13/01/2013 16.20, Jon TURNEY ha scritto:
On 13/01/2013 14:44, Angelo Graziosi wrote:
Il 13/01/2013 15.31, Jon TURNEY ha scritto:
On 11/01/2013 12:54, Angelo Graziosi wrote:
An application which need to be built with clang++, fails to build when it
includes glx.h and indirectly windows.h headers like in the test case shown
below.
In short, X11/Xlib.h define Status as a macro (an alias for int) instead
rpcdce.h uses Status a a pointer variable name...
I don't think there's anything clang-specific about this problem. The same
issue can be seen with gcc.
If your application needs both Xlib and Win32 interfaces, you should include
X11/Xwindows.h rather than windows.h, which wraps any conflicting
declarations.
(xcb uses a sensible namespace, so this is not necessary for applications
which use xcb and Win32.)
You probably need the latest upstream x11proto (not yet packaged for cygwin)
for this wrapping to work correctly with the mingw-w64 w32api headers [1]
Alternatively you can work around this yourself e.g. as in [2]
Thanks Jon, foo.cxx was anly a test case to reproduce the errors. In the true
application those headers were included indirectly... :-(
In file included from input_line_87:1:
In file included from include/TX11GL.h:29:
In file included from /usr/include/GL/glx.h:45:
In file included from /usr/include/w32api/GL/gl.h:13:
This looks very wrong, mixing native and X GL headers isn't going to work.
Assuming you mean to build an X application, this should be finding
/usr/include/GL/gl.h, so maybe an include path issue?
For the record...
ROOT guys have fixed this issue with the following patch to their
patched version of llvm/clang:
$ cat InitHeaderSearch.cpp.diff
---
ROOT/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp
2013-01-01 11:50:05.0 +0100
+++
root_trunk/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp
2013-01-14 12:10:43.90625 +0100
@@ -305,7 +305,8 @@
case llvm::Triple::RTEMS:
break;
case llvm::Triple::Cygwin:
-AddPath(/usr/include/w32api, System, true, false, false);
+// The headers in w32api/ are not cygwin-compatible (but native)
+//AddPath(/usr/include/w32api, System, true, false, false);
break;
case llvm::Triple::MinGW32: {
// mingw-w64 crt include paths
Ciao,
Angelo.
In file included from /usr/include/w32api/windows.h:88:
In file included from /usr/include/w32api/rpc.h:70:
/usr/include/w32api/rpcdce.h:142:88: error: expected ')'
typedef void __RPC_API RPC_OBJECT_INQ_FN(UUID *ObjectUuid,UUID
*TypeUuid,RPC_STATUS *Status);
--
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
RES: hiding cursor on text terminals
Am 07.01.2013 19:24, schrieb Damian Rodriguez Sanchez: Hello list, I have compiled a Linux ncurses gcc application on Cygwin. Everything works fine except for curs_set(0) calls which do not hide the cursor on text mode terminals (they work on X though). Does anybody know of a way to achieve this, even if it's not a portable solution? The feature has been added to the cygwin console for the next release. Thomas Nice, so I see you guys aren't so mean after all. Damian. Pelo quarto ano consecutivo, a Itautec é a empresa latino-americana melhor posicionada no ranking Fintech 100 que lista as maiores fornecedoras globais de TI para o setor financeiro. Saiba mais: www.itautec.com.br --- 0 -- 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: RES: hiding cursor on text terminals
On Jan 14 10:37, Damian Rodriguez Sanchez wrote: Am 07.01.2013 19:24, schrieb Damian Rodriguez Sanchez: Hello list, I have compiled a Linux ncurses gcc application on Cygwin. Everything works fine except for curs_set(0) calls which do not hide the cursor on text mode terminals (they work on X though). Does anybody know of a way to achieve this, even if it's not a portable solution? The feature has been added to the cygwin console for the next release. Thomas Nice, so I see you guys aren't so mean after all. What's that? Are you trying to undermine our bad reputation? ;) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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: Another issue with CLANG
On 14/01/2013 11:47, Angelo Graziosi wrote: Il 13/01/2013 16.20, Jon TURNEY ha scritto: On 13/01/2013 14:44, Angelo Graziosi wrote: Il 13/01/2013 15.31, Jon TURNEY ha scritto: On 11/01/2013 12:54, Angelo Graziosi wrote: An application which need to be built with clang++, fails to build when it includes glx.h and indirectly windows.h headers like in the test case shown below. In short, X11/Xlib.h define Status as a macro (an alias for int) instead rpcdce.h uses Status a a pointer variable name... I don't think there's anything clang-specific about this problem. The same issue can be seen with gcc. If your application needs both Xlib and Win32 interfaces, you should include X11/Xwindows.h rather than windows.h, which wraps any conflicting declarations. (xcb uses a sensible namespace, so this is not necessary for applications which use xcb and Win32.) You probably need the latest upstream x11proto (not yet packaged for cygwin) for this wrapping to work correctly with the mingw-w64 w32api headers [1] Alternatively you can work around this yourself e.g. as in [2] Thanks Jon, foo.cxx was anly a test case to reproduce the errors. In the true application those headers were included indirectly... :-( In file included from input_line_87:1: In file included from include/TX11GL.h:29: In file included from /usr/include/GL/glx.h:45: In file included from /usr/include/w32api/GL/gl.h:13: This looks very wrong, mixing native and X GL headers isn't going to work. Assuming you mean to build an X application, this should be finding /usr/include/GL/gl.h, so maybe an include path issue? For the record... ROOT guys have fixed this issue with the following patch to their patched version of llvm/clang: $ cat InitHeaderSearch.cpp.diff --- ROOT/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp 2013-01-01 11:50:05.0 +0100 +++ root_trunk/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp 2013-01-14 12:10:43.90625 +0100 @@ -305,7 +305,8 @@ case llvm::Triple::RTEMS: break; case llvm::Triple::Cygwin: -AddPath(/usr/include/w32api, System, true, false, false); +// The headers in w32api/ are not cygwin-compatible (but native) +//AddPath(/usr/include/w32api, System, true, false, false); Well, ok. But this comment is almost completely wrong. cygwin clang has /usr/include/w32api in the default include path (try compiling your test program with clang -v), and since it appears *after* /usr/include, including glx.h works correctly. I have no idea what the right way to solve this problem is. -- 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: Rebuilding make
On 14.01.2013 10:19, Christopher Faylor wrote: Calm down and READ the message you received. It surely didn't tell you to send implied profanity to the Cygwin mailing list. Sorry, i don't really understand you. What do you mean under profanity ? Is it not allowed to post patches here ? -- Kind regards Pavel Fedin Expert engineer, Samsung Moscow research center -- 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: stat() and tilde prefix (was bad bash tab completion)
Hi,
On 14/01/13 21:00, Corinna Vinschen wrote:
On Jan 14 01:17, Christopher Faylor wrote:
On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote:
In investigating this, I believe the issue I am having is due to how
stat() handles tilde prefixed paths. On linux we see:
linux$ $ python -c 'import os; print os.stat(~/..)'
Traceback (most recent call last):
File string, line 1, inmodule
OSError: [Errno 2] No such file or directory: '~/..'
and on cygwin we see:
cygwin$ python -c 'import os; print os.stat(~/..)'
posix.stat_result(st_mode=16832, st_ino=562949953496729L,
st_dev=4174909669L, st_nlink=1, st_uid=42037, st_gid=10513, st_size=0L,
st_atime=1357616166, st_mtime=1357616166, st_ctime=1357616166)
It is a bug. It's not just ~. Any nonexistent directory will
work, like foo/...
And it's a bug which isn't easily fixed. Since about the dawn of time,
Cygwin's core path handling evaluates the path in a non-POSIX manner,
mainly for performance reasons.
Thank you both for your explanations. If my understanding is correct,
stat() will be returning for the current working directory.
It seems to me then that a patch to bash may be in order? I can see how
the bash check is the right thing to do. It doesn't want the special
tilde expansion to mask and disallow referencing of real tilde prefixed
paths. So the stat() check is the quick win to determine that.
From what I make of it, there needs to be a patch that, although can
work generically, adds checks only required for Cygwin. And therefore
is specific to the Cygwin package.
The check would be an extension of the file_exists() function, perhaps
called tilde_file_exists(), which determines if the tilde prefix forms
a directory component of the path (strchr('/')?). If it does not, the
file_exists() check is sufficient. If it does, then the check of if
that directory exists is logically and'ed to the result of
file_exists().
Does that sound about right?
--
Regards,
Shaddy
--
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: Rebuilding make
On 14.01.2013 10:19, Christopher Faylor wrote: On Mon, Jan 14, 2013 at 01:19:54AM -0500, Christopher Faylor wrote: On Mon, Jan 14, 2013 at 10:12:12AM +0400, Fedin Pavel wrote: On 10.01.2013 23:47, Reini Urban wrote: Great! Can you gist the patches somewhere please? I tried to post patches from my home email address. But messages get rejected as spam. WTF ??? Calm down and READ the message you received. It surely didn't tell you to send implied profanity to the Cygwin mailing list. Sorry, i don't really understand you. What do you mean under profanity ? Is it not allowed to post patches here ? I was referring to your WTF ???. I didn't say anything about not posting patches. Of course you can post patches. You apparently knew that your mail was rejected as spam because you received a bounce. The bounce gave you information which did not tell you to send a complaint here. -- 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: Rebuilding make
Fedin Pavel wrote: On 14.01.2013 10:19, Christopher Faylor wrote: Calm down and READ the message you received. It surely didn't tell you to send implied profanity to the Cygwin mailing list. Sorry, i don't really understand you. What do you mean under profanity ? Is it not allowed to post patches here ? WTF is implied profanity. cgf's point was that rather than complaining that your message was rejected, you'd have better luck reading the rejection email and follow the instructions there. -- Adam Dinwoodie Messages posted to this list are made in a personal capacity. -- 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: RES: hiding cursor on text terminals
On Mon, Jan 14, 2013 at 02:26:14PM +0100, Corinna Vinschen wrote: On Jan 14 10:37, Damian Rodriguez Sanchez wrote: ???Am 07.01.2013 19:24, schrieb Damian Rodriguez Sanchez: Hello list, I have compiled a Linux ncurses gcc application on Cygwin. Everything works fine except for curs_set(0) calls which do not hide the cursor on text mode terminals (they work on X though). Does anybody know of a way to achieve this, even if it's not a portable solution? The feature has been added to the cygwin console for the next release. Thomas Nice, so I see you guys aren't so mean after all. What's that? Are you trying to undermine our bad reputation? Well, just for that, how about if we don't release 1.7.18 until February at the latest? That will show everyone. cgf -- 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: stat() and tilde prefix (was bad bash tab completion)
On Mon, Jan 14, 2013 at 11:00:02AM +0100, Corinna Vinschen wrote: On Jan 14 01:17, Christopher Faylor wrote: On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote: In investigating this, I believe the issue I am having is due to how stat() handles tilde prefixed paths. On linux we see: linux$ $ python -c 'import os; print os.stat(~/..)' Traceback (most recent call last): File string, line 1, in module OSError: [Errno 2] No such file or directory: '~/..' and on cygwin we see: cygwin$ python -c 'import os; print os.stat(~/..)' posix.stat_result(st_mode=16832, st_ino=562949953496729L, st_dev=4174909669L, st_nlink=1, st_uid=42037, st_gid=10513, st_size=0L, st_atime=1357616166, st_mtime=1357616166, st_ctime=1357616166) It is a bug. It's not just ~. Any nonexistent directory will work, like foo/... And it's a bug which isn't easily fixed. Since about the dawn of time, Cygwin's core path handling evaluates the path in a non-POSIX manner, mainly for performance reasons. POSIX demands to evaluate a path from left to right (thus tripping over the non-existant ~ or foo directory). Windows OTOH skips testing all parent directories of a path, and while this can be changed(*), it's the default setting since the earliest Windows NT versions. So, since Cygwin can't rely on the OS to this job when it has to convert a POSIX path to a Windows path internally, Cygwin would have to check the existence of every single path component from left to right to emulate the POSIX requirements. But that would be a big performance hit, so Cygwin's path handling code tries to be clever to avoid having to call too many OS functions: The first step of converting a POSIX path to a Windows path is to normalize the path. . and .. components are simply dropped: a/b/./c - a\b\c a/b/../c - a\c Then the path prefix is replaced by the matching mount point. Eventually it evaluates the path from right to left. Consider a valid, normalized path with 10 components. Under POSIX rules this requires 10 checks for existence. No problem for the Linux kernel since it has everything under control anyway and the test is blazingly fast. But Cygwin is not the OS so it has to call the necessary OS functions 10 times. By checking from right to left, Cygwin has to call the OS functions only once, if the file exists, two times if the file does not exist, but its parent dir exists, and so on. On top of that, the entire chore has to restart when tripping over a symbolic link. Since the predominant number of file operations are performed on existing paths, or at least paths for which the parent dir exists, Cygwin reduces the number of OS operations to convert a POSIX to a Windows path. The price we're paying is this very deviation from the POSIX standard. Also: c:\dir foo\bar\..\.. Volume in drive S is share Serial number is e620:3c3d Directory of S:\* 1/11/2013 9:58 DIR. 12/26/2012 21:34 DIR.. 1/12/2013 16:27 DIRbin 1/14/2013 10:20 DIRcgf ... I don't have a foo directory but cmd was happy to just ignore that fact and show my the root directory. This is YA place where Windows and Linux differ drastically. cgf -- 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: stat() and tilde prefix (was bad bash tab completion)
On Jan 14 10:27, Christopher Faylor wrote: On Mon, Jan 14, 2013 at 11:00:02AM +0100, Corinna Vinschen wrote: The first step of converting a POSIX path to a Windows path is to normalize the path. . and .. components are simply dropped: a/b/./c - a\b\c a/b/../c - a\c [...] Also: c:\dir foo\bar\..\.. Volume in drive S is share Serial number is e620:3c3d Directory of S:\* 1/11/2013 9:58 DIR. 12/26/2012 21:34 DIR.. 1/12/2013 16:27 DIRbin 1/14/2013 10:20 DIRcgf ... I don't have a foo directory but cmd was happy to just ignore that fact and show my the root directory. This is YA place where Windows and Linux differ drastically. Indeed. Before writing my mail I tested the GetFullPathName function, and I was not exactly surprised to find that it behaves as you describe for CMD. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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: stat() and tilde prefix (was bad bash tab completion)
On Jan 15 01:36, Shaddy Baddah wrote:
Hi,
On 14/01/13 21:00, Corinna Vinschen wrote:
On Jan 14 01:17, Christopher Faylor wrote:
On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote:
In investigating this, I believe the issue I am having is due to how
stat() handles tilde prefixed paths. On linux we see:
linux$ $ python -c 'import os; print os.stat(~/..)'
Traceback (most recent call last):
File string, line 1, inmodule
OSError: [Errno 2] No such file or directory: '~/..'
and on cygwin we see:
cygwin$ python -c 'import os; print os.stat(~/..)'
posix.stat_result(st_mode=16832, st_ino=562949953496729L,
st_dev=4174909669L, st_nlink=1, st_uid=42037, st_gid=10513, st_size=0L,
st_atime=1357616166, st_mtime=1357616166, st_ctime=1357616166)
It is a bug. It's not just ~. Any nonexistent directory will
work, like foo/...
And it's a bug which isn't easily fixed. Since about the dawn of time,
Cygwin's core path handling evaluates the path in a non-POSIX manner,
mainly for performance reasons.
Thank you both for your explanations. If my understanding is correct,
stat() will be returning for the current working directory.
In the above case, yes.
It seems to me then that a patch to bash may be in order? I can see how
the bash check is the right thing to do. It doesn't want the special
tilde expansion to mask and disallow referencing of real tilde prefixed
paths. So the stat() check is the quick win to determine that.
From what I make of it, there needs to be a patch that, although can
work generically, adds checks only required for Cygwin. And therefore
is specific to the Cygwin package.
The check would be an extension of the file_exists() function, perhaps
called tilde_file_exists(), which determines if the tilde prefix forms
a directory component of the path (strchr('/')?). If it does not, the
file_exists() check is sufficient. If it does, then the check of if
that directory exists is logically and'ed to the result of
file_exists().
Does that sound about right?
A check like this might be a good idea. Ultimately I would be glad to
be able to come up with more correct code in Cygwin while not getting
slower, of course. But that's wishful thinking for now.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader 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: stat() and tilde prefix (was bad bash tab completion)
On Mon, Jan 14, 2013 at 05:04:17PM +0100, Corinna Vinschen wrote: On Jan 14 10:27, Christopher Faylor wrote: On Mon, Jan 14, 2013 at 11:00:02AM +0100, Corinna Vinschen wrote: The first step of converting a POSIX path to a Windows path is to normalize the path. . and .. components are simply dropped: a/b/./c - a\b\c a/b/../c - a\c [...] Also: c:\dir foo\bar\..\.. Volume in drive S is share Serial number is e620:3c3d Directory of S:\* 1/11/2013 9:58 DIR. 12/26/2012 21:34 DIR.. 1/12/2013 16:27 DIRbin 1/14/2013 10:20 DIRcgf ... I don't have a foo directory but cmd was happy to just ignore that fact and show my the root directory. This is YA place where Windows and Linux differ drastically. Indeed. Before writing my mail I tested the GetFullPathName function, and I was not exactly surprised to find that it behaves as you describe for CMD. Right. It's not just CMD. A standard windows program will behave similarly. cgf -- 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: Rebuilding make
Hello, Christopher. 14 января 2013 г., 18:17:33, you wrote: You apparently knew that your mail was rejected as spam because you received a bounce. The bounce gave you information which did not tell you to send a complaint here. Ah, sorry for being impolite... I asked only because there was no meaningful or useful information in the bounce message. It had only one line: Spam score is too high. Well, does not matter any more. -- Kind regards, Pavel mailto:pavel_fe...@mail.ru -- 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: RES: hiding cursor on text terminals
On Jan 14 10:20, Christopher Faylor wrote: On Mon, Jan 14, 2013 at 02:26:14PM +0100, Corinna Vinschen wrote: On Jan 14 10:37, Damian Rodriguez Sanchez wrote: ???Am 07.01.2013 19:24, schrieb Damian Rodriguez Sanchez: Hello list, I have compiled a Linux ncurses gcc application on Cygwin. Everything works fine except for curs_set(0) calls which do not hide the cursor on text mode terminals (they work on X though). Does anybody know of a way to achieve this, even if it's not a portable solution? The feature has been added to the cygwin console for the next release. Thomas Nice, so I see you guys aren't so mean after all. What's that? Are you trying to undermine our bad reputation? Well, just for that, how about if we don't release 1.7.18 until February at the latest? That will show everyone. The particulary mean part here is that you neglected to mention the year ;) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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: RES: hiding cursor on text terminals
On Mon, Jan 14, 2013 at 07:31:19PM +0100, Corinna Vinschen wrote: On Jan 14 10:20, Christopher Faylor wrote: On Mon, Jan 14, 2013 at 02:26:14PM +0100, Corinna Vinschen wrote: On Jan 14 10:37, Damian Rodriguez Sanchez wrote: ???Am 07.01.2013 19:24, schrieb Damian Rodriguez Sanchez: Hello list, I have compiled a Linux ncurses gcc application on Cygwin. Everything works fine except for curs_set(0) calls which do not hide the cursor on text mode terminals (they work on X though). Does anybody know of a way to achieve this, even if it's not a portable solution? The feature has been added to the cygwin console for the next release. Thomas Nice, so I see you guys aren't so mean after all. What's that? Are you trying to undermine our bad reputation? Well, just for that, how about if we don't release 1.7.18 until February at the latest? That will show everyone. The particulary mean part here is that you neglected to mention the year ;) Bwahaha. cgf -- 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: stat() and tilde prefix (was bad bash tab completion)
On Jan 14 01:17, Christopher Faylor wrote: It is a bug. It's not just ~. Any nonexistent directory will work, like foo/... Corinna wrote: And it's a bug which isn't easily fixed. Since about the dawn of time, Cygwin's core path handling evaluates the path in a non-POSIX manner, mainly for performance reasons. and: Cygwin would have to check the existence of every single path component from left to right to emulate the POSIX requirements. and: The first step of converting a POSIX path to a Windows path is to normalize the path. . and .. components are simply dropped: a/b/./c - a\b\c a/b/../c - a\c Then the path prefix is replaced by the matching mount point. and: Ultimately I would be glad to be able to come up with more correct code in Cygwin while not getting slower, of course. But that's wishful thinking for now. Perhaps (as you may well have already considered): - replace the path prefix by the mount point first? (this may be naïve on my part, but it's not clear to me that .. early in a path should be able to influence which mount point is substituted) - test directory existence of the component preceding .. before collapsing (in the example above) b/.. to nothing. - trust that for a/b3/b2/b/../../../c, the existence test of a/b3/b2/b before collapsing b/.. to nothing implies existence of b2 and b3 so no further tests are needed for 'runs' of .. components with enough components before them Understood that this is still going to cause a slowdown because paths with .. are not uncommon, but it would reduce the number of additional existence checks from one-per-path-component to one-per-run-of-.., which means none in the case of paths without .. in them. stephan();
adding noreturn attribute to pthread_exit
Hi, Calling pthread_exit() at the end of a routine marked noreturn produces a compiler warning/error on cygwin: error: 'noreturn' function does return Is it possible to add the attribute to the cygwin pthread.h: --- pthread.h.orig 2012-10-19 14:40:13.0 +0200 +++ pthread.h 2013-01-14 21:40:00.018198900 +0100 @@ -137,7 +137,7 @@ void *(*)(void *), void *); int pthread_detach (pthread_t); int pthread_equal (pthread_t, pthread_t); -void pthread_exit (void *); +void pthread_exit (void *) __attribute__((__noreturn__)); int pthread_getcpuclockid (pthread_t, clockid_t *); int pthread_getschedparam (pthread_t, int *, struct sched_param *); void *pthread_getspecific (pthread_key_t); (note, i didn't check how it needs to trickle down in the cygwin implementation of pthread_exit()) - antti -- 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: adding noreturn attribute to pthread_exit
On Mon, Jan 14, 2013 at 09:55:38PM +0100, Antti Kantee wrote: Hi, Calling pthread_exit() at the end of a routine marked noreturn produces a compiler warning/error on cygwin: error: 'noreturn' function does return Is it possible to add the attribute to the cygwin pthread.h: --- pthread.h.orig 2012-10-19 14:40:13.0 +0200 +++ pthread.h 2013-01-14 21:40:00.018198900 +0100 @@ -137,7 +137,7 @@ void *(*)(void *), void *); int pthread_detach (pthread_t); int pthread_equal (pthread_t, pthread_t); -void pthread_exit (void *); +void pthread_exit (void *) __attribute__((__noreturn__)); int pthread_getcpuclockid (pthread_t, clockid_t *); int pthread_getschedparam (pthread_t, int *, struct sched_param *); void *pthread_getspecific (pthread_key_t); I added a ChangeLog entry and checked this in. Thanks for the patch. cgf -- 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: stat() and tilde prefix (was bad bash tab completion)
On 14/01/2013 3:24 PM, Stephan Mueller wrote: Perhaps (as you may well have already considered): - replace the path prefix by the mount point first? (this may be naïve on my part, but it's not clear to me that .. early in a path should be able to influence which mount point is substituted) If I mount something at /foo/bar/baz, then /foo/bar/baz/../../blah definitely shouldn't end up inside baz. - test directory existence of the component preceding .. before collapsing (in the example above) b/.. to nothing. - trust that for a/b3/b2/b/../../../c, the existence test of a/b3/b2/b before collapsing b/.. to nothing implies existence of b2 and b3 so no further tests are needed for 'runs' of .. components with enough components before them Understood that this is still going to cause a slowdown because paths with .. are not uncommon, but it would reduce the number of additional existence checks from one-per-path-component to one-per-run-of-.., which means none in the case of paths without .. in them. The rest seems totally reasonable to me, FWIW. I wouldn't put it past a Makefile (esp. one generated by autotools) or a gcc header search path to generate paths like: /a/b/c/d/../e/../f/../../../g/h (which resolves to a/g/h, if I counted dots correctly). Even then, though, it's only three checks to achieve posix-compliant behavior. Ryan -- 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: stat() and tilde prefix (was bad bash tab completion)
Am 14.01.2013 11:00, schrieb Corinna Vinschen: ... The first step of converting a POSIX path to a Windows path is to normalize the path. . and .. components are simply dropped: a/b/./c - a\b\c a/b/../c - a\c which isn't correct already (even if everything exists) because if b is a symbolic link, b/.. is *not* . - (I think I came across this bug a few times already without really noticing it as a bug, having taken it as some spurious glitch...) (Not sure whether this case is covered by further arguments in this thread) -- 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: Ctrl-C not working in snapshot
Am 13.01.2013 18:58, schrieb Thomas Wolff: When I tried the recent snapshot (2013-01-11) it turned out that Ctrl-C does not work anymore to interrupt a JVM program. There had been a similar discussion last year (http://cygwin.com/ml/cygwin/2012-07/msg00185.html) but it does not seem to be the same problem; in contrast to previous symptoms (http://cygwin.com/ml/cygwin/2012-08/msg00062.html), this time it fails in mintty but still works in the cygwin console. Also, it still worked for me with the 1.7.17 release. Bug gone with today's snapshot (*2013-01-14*). As I don't see in ChangeLog what might have fixed it, I checked further and it appeared with *2013-01-02.* At the same time, with an interactive Windows program (actually, the Scala interpreter), unlike Ctrl-C, Ctrl-D now works to terminate it, which it did not in the 1.7.17 release. Have to withdraw this. -- 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: Another issue with CLANG
On Mon, 14 Jan 2013 13:43:26 +, Jon TURNEY wrote: On 14/01/2013 11:47, Angelo Graziosi wrote: For the record... ROOT guys have fixed this issue with the following patch to their patched version of llvm/clang: $ cat InitHeaderSearch.cpp.diff --- ROOT/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp 2013-01-01 11:50:05.0 +0100 +++ root_trunk/interpreter/llvm/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp 2013-01-14 12:10:43.90625 +0100 @@ -305,7 +305,8 @@ case llvm::Triple::RTEMS: break; case llvm::Triple::Cygwin: -AddPath(/usr/include/w32api, System, true, false, false); +// The headers in w32api/ are not cygwin-compatible (but native) +//AddPath(/usr/include/w32api, System, true, false, false); Well, ok. But this comment is almost completely wrong. cygwin clang has /usr/include/w32api in the default include path (try compiling your test program with clang -v), and since it appears *after* /usr/include, including glx.h works correctly. I have no idea what the right way to solve this problem is. http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/llvm;a=blob;f=3.1-cygwin-includes.patch;h=1444765;hb=HEAD 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
deadlock with busy waiting on sigfe
Caused by executing following command and ctrl+c to interrupt in bash shell. sh -c cd /tmp/openjpeg/src/bin/jp2 /usr/bin/i686-pc-mingw32-gcc.exe -DOPJ_EXPORTS -ffast-math -O3 -DNDEBUG @CMakeFiles/opj_compress.dir/includes_C.rsp -o CMakeFiles/opj_compress.dir/convert.c.obj -c /tmp/openjpeg/src/bin/jp2/convert.c SleepEx is being spammed across threads. some thread got tls lock but didn't released it. how can i fix the problem? (gdb) thread apply all bt Thread 3 (Thread 8576.0x1b30): #0 0x571ec771 in filename_completion_function () from /usr/bin/cygreadline7.dll #1 0x7c958f81 in ntdll!LdrShutdownThread () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x571ec3c0 in filename_completion_function () from /usr/bin/cygreadline7.dll #3 0x7c97fc9b in ntdll!RtlExitUserThread () from /cygdrive/c/WINDOWS/system32/ntdll.dll #4 0x7c97fc73 in ntdll!DbgUiRemoteBreakin () from /cygdrive/c/WINDOWS/system32/ntdll.dll #5 0x in ?? () Thread 2 (Thread 8576.0xe38): #0 0x7c801e8c in SleepEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll #1 0x610873f2 in yield () at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/miscfuncs.cc:251 #2 0x610d6da4 in _cygtls::lock() () from /usr/bin/cygwin1.dll #3 0x6103035e in sigpacket::setup_handler (this=0xc3ac34, handler=0x6102fdb0 signal_exit(int, siginfo_t*), siga=..., tls=0x22ce64) at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/exceptions.cc:797 #4 0x610319bb in sigpacket::process (this=0xc3ac34) at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/exceptions.cc:1278 ---Type return to continue, or q return to quit--- #5 0x610dd38c in wait_sig () at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/sigproc.cc:1415 #6 0x61003ea5 in cygthread::callfunc (this=0x6118b400 threads, issimplestub=optimized out) at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/cygthread.cc:51 #7 0x6100442f in cygthread::stub (arg=0x6118b400 threads) at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/cygthread.cc:93 #8 0x6100538d in _cygtls::call2 (this=optimized out, func=0x610043e0 _ZN9cygthread4stubEPv@4, arg=0x6118b400 threads, buf=0x6100551b _cygtls::call(unsigned long (*)(void*, void*), void*)+91) at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/cygtls.cc:99 #9 0x00c3ffb8 in ?? () #10 0x7c82484f in KERNEL32!GetModuleHandleA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #11 0x in ?? () Thread 1 (Thread 8576.0x27b8): #0 0x7c801e8d in SleepEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll #1 0x610873f2 in yield () at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/miscfuncs.cc:251 #2 0x610d6c8c in _sigfe () from /usr/bin/cygwin1.dll #3 0x61103990 in pthread_kill () at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/thread.cc:3024 #4 0x610075fa in _cygwin_exit_return () ---Type return to continue, or q return to quit--- at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/dcrt0.cc:978 #5 0x6100538d in _cygtls::call2 (this=optimized out, func=0x61006bf0 dll_crt0_1(void*), arg=0x0, buf=0x6100551b _cygtls::call(unsigned long (*)(void*, void*), void*)+91) at /netrel/src/cygwin-snapshot-20130107-1/winsup/cygwin/cygtls.cc:99 #6 0x0022ff78 in ?? () #7 0x00465672 in ?? () #8 0x00401033 in ?? () #9 0x7c82f243 in ProcessIdToSessionId () from /cygdrive/c/WINDOWS/system32/kernel32.dll #10 0x in ?? () -- Regards. -- 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
