Re: Building setup.exe: conflicting declarations of ssize_t
On Sat, Sep 03, 2011 at 10:19:57PM -0400, Ken Brown wrote: Building setup.exe fails as follows: depbase=`echo archive.o | sed 's|[^/]*$|.deps/|;s|\.o$||'`;\ i686-pc-mingw32-g++ -DPACKAGE_NAME=\setup\ -DPACKAGE_TARNAME=\setup\ -DPACKAGE_VERSION=\0\ -DPACKAGE_STRING=\setup\ 0\ -DPACKAGE_BUGREPORT=\xxx\ -DPACKAGE_URL=\\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DLT_OBJDIR=\.libs/\ -DHAVE_LIBMINGW32=1 -DHAVE_ERRNO_H=1 -DHAVE_STRING=1 -DHAVE_STRING_H=1 -I. -DLZMA_API_STATIC -I./libgetopt++/include -Werror -Wall -Wno-uninitialized -Wpointer-arith -Wcomments -Wcast-align -Wwrite-strings -g -O2 -MT archive.o -MD -MP -MF $depbase.Tpo -c -o archive.o archive.cc \ mv -f $depbase.Tpo $depbase.Po In file included from archive.cc:26:0: io_stream.h:37:21: error: conflicting declaration ??typedef long int ssize_t?? /usr/i686-pc-mingw32/sys-root/mingw/include/sys/types.h:118:18: error: ??ssize_t?? has a previous declaration as ??typedef _ssize_t ssize_t?? The conflicting declarations result from the following recent change to the mingw-runtime package: 2011-08-19 Chris Sutcliffe xxx * include/sys/types.h (ssize_t): Defined as int as opposed to long. The following patch enables the build to complete, but I don't know if it's the right way to fix this: --- io_stream.h.orig2009-12-18 06:59:54.0 -0500 +++ io_stream.h 2011-09-03 21:14:44.664235000 -0400 @@ -33,7 +33,7 @@ */ //Where is this defined? -#if defined(_WIN32) ! defined(__CYGWIN__) +#if defined(_WIN32) ! defined(__CYGWIN__) ! defined(HAVE_SYS_TYPES_H) typedef signed long ssize_t; #endif That's definitely the wrong approach to fix the problem. Why not just include sys/types.h in io_stream.h? cgf
Re: gcc4: Time to drop gcc3 from the distro?
On Fri, 2011-09-02 at 20:40 +0200, Corinna Vinschen wrote: As the subject says, shouldn't we remove gcc3 from the distro finally? We have 3 mingw compilers and gcc4 for Cygwin. What reason is left to stick to gcc 3? Based on Dave's response, only GDC. Therefore, I would say that once he's ready to ship a GDC-enabled gcc-4.5+, then gcc3 can and should go, at which point gcc4 can become gcc and the -4 suffixes can be dropped. Yaakov
Re: debugging SIGSEV on pclose
On 9/6/2011 5:20 AM, jan.kolar wrote: Marco, this is not point where octave always crashes, since in an strace dump I sent you separately, I read 188 145419026 [main] octave-3.4.2 11704 close: close (6) 31 145419057 [main] octave-3.4.2 11704 fhandler_base::close: closing 'pipe:[6]' 34 145419091 [main] octave-3.4.2 11704 close: 0 = close (6) which I believe to be produced by if (fclose (fp)) just below the code you listed. Also you give two 'Program received signal SIGSEGV' with different locations. This suggests the problem is caused by an asynchronous event. The event may come from another thread, from OS, or from a child process. I suggest to replace gs with another program (like cat.exe with a redirection) and test if that makes difference. Hi Kolar, first please no top posting on the cygwin mailing list. Stepping within GDB, I can confirm you that the crash is happening inside pclose. The close reported by strace is relative to the pclose call, and the exception is killing octave not gs. 232 103746055 [main] octave-3.4.2 3664 close: close (6) 33 103746088 [main] octave-3.4.2 3664 fhandler_base::close: closing 'pipe:[6]' handle 0x470 33 103746121 [main] octave-3.4.2 3664 close: 0 = close (6) 205 258249 [main] gs 2840 open: open (/usr/share/ghostscript/8.63/lib/gs_wan_e.ps, 0x0) 30 258279 [main] gs 2840 normalize_posix_path: src /usr/share/ghostscript/8.63/lib/gs_wan_e.ps 30 258309 [main] gs 2840 normalize_posix_path: /usr/share/ghostscript/8.63/lib/gs_wan_e.ps = normalize_posix_path (/usr/share/ghostscript/8.63/lib/gs_wan_e.ps) 27 258336 [main] gs 2840 mount_info::conv_to_win32_path: conv_to_win32_path (/usr/share/ghostscript/8.63/lib/gs_wan_e.ps) 26 258362 [main] gs 2840 set_flags: flags: binary (0x2) 33 258395 [main] gs 2840 mount_info::conv_to_win32_path: src_path /usr/share/ghostscript/8.63/lib/gs_wan_e.ps, dst E:\cygwin2\usr\share\ghostscript\8.63\lib\gs_wan_e.ps, flags 0x3000A, rc 0 66 258461 [main] gs 2840 symlink_info::check: 0x0 = NtCreateFile (\??\E:\cygwin2\usr\share\ghostscript\8.63\lib\gs_wan_e.ps) 43 258504 [main] gs 2840 symlink_info::check: not a symlink --- Process 3664, exception C005 at 610ECEFA [long cut] 39 2360323 [main] gs 2840 pinfo::exit: Calling ExitProcess n 0x0, exitcode 0x0 --- stepping inside pclose, line 4026 of syscalls.cc is where the SIGSEV is generated, but why is the nasty question --- [long cut] 4024 fhandler_pipe *fh = (fhandler_pipe *) cygheap-fdtab[fileno(fp)]; (gdb) step 4026 if (fh-get_device () != FH_PIPEW fh-get_device () != FH_PIPER) (gdb) step 0x7c90e480 in ntdll!LdrDisableThreadCalloutsForDll () from /cygdrive/c/WINDOWS/system32/ntdll.dll (gdb) step Single stepping until exit from function ntdll!LdrDisableThreadCalloutsForDll, which has no line number information. 0x7c92a824 in wcstol () from /cygdrive/c/WINDOWS/system32/ntdll.dll (gdb) step Single stepping until exit from function wcstol, which has no line number information. 0x7c9033dc in ntdll!RtlCheckRegistryKey () from /cygdrive/c/WINDOWS/system32/ntdll.dll (gdb) step Single stepping until exit from function ntdll!RtlCheckRegistryKey, which has no line number information. 0x7c92a853 in wcstol () from /cygdrive/c/WINDOWS/system32/ntdll.dll (gdb) step Single stepping until exit from function wcstol, which has no line number information. 0x7c9033f8 in ntdll!RtlCheckRegistryKey () from /cygdrive/c/WINDOWS/system32/ntdll.dll (gdb) step Single stepping until exit from function ntdll!RtlCheckRegistryKey, which has no line number information. 0x7c92a858 in wcstol () from /cygdrive/c/WINDOWS/system32/ntdll.dll (gdb) step Single stepping until exit from function wcstol, which has no line number information. 0x7c901118 in ntdll!RtlUnhandledExceptionFilter () from /cygdrive/c/WINDOWS/system32/ntdll.dll (gdb) step Single stepping until exit from function ntdll!RtlUnhandledExceptionFilter, which has no line number information. 0x7c92a97b in wcstol () from /cygdrive/c/WINDOWS/system32/ntdll.dll (gdb) step Single stepping until exit from function wcstol, which has no line number information. 0x7c92f557 in ntdll!_itow () from /cygdrive/c/WINDOWS/system32/ntdll.dll (gdb) step Single stepping until exit from function ntdll!_itow, which has no line number information. 0x7c92aa01 in wcstol () from /cygdrive/c/WINDOWS/system32/ntdll.dll (gdb) step Single stepping until exit from function wcstol, which has no line number information. 0x7c910339 in ntdll!RtlInitAnsiString () from /cygdrive/c/WINDOWS/system32/ntdll.dll (gdb) step Single stepping until exit from function ntdll!RtlInitAnsiString, which has no line number information. 0x7c9102d9 in ntdll!RtlAppendStringToString () from
Re: Typical Cygwin fork problem
On 2011-09-06 01:53Z, jan.kolar wrote: Why the newest version rebase/rebase-3.0-2 utilities for rebasing DLLs [...] is listed in the middle of this page? Actually, the one at the bottom is the newest: 2009 April rebase-3.0-2 2009 July rebase-3.0.1-1 Anything following a '-' at the end is likely to be an auxiliary serial number, e.g., to distinguish successive uploads of the same release. -- 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] Updated: stable compiler package gcc4-4.5.3-2
I recompiled the recent boost libraries with the new gcc-4 package. The thread example fails with: $ g++ thread.cpp -L /usr/local/lib -lboost_thread /tmp/cccfCagO.o:thread.cpp:(.text+0xa4): undefined reference to `__Unwind_Resume' Cheers, -- Bernd On 9/1/2011 11:49 PM, Dave Korn wrote: I have just uploaded an updated GCC-4 package to cygwin.com. It will be arriving at your favourite mirror next time it synchronizes itself with the official Cygwin repository. This is a stable release of GCC 4.5.3 which replaces the earlier experimental release of GCC 4.5.0. --ooOOOoo-- PLEASE SEND BUG REPORTS, PROBLEMS, ETC. TO THE CYGWIN MAILING LIST. --ooOOOoo-- ... -- 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: Typical Cygwin fork problem
On Mon, Sep 05, 2011 at 06:53:34PM -0700, jan.kolar wrote: Then you need to install the rebase package: http://cygwin.com/cgi-bin2/package-grep.cgi?grep=rebaseall Why the newest version rebase/rebase-3.0-2 utilities for rebasing DLLs to load at alternate addresses is listed in the middle of this page? It's confusing. Not really. You searched for every package which contained the string rebase. If you were looking for the latest version of rebase then go to http://cygwin.com/packages/, scroll down until you see rebase and then click on that. Or, if you want to use the package grep, type rebase.exe into the search box to look for the package which contains that program. -- 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] Updated: stable compiler package gcc4-4.5.3-2
On Tue, 2011-09-06 at 15:44 -0400, Bernd Prager wrote: I recompiled the recent boost libraries with the new gcc-4 package. The thread example fails with: $ g++ thread.cpp -L /usr/local/lib -lboost_thread /tmp/cccfCagO.o:thread.cpp:(.text+0xa4): undefined reference to `__Unwind_Resume' There will be new boost packages soon built for gcc-4.5. 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
