Re: [64bit] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284
None of the tricks (-fno-reorder-blocks, -r, -nostdlib) help here. It still fails the same way. Shall I create a GCC Bugzilla report from this then? On 14 April 2013 11:13, Kai Tietz ktiet...@googlemail.com wrote: 2013/4/14 Yaakov (Cygwin/X) wrote: On 2013-04-11 03:58, Václav Zeman wrote: I have tried to compile log4cplus (C++ logging library) on Cygwin64 with -flto GCC option. I am getting the following failure: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284 Confirmed; I suggest you continue pursuing this upstream via your PR55902. Yaakov Hmm, not sure if this is for real the same issue. Does option -r or -nostdlib solves the issue for you? I assume that the underlying issue might be related to an bb-reorder issue (-fno-reorder-blocks might solve it too). Thanks, Kai -- VZ
Re: [64bit] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284
2013/4/15 Václav Zeman vhais...@gmail.com: None of the tricks (-fno-reorder-blocks, -r, -nostdlib) help here. It still fails the same way. Shall I create a GCC Bugzilla report from this then? Yes, then please create an new BZ for it, and mention that there that all these options had no effect. Thanks, Kai
Re: [64bit] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284
2013/4/15 Václav Zeman wrote: None of the tricks (-fno-reorder-blocks, -r, -nostdlib) help here. It still fails the same way. Shall I create a GCC Bugzilla report from this then? Yes, then please create an new BZ for it, and mention that there that all these options had no effect. Thanks, Kai
Re: [RFU 32 + 64bit] fltk
On 4/14/2013 11:09 PM, A.R. Burgers wrote: LS, packages for fltk-1.3 are available here for upload: 64 bit: wget -nH -r -L -R 'index.html*' --cut-dirs=3 http://members.quicknet.nl/ar.burgers/cygwin/64bit/fltk/ does not work in this way. Next time : wget -nH -np -r --cut-dirs=2 http://members.quicknet.nl/ar.burgers/cygwin/64bit/fltk/ find 64bit -name index.html* |xargs rm 32 bit: wget -nH -r -L -R 'index.html*' --cut-dirs=3 http://members.quicknet.nl/ar.burgers/cygwin/fltk/ wget -nH -np -r --cut-dirs=2 http://members.quicknet.nl/ar.burgers/cygwin/fltk/ find fltk -name index.html* |xargs rm for 32 bit please leave 1.3.1.9285 as previous should I remove 1.1.8r5648-1 and 1.1.10 ? kind regards, Teun Regards Marco
Re: [RFU 32 + 64bit] fltk
Hi Teun, On Apr 14 23:09, A.R. Burgers wrote: LS, packages for fltk-1.3 are available here for upload: 64 bit: wget -nH -r -L -R 'index.html*' --cut-dirs=3 http://members.quicknet.nl/ar.burgers/cygwin/64bit/fltk/ 32 bit: wget -nH -r -L -R 'index.html*' --cut-dirs=3 http://members.quicknet.nl/ar.burgers/cygwin/fltk/ for 32 bit please leave 1.3.1.9285 as previous kind regards, Marco uploaded the packages, but there was a small problem. The required: lines of libfltk-devel/setup.hint and libfltk1.3/setup.hint were broken up in multiple lines. I fixed that on cygwin.com, but maybe you should check locally. Did cygport add the line breaks for some reason? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFU 32 + 64bit] fltk
On 4/15/2013 10:01 AM, marco atzeri wrote: On 4/14/2013 11:09 PM, A.R. Burgers wrote: LS, for 32 bit please leave 1.3.1.9285 as previous should I remove 1.1.8r5648-1 and 1.1.10 ? as they are needed for libfltk1.1 , it is better to not remove. Regards Marco
Re: [64bit] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284
I have filled the GCC Bugzilla PR: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56963 On 15 April 2013 09:56, Kai Tietz ktiet...@googlemail.com wrote: 2013/4/15 Václav Zeman wrote: None of the tricks (-fno-reorder-blocks, -r, -nostdlib) help here. It still fails the same way. Shall I create a GCC Bugzilla report from this then? Yes, then please create an new BZ for it, and mention that there that all these options had no effect. Thanks, Kai -- VZ
Re: 64bit: cygstdc++-6.dll
On Apr 14 13:28, Corinna Vinschen wrote:
On Apr 14 13:09, Kai Tietz wrote:
No, IMHO it is a flaw to make const-data and text sections in
pe-coff-image by default writable without good need. v1 and v2
pseudo-relocation are capable to handle read-only sections.
Sure. I'd say the same goes for Cygwin images. .text is R/O anyway, so
that only leaves the .rdata content moved to .data when auto-image is
enabled. Given that this seems to be old behaviour, based on an old
assumption, it seems we could just get rid of the .xa ldscript to fix
this issue in future.
Does anybody volunteer to have a look into this and send a patch upstream
to binutils?
For testing, I created a simple testcase:
$ cat EOF x.c
#include stdio.h
extern int optind;
int main () { printf (optind: %d,%p\n, optind, optind);
EOF
On 32 bit:
$ gcc -o x x.c
$ objdump -h x
[...]
0 .text 0748 00401000 00401000 0400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 0098 00402000 00402000 0c00 2**5
CONTENTS, ALLOC, LOAD, DATA
2 .rdata0024 00403000 00403000 0e00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .eh_frame 0004 00404000 00404000 1000 2**2
CONTENTS, ALLOC, LOAD, DATA
4 .bss 0110 00405000 00405000 2**5
ALLOC
5 .idata01e0 00406000 00406000 1200 2**2
CONTENTS, ALLOC, LOAD, DATA
[...]
$ nm x | grep optind
0040117f T __fu0__optind
00401187 T __fu1__optind
004060a0 I __imp__optind
004060a0 I __imp__optind
00406140 I __nm__optind
So on 32 bit we have two symbols in .text and 3 symbols in .idata.
On 64 bit:
$ gcc -o x x.c
$ objdump -h x
[...]
0 .text 0760 000100401000 000100401000 0400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 0048 000100402000 000100402000 0c00 2**5
CONTENTS, ALLOC, LOAD, DATA
2 .rdata0308 000100403000 000100403000 0e00 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .pdata00e4 000100404000 000100404000 1200 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .xdata0088 000100405000 000100405000 1400 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .bss 01c0 000100406000 000100406000 2**5
ALLOC
6 .idata025c 000100407000 000100407000 1600 2**2
CONTENTS, ALLOC, LOAD, DATA
$ nm x | grep optind
000100403050 r .rdata$.refptr.optind
000100403050 R .refptr.optind
000100403050 R __fu0_optind
000100407104 I __imp_optind
000100407104 I __imp_optind
0001004071bc I __nm_optind
So on 64 bit we have three symbols in .rdata and 3 in .idata.
On 32 bit, the .xa script is used, but has no influence, apparently.
On 64 bit, the .x script is used, even with --enable-auto-import.
Both versions work as expected:
$ ./x
optind: 1,0x611821e4
$ ./x
optind: 1,0x1801c37bc
To me this means, we should not use the .xa file on 32 bit either.
It moves all .rdata data to the .data section for no good reason,
thus adding unnecessary pressure to the pagefile.
Does that make sense or did I miss something?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
Re: 64bit: cygstdc++-6.dll
On 2013-04-15 11:48, Corinna Vinschen wrote:
On Apr 14 13:28, Corinna Vinschen wrote:
On Apr 14 13:09, Kai Tietz wrote:
No, IMHO it is a flaw to make const-data and text sections in
pe-coff-image by default writable without good need. v1 and v2
pseudo-relocation are capable to handle read-only sections.
Sure. I'd say the same goes for Cygwin images. .text is R/O anyway, so
that only leaves the .rdata content moved to .data when auto-image is
enabled. Given that this seems to be old behaviour, based on an old
assumption, it seems we could just get rid of the .xa ldscript to fix
this issue in future.
Does anybody volunteer to have a look into this and send a patch upstream
to binutils?
For testing, I created a simple testcase:
$ cat EOF x.c
#include stdio.h
extern int optind;
int main () { printf (optind: %d,%p\n, optind, optind);
EOF
On 32 bit:
$ gcc -o x x.c
$ objdump -h x
[...]
0 .text 0748 00401000 00401000 0400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 0098 00402000 00402000 0c00 2**5
CONTENTS, ALLOC, LOAD, DATA
2 .rdata0024 00403000 00403000 0e00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .eh_frame 0004 00404000 00404000 1000 2**2
CONTENTS, ALLOC, LOAD, DATA
4 .bss 0110 00405000 00405000 2**5
ALLOC
5 .idata01e0 00406000 00406000 1200 2**2
CONTENTS, ALLOC, LOAD, DATA
[...]
$ nm x | grep optind
0040117f T __fu0__optind
00401187 T __fu1__optind
004060a0 I __imp__optind
004060a0 I __imp__optind
00406140 I __nm__optind
So on 32 bit we have two symbols in .text and 3 symbols in .idata.
On 64 bit:
$ gcc -o x x.c
$ objdump -h x
[...]
0 .text 0760 000100401000 000100401000 0400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 0048 000100402000 000100402000 0c00 2**5
CONTENTS, ALLOC, LOAD, DATA
2 .rdata0308 000100403000 000100403000 0e00 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .pdata00e4 000100404000 000100404000 1200 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .xdata0088 000100405000 000100405000 1400 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .bss 01c0 000100406000 000100406000 2**5
ALLOC
6 .idata025c 000100407000 000100407000 1600 2**2
CONTENTS, ALLOC, LOAD, DATA
$ nm x | grep optind
000100403050 r .rdata$.refptr.optind
000100403050 R .refptr.optind
000100403050 R __fu0_optind
000100407104 I __imp_optind
000100407104 I __imp_optind
0001004071bc I __nm_optind
So on 64 bit we have three symbols in .rdata and 3 in .idata.
On 32 bit, the .xa script is used, but has no influence, apparently.
On 64 bit, the .x script is used, even with --enable-auto-import.
Both versions work as expected:
$ ./x
optind: 1,0x611821e4
$ ./x
optind: 1,0x1801c37bc
To me this means, we should not use the .xa file on 32 bit either.
It moves all .rdata data to the .data section for no good reason,
thus adding unnecessary pressure to the pagefile.
Does that make sense or did I miss something?
Corinna
IIRC it was more problematic with complex data structures and needing
more than one relocation for a single lookup. Like importing a const
that is used as offset in an imported const array, or something like
that. Or, I'm completely off base and that was a totally different
problem, sorry for the noise in that case.
Cheers,
Peter
Re: 64bit: cygstdc++-6.dll
On 2013-04-15 04:48, Corinna Vinschen wrote:
On 32 bit, the .xa script is used, but has no influence, apparently.
On 64 bit, the .x script is used, even with --enable-auto-import.
The reason being, on x86_64, .xa is used only if pseudo-reloc v1 is
specified (the default is v2), where on ix86 it is used for all
non-mingw* targets OR on mingw* with v1.
To me this means, we should not use the .xa file on 32 bit either.
It moves all .rdata data to the .data section for no good reason,
thus adding unnecessary pressure to the pagefile.
Patch attached.
Yaakov
Use the .x ldscript for pseudo-reloc v2; .xa is only for v1.
--- binutils-2.23.51-1/origsrc/binutils-/ld/emultempl/pe.em 2013-01-10 14:08:03.0 -0600
+++ binutils-2.23.51-1/src/binutils-/ld/emultempl/pe.em 2013-04-15 04:58:44.458607800 -0500
@@ -174,7 +174,7 @@ EOF
case ${target} in
*-*-cygwin*)
default_auto_import=1
-default_merge_rdata=1
+default_merge_rdata=0
;;
i[3-7]86-*-mingw* | x86_64-*-mingw*)
default_auto_import=1
Re: 64bit: cygstdc++-6.dll
On Apr 15 05:14, Yaakov (Cygwin/X) wrote: On 2013-04-15 04:48, Corinna Vinschen wrote: On 32 bit, the .xa script is used, but has no influence, apparently. On 64 bit, the .x script is used, even with --enable-auto-import. The reason being, on x86_64, .xa is used only if pseudo-reloc v1 is specified (the default is v2), where on ix86 it is used for all non-mingw* targets OR on mingw* with v1. To me this means, we should not use the .xa file on 32 bit either. It moves all .rdata data to the .data section for no good reason, thus adding unnecessary pressure to the pagefile. Patch attached. That looks right to me. We're using v2 as well, so we should also use the .xa file only when generating v1 pseudo-relocs. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: 64bit: cygstdc++-6.dll
On Apr 15 12:10, Peter Rosin wrote: On 2013-04-15 11:48, Corinna Vinschen wrote: On 32 bit, the .xa script is used, but has no influence, apparently. On 64 bit, the .x script is used, even with --enable-auto-import. Both versions work as expected: $ ./x optind: 1,0x611821e4 $ ./x optind: 1,0x1801c37bc To me this means, we should not use the .xa file on 32 bit either. It moves all .rdata data to the .data section for no good reason, thus adding unnecessary pressure to the pagefile. Does that make sense or did I miss something? IIRC it was more problematic with complex data structures and needing more than one relocation for a single lookup. Like importing a const that is used as offset in an imported const array, or something like that. Or, I'm completely off base and that was a totally different problem, sorry for the noise in that case. I don't know about that, but given Yaakov's finding that mingw can live without the .xa file for auto-import and v2 pseudo-relocs, and given that x86_64 can do so, too, I don't see why this should be different for Cygwin. Everything points to an old requirement when using v1 pseudo-relocs here. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
setup.exe: error: ‘KEY_WOW64_{64,32}KEY’ was not declared in this scope
Hi, I'm encountering this error whilst trying to build (32bit) setup.exe, under 32bit Cygwin: make[2]: Entering directory `/cygdrive/c/Users/sbaddah/cygwin-home/workarea/cygwin-setup-build' CXX install.o ../cygwin-setup/install.cc: In function ‘void create_allow_protected_renames()’: ../cygwin-setup/install.cc:265:27: error: ‘KEY_WOW64_64KEY’ was not declared in this scope ../cygwin-setup/install.cc:265:27: error: ‘KEY_WOW64_32KEY’ was not declared in this scope Makefile:855: recipe for target `install.o' failed make[2]: *** [install.o] Error 1 I think it may be linked to this change: http://sourceware.org/cgi-bin/cvsweb.cgi/setup/install.cc?rev=2.106content-type=text/x-cvsweb-markupcvsroot=cygwin-apps But this change looks to have been included in the 2.795 build of setup64.exe, so that gives me the impression I'm doing something wrong with my build parameters. Any help would be appreciated. -- Thanks, Shaddy
Re: setup.exe: error: ‘KEY_WOW64_{64,32}KEY’ was not declared in this scope
Hi, On 16/04/13 00:39, Shaddy Baddah wrote: I'm encountering this error whilst trying to build (32bit) setup.exe, under 32bit Cygwin: make[2]: Entering directory `/cygdrive/c/Users/sbaddah/cygwin-home/workarea/cygwin-setup-build' CXX install.o ../cygwin-setup/install.cc: In function ‘void create_allow_protected_renames()’: ../cygwin-setup/install.cc:265:27: error: ‘KEY_WOW64_64KEY’ was not declared in this scope ../cygwin-setup/install.cc:265:27: error: ‘KEY_WOW64_32KEY’ was not declared in this scope Makefile:855: recipe for target `install.o' failed make[2]: *** [install.o] Error 1 I think it may be linked to this change: http://sourceware.org/cgi-bin/cvsweb.cgi/setup/install.cc?rev=2.106content-type=text/x-cvsweb-markupcvsroot=cygwin-apps But this change looks to have been included in the 2.795 build of setup64.exe, so that gives me the impression I'm doing something wrong with my build parameters. Any help would be appreciated. I think I may have worked out what is wrong. I understand now (actually again, I'd forgotten) that the old mingw project is a little bit stale, and that mingw64 is the way forward. I'd configured my build using: $ ../cygwin-setup/configure --host=i686-pc-mingw32 -C which is using the legacy mingw32 compiler and its stale w32api. That w32api has a strange guard around the definitions for the above: #if (_WIN32_WINNT = 0x0502) #define KEY_WOW64_64KEY 0x0100 #define KEY_WOW64_32KEY 0x0200 #endif And however it is defined, _WIN32_WINNT is set as 0x0400. I am trying with: $ ../cygwin-setup/configure --host=i686-w64-mingw32 -C I am expecting this will work. I can report back if necessary.
Re: setup.exe: error: ‘KEY_WOW64_{64,32}KEY’ was not declared in this scope
Hi, On 16/04/13 01:34, Shaddy Baddah wrote: On 16/04/13 00:39, Shaddy Baddah wrote: I'm encountering this error whilst trying to build (32bit) setup.exe, under 32bit Cygwin: make[2]: Entering directory `/cygdrive/c/Users/sbaddah/cygwin-home/workarea/cygwin-setup-build' CXX install.o ../cygwin-setup/install.cc: In function ‘void create_allow_protected_renames()’: ../cygwin-setup/install.cc:265:27: error: ‘KEY_WOW64_64KEY’ was not declared in this scope ../cygwin-setup/install.cc:265:27: error: ‘KEY_WOW64_32KEY’ was not declared in this scope Makefile:855: recipe for target `install.o' failed make[2]: *** [install.o] Error 1 snip/ I think I may have worked out what is wrong. I understand now (actually again, I'd forgotten) that the old mingw project is a little bit stale, and that mingw64 is the way forward. I'd configured my build using: $ ../cygwin-setup/configure --host=i686-pc-mingw32 -C which is using the legacy mingw32 compiler and its stale w32api. That w32api has a strange guard around the definitions for the above: #if (_WIN32_WINNT = 0x0502) #define KEY_WOW64_64KEY 0x0100 #define KEY_WOW64_32KEY 0x0200 #endif And however it is defined, _WIN32_WINNT is set as 0x0400. I am trying with: $ ../cygwin-setup/configure --host=i686-w64-mingw32 -C I am expecting this will work. I can report back if necessary. Yes, this has worked. Sorry for the noise.
[RFU 32 + 64bit] fltk-1.3.1.9857-2
corrina wrote: Marco uploaded the packages, but there was a small problem. The required: lines of libfltk-devel/setup.hint and libfltk1.3/setup.hint were broken up in multiple lines. I fixed that on cygwin.com, but maybe you should check locally. Did cygport add the line breaks for some reason? I switched from manual setup.hints to cygport autobuilded setup.hint. I had embedded newlines in the values of the _REQUIRES variables, which apparently is not allowed. new packages for fltk-1.3 fixing this are available here for upload: 64 bit: wget -nH -r -L -R 'index.html*' --cut-dirs=3 http://members.quicknet.nl/ar.burgers/cygwin/64bit/fltk/ 32 bit: wget -nH -r -L -R 'index.html*' --cut-dirs=2 http://members.quicknet.nl/ar.burgers/cygwin/fltk/ Marco had an issue with the wget command. I think there was an error in the cut-dirs level in one of the wget commands. I double checked, the wgets work fine for me, I hope they work for you too. kind regards, Teun
Re: [RFU 32 + 64bit] fltk-1.3.1.9857-2
On 4/15/2013 8:40 PM, a.rburg...@quicknet.nl wrote: corrina wrote: Marco uploaded the packages, but there was a small problem. The required: lines of libfltk-devel/setup.hint and libfltk1.3/setup.hint were broken up in multiple lines. I fixed that on cygwin.com, but maybe you should check locally. Did cygport add the line breaks for some reason? I switched from manual setup.hints to cygport autobuilded setup.hint. I had embedded newlines in the values of the _REQUIRES variables, which apparently is not allowed. new packages for fltk-1.3 fixing this are available here for upload: do we need to upload a new version just for setup.hint ? I guess Corinna already solved it. 64 bit: wget -nH -r -L -R 'index.html*' --cut-dirs=3 http://members.quicknet.nl/ar.burgers/cygwin/64bit/fltk/ 32 bit: wget -nH -r -L -R 'index.html*' --cut-dirs=2 http://members.quicknet.nl/ar.burgers/cygwin/fltk/ Marco had an issue with the wget command. In reality it is sourceware.org that does not like it in this way I suspect it is due to the : -R 'index.html*' as index.html is the first file downloaded and than immediately rejected, nothing else if further downloaded. I think there was an error in the cut-dirs level in one of the wget commands. I double checked, the wgets work fine for me, I hope they work for you too. different system , different result. kind regards, Teun Regards Marco
Re: [RFU 32 + 64bit] fltk-1.3.1.9857-2
On 2013-04-15 15:03, marco atzeri wrote: On 4/15/2013 8:40 PM, a.rburgers wrote: I switched from manual setup.hints to cygport autobuilded setup.hint. I had embedded newlines in the values of the _REQUIRES variables, which apparently is not allowed. new packages for fltk-1.3 fixing this are available here for upload: do we need to upload a new version just for setup.hint ? No. Yaakov
Re: libaa1 is in the wrong category Lib, should be Libs.
On 4/14/2013 10:47 PM, Peter Rosin wrote: Hi! libaa1-1.4rc5-11 is all alone and desperate for company in the Lib category. Please move it to Libs. Cheers, Peter done -- 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: possible libtool bug blocking builds of Cygwin setup.exe
Hi Peter, On Apr 13, Peter Rosin wrote: On 2013-04-13 02:31, Shaddy Baddah wrote: Hi Peter, On 13/04/13 09:15, Peter Rosin wrote: /snip Have I stumbled on a real problem? This all sounds suspiciously like libtool bug 14022, where the reporter had confused --build and --host. How did you run configure? I'm emulating what is in setup/bootstrap.sh: $ ../cygwin-setup/configure --build=i686-pc-mingw32 --host=i686-pc-mingw32 -C Since you had POSIX paths with a distinct Cygwin touch, I guess we can stop blaming Libtool. You are apparently cross-compiling from Cygwin to MinGW and should drop your --build argument and thus let config.guess do its thing. I.e. stop lying to configure. Or build with MSYS where the above --build and --host are true. I guess the bootstrap script also needs some love if you have read it right. I haven't read it at all. You are correct, dropping the --build argument was the correct action. I apologise for blaming libtool. I was confused and therefore only suggested it was a possibility. Thankfully it was not. -- Thanks, 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: Issue with binutils-2.23.1-1
Hi All, On 6 March 2013 08:40, Chris Sutcliffe wrote: I noticed a problem after upgrading to the 2.23.1-1 release of binutils that cygport was no longer generating debuginfo files. After digging in to it a little and following up on the cygwin-ports mailing list, Yaakov determined that the objdump included in the 2.23.1 release of binutils does not handle the -l flag properly. Reverting to 2.22.51-2 solved the issue for me and Yaakov confirmed that the issue does not exist in CVS HEAD either. This issue has resurfaced in the 2.23.52.20130309 release of bintuils currently shipping with Cygwin. My cygport based packages are no longer producing debuginfo packages. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- 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: Issue with binutils-2.23.1-1
On Apr 15 08:54, Chris Sutcliffe wrote: Hi All, On 6 March 2013 08:40, Chris Sutcliffe wrote: I noticed a problem after upgrading to the 2.23.1-1 release of binutils that cygport was no longer generating debuginfo files. After digging in to it a little and following up on the cygwin-ports mailing list, Yaakov determined that the objdump included in the 2.23.1 release of binutils does not handle the -l flag properly. Reverting to 2.22.51-2 solved the issue for me and Yaakov confirmed that the issue does not exist in CVS HEAD either. This issue has resurfaced in the 2.23.52.20130309 release of bintuils currently shipping with Cygwin. My cygport based packages are no longer producing debuginfo packages. Erm... 2.23.52-1 is a 64bit-only package. I created all the debuginfo packages with this version. 32 bit is at 2.23.51-1, and I'm pretty sure I created the latest OpenSSH packages with that version, including debuginfo. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Issue with binutils-2.23.1-1
On Apr 15 15:21, Corinna Vinschen wrote: On Apr 15 08:54, Chris Sutcliffe wrote: Hi All, On 6 March 2013 08:40, Chris Sutcliffe wrote: I noticed a problem after upgrading to the 2.23.1-1 release of binutils that cygport was no longer generating debuginfo files. After digging in to it a little and following up on the cygwin-ports mailing list, Yaakov determined that the objdump included in the 2.23.1 release of binutils does not handle the -l flag properly. Reverting to 2.22.51-2 solved the issue for me and Yaakov confirmed that the issue does not exist in CVS HEAD either. This issue has resurfaced in the 2.23.52.20130309 release of bintuils currently shipping with Cygwin. My cygport based packages are no longer producing debuginfo packages. Erm... 2.23.52-1 is a 64bit-only package. I created all the debuginfo packages with this version. 32 bit is at 2.23.51-1, and I'm pretty sure I created the latest OpenSSH packages with that version, including debuginfo. Oh, hmm. The 2.23.51-1 package actually contains the 2.23.52.20130309 binutils files, so never mind what I wrote. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Issue with binutils-2.23.1-1
On Mon, Apr 15, 2013 at 03:48:09PM +0200, Corinna Vinschen wrote: On Apr 15 15:21, Corinna Vinschen wrote: On Apr 15 08:54, Chris Sutcliffe wrote: Hi All, On 6 March 2013 08:40, Chris Sutcliffe wrote: I noticed a problem after upgrading to the 2.23.1-1 release of binutils that cygport was no longer generating debuginfo files. After digging in to it a little and following up on the cygwin-ports mailing list, Yaakov determined that the objdump included in the 2.23.1 release of binutils does not handle the -l flag properly. Reverting to 2.22.51-2 solved the issue for me and Yaakov confirmed that the issue does not exist in CVS HEAD either. This issue has resurfaced in the 2.23.52.20130309 release of bintuils currently shipping with Cygwin. My cygport based packages are no longer producing debuginfo packages. Erm... 2.23.52-1 is a 64bit-only package. I created all the debuginfo packages with this version. 32 bit is at 2.23.51-1, and I'm pretty sure I created the latest OpenSSH packages with that version, including debuginfo. Oh, hmm. The 2.23.51-1 package actually contains the 2.23.52.20130309 binutils files, so never mind what I wrote. Just to be clear: The current 32-bit version of binutils is 2.23.51-1. It was released to address the problems with objdump introduced by a, er, illegal upload by someone who was confused about binutils maintainership. There is no 32-bit version named 2.23.52.20130309 or 2.23.1-1. 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: Issue with binutils-2.23.1-1
On Apr 15 10:37, Christopher Faylor wrote: On Mon, Apr 15, 2013 at 03:48:09PM +0200, Corinna Vinschen wrote: On Apr 15 15:21, Corinna Vinschen wrote: On Apr 15 08:54, Chris Sutcliffe wrote: Hi All, On 6 March 2013 08:40, Chris Sutcliffe wrote: I noticed a problem after upgrading to the 2.23.1-1 release of binutils that cygport was no longer generating debuginfo files. After digging in to it a little and following up on the cygwin-ports mailing list, Yaakov determined that the objdump included in the 2.23.1 release of binutils does not handle the -l flag properly. Reverting to 2.22.51-2 solved the issue for me and Yaakov confirmed that the issue does not exist in CVS HEAD either. This issue has resurfaced in the 2.23.52.20130309 release of bintuils currently shipping with Cygwin. My cygport based packages are no longer producing debuginfo packages. Erm... 2.23.52-1 is a 64bit-only package. I created all the debuginfo packages with this version. 32 bit is at 2.23.51-1, and I'm pretty sure I created the latest OpenSSH packages with that version, including debuginfo. Oh, hmm. The 2.23.51-1 package actually contains the 2.23.52.20130309 binutils files, so never mind what I wrote. Just to be clear: The current 32-bit version of binutils is 2.23.51-1. It was released to address the problems with objdump introduced by a, er, illegal upload by someone who was confused about binutils maintainership. There is no 32-bit version named 2.23.52.20130309 or 2.23.1-1. If you run `ld --version' on ld from the 2.23.51-1 package, it returns GNU ld (GNU Binutils) 2.23.52.20130309 Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Issue with binutils-2.23.1-1
On Mon, Apr 15, 2013 at 04:39:54PM +0200, Corinna Vinschen wrote: On Apr 15 10:37, Christopher Faylor wrote: On Mon, Apr 15, 2013 at 03:48:09PM +0200, Corinna Vinschen wrote: On Apr 15 15:21, Corinna Vinschen wrote: On Apr 15 08:54, Chris Sutcliffe wrote: Hi All, On 6 March 2013 08:40, Chris Sutcliffe wrote: I noticed a problem after upgrading to the 2.23.1-1 release of binutils that cygport was no longer generating debuginfo files. After digging in to it a little and following up on the cygwin-ports mailing list, Yaakov determined that the objdump included in the 2.23.1 release of binutils does not handle the -l flag properly. Reverting to 2.22.51-2 solved the issue for me and Yaakov confirmed that the issue does not exist in CVS HEAD either. This issue has resurfaced in the 2.23.52.20130309 release of bintuils currently shipping with Cygwin. My cygport based packages are no longer producing debuginfo packages. Erm... 2.23.52-1 is a 64bit-only package. I created all the debuginfo packages with this version. 32 bit is at 2.23.51-1, and I'm pretty sure I created the latest OpenSSH packages with that version, including debuginfo. Oh, hmm. The 2.23.51-1 package actually contains the 2.23.52.20130309 binutils files, so never mind what I wrote. Just to be clear: The current 32-bit version of binutils is 2.23.51-1. It was released to address the problems with objdump introduced by a, er, illegal upload by someone who was confused about binutils maintainership. There is no 32-bit version named 2.23.52.20130309 or 2.23.1-1. If you run `ld --version' on ld from the 2.23.51-1 package, it returns GNU ld (GNU Binutils) 2.23.52.20130309 Again, the version that was uploaded in March was to fix the problem reported in this thread. It's odd that it took a month for someone to notice a problem if the problem is still there. The original thread did not have an explanation of what the actual problem with objdump was so I don't really have any way of investigating it. Yaakov, can you explain what you think the problem is? 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: Issue with binutils-2.23.1-1
On Apr 15 11:11, Christopher Faylor wrote: On Mon, Apr 15, 2013 at 04:39:54PM +0200, Corinna Vinschen wrote: On Apr 15 10:37, Christopher Faylor wrote: On Mon, Apr 15, 2013 at 03:48:09PM +0200, Corinna Vinschen wrote: On Apr 15 15:21, Corinna Vinschen wrote: On Apr 15 08:54, Chris Sutcliffe wrote: Hi All, On 6 March 2013 08:40, Chris Sutcliffe wrote: I noticed a problem after upgrading to the 2.23.1-1 release of binutils that cygport was no longer generating debuginfo files. After digging in to it a little and following up on the cygwin-ports mailing list, Yaakov determined that the objdump included in the 2.23.1 release of binutils does not handle the -l flag properly. Reverting to 2.22.51-2 solved the issue for me and Yaakov confirmed that the issue does not exist in CVS HEAD either. This issue has resurfaced in the 2.23.52.20130309 release of bintuils currently shipping with Cygwin. My cygport based packages are no longer producing debuginfo packages. Erm... 2.23.52-1 is a 64bit-only package. I created all the debuginfo packages with this version. 32 bit is at 2.23.51-1, and I'm pretty sure I created the latest OpenSSH packages with that version, including debuginfo. Oh, hmm. The 2.23.51-1 package actually contains the 2.23.52.20130309 binutils files, so never mind what I wrote. Just to be clear: The current 32-bit version of binutils is 2.23.51-1. It was released to address the problems with objdump introduced by a, er, illegal upload by someone who was confused about binutils maintainership. There is no 32-bit version named 2.23.52.20130309 or 2.23.1-1. If you run `ld --version' on ld from the 2.23.51-1 package, it returns GNU ld (GNU Binutils) 2.23.52.20130309 Again, the version that was uploaded in March was to fix the problem reported in this thread. I was just pointing out the version mismatch. The package is called 2.23.51, while the binaries claim to be 2.23.52. I did not comment on the behaviour. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Debugging totally broken with latest everything?
On Mon, Apr 15, 2013 at 05:03:17PM +0100, Dave Korn wrote: Some notes on the above: The same happens with both the previous version and current snapshot of the cygwin dll. It also happens with both current gdb and an old gdb 6.8.0.20080328-cvs that I have lying around. The hw.exe in question is your bog-standard hello world, compiled with -g -O0 using gcc4-4.5.3-3. kill -9 won't kill gdb; I have to use Windows task manager. If I've attached gdb to the hung gdb, I can kill it from there using the k instruction. Anyone else having similar problems? You're probably seeing a known bug in gdb where it no longer works well when run from a console window. There is a race where gdb tries to get tty information from a stopped cygwin process. Although I didn't introduce the problem, I have tried to fix it from time to time without much luck. Debugging from mintty will probably work better. 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: Issue with binutils-2.23.1-1
On Mon, Apr 15, 2013 at 06:52:45PM +0200, Corinna Vinschen wrote: I was just pointing out the version mismatch. The package is called 2.23.51, while the binaries claim to be 2.23.52. I did not comment on the behaviour. Yes, I got that. I was trying to move the discussion away from version confusion and into the realm of fixing the actual problem. That's why I asked Yaakov for comment since he was referenced in the original thread as understanding the problem. 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: Debugging totally broken with latest everything?
On 15/04/2013 18:14, Christopher Faylor wrote: On Mon, Apr 15, 2013 at 05:03:17PM +0100, Dave Korn wrote: Some notes on the above: The same happens with both the previous version and current snapshot of the cygwin dll. It also happens with both current gdb and an old gdb 6.8.0.20080328-cvs that I have lying around. The hw.exe in question is your bog-standard hello world, compiled with -g -O0 using gcc4-4.5.3-3. kill -9 won't kill gdb; I have to use Windows task manager. If I've attached gdb to the hung gdb, I can kill it from there using the k instruction. Anyone else having similar problems? You're probably seeing a known bug in gdb where it no longer works well when run from a console window. There is a race where gdb tries to get tty information from a stopped cygwin process. Although I didn't introduce the problem, I have tried to fix it from time to time without much luck. It must be an interaction between gdb and the cygwin dll, since my old-and-previously-working-just-fine-in-a-console gdb-6 has also stopped working. Debugging from mintty will probably work better. It certainly does. Thanks for the tip. cheers, DaveK -- 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: Debugging totally broken with latest everything?
On 15/04/2013 1:14 PM, Christopher Faylor wrote:
On Mon, Apr 15, 2013 at 05:03:17PM +0100, Dave Korn wrote:
Some notes on the above:
The same happens with both the previous version and current snapshot of the
cygwin dll. It also happens with both current gdb and an old gdb
6.8.0.20080328-cvs that I have lying around.
The hw.exe in question is your bog-standard hello world, compiled with -g
-O0 using gcc4-4.5.3-3.
kill -9 won't kill gdb; I have to use Windows task manager. If I've
attached gdb to the hung gdb, I can kill it from there using the k
instruction.
Anyone else having similar problems?
You're probably seeing a known bug in gdb where it no longer works well
when run from a console window. There is a race where gdb tries to get
tty information from a stopped cygwin process. Although I didn't
introduce the problem, I have tried to fix it from time to time without
much luck.
I've also seen the problem, my workaround so far has been to ensure the
process is running again before attaching gdb to it (assuming you
stopped it with ^Z so that jobs -p could report its pid). Not that I
actually remember to do this most of the time...
Debugging from mintty will probably work better.
That's a rather unfortunate interaction with the long-standing feature
that interrupting programs with ^C only works if gdb runs in a console
window (STC I used today is below in case I've gotten something wrong).
Am I missing some obvious workaround?
Ryan
STC: when compiling and running this:
#include unistd.h
#include stdio.h
int main() {
printf(pid: %d\n, getpid());
sleep(10);
}
... ^C does not break in (it exits normally) when gdb runs inside
mintty; putting in a cmd.exe window allows ^C to break in with SIGTRAP
(though the stack trace is utterly useless since the thread is in
windows land at that point).
--
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: Debugging totally broken with latest everything?
On 2013-04-16 AM 1:03, Dave Korn wrote: Thread 2 (Thread 5536.0xe2c): #0 0x77f88a87 in ntdll!ZwReadFile () from /win/c/WINNT/system32/ntdll.dll #1 0x7c586381 in ?? () #2 0x610dd075 in wait_sig () at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/sigproc.cc:1360 #3 0x61003e65 in cygthread::callfunc (this=0x6118a400 threads, issimplestub=optimized out) at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/cygthread.cc:51 #4 0x610043ef in cygthread::stub (arg=0x6118a400 threads) at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/cygthread.cc:93 #5 0x6100533d in _cygtls::call2 (this=optimized out, func=0x610043a0 cygthread::stub(void*), arg=0x6118a400 threads, buf=0x610054cb _cygtls::call(unsigned long (*)(void*, void*), void*)+91) at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/cygtls.cc:99 #6 0x0270ffb4 in ?? () #7 0x7c57b3bc in ?? () #8 0x in ?? () Thread 1 (Thread 5536.0x1640): #0 0x77f88f43 in ntdll!ZwWriteFile () from /win/c/WINNT/system32/ntdll.dll #1 0x7c5864f9 in ?? () #2 0x610dc3f4 in sig_send (p=0x14ea444, si=..., tls=0x0) at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/sigproc.cc:736 #3 0x6106b028 in tty_min::kill_pgrp (this=0x60fc, sig=-43) at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/fhandler_termios.cc:133 #4 0x6106b129 in fhandler_termios::tcsetpgrp ( this=0x61274690 __real__Znwj+1629963920, pgid=2428) at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/fhandler_termios.cc:85 #5 0x610f9f78 in tcsetpgrp (fd=0, pgid=2428) at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/termios.cc:237 #6 0x610d6745 in _sigfe () from /usr/bin/cygwin1.dll #7 0x200bbb70 in ?? () #8 0x00418662 in ?? () #9 0x00521908 in ?? () #10 0x004eb052 in ?? () ---Type return to continue, or q return to quit--- #11 0x004eb265 in ?? () #12 0x004dd4a0 in ?? () #13 0x004dd6a5 in ?? () #14 0x005b11ab in ?? () #15 0x004feccb in ?? () #16 0x004ff6c0 in ?? () #17 0x005f2de2 in ?? () #18 0x004fed3b in ?? () #19 0x004fd9a0 in ?? () #20 0x004fdfc4 in ?? () #21 0x004fe4b8 in ?? () #22 0x004fe537 in ?? () #23 0x004f8345 in ?? () #24 0x004f6e0a in ?? () #25 0x004f8a85 in ?? () #26 0x004f6e0a in ?? () #27 0x004f9632 in ?? () #28 0x004011a8 in ?? () #29 0x6100763a in _cygwin_exit_return () at /usr/src/debug/cygwin-1.7.17-1/winsup/cygwin/dcrt0.cc:974 #30 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/debug/cygwin-1.7.17-1/winsup/cygwin/cygtls.cc:99 #31 0x014eff78 in ?? () #32 0x006c1df2 in ?? () #33 0x00401015 in ?? () #34 0x7c5989d5 in ?? () #35 0x in ?? () (gdb) Some notes on the above: The same happens with both the previous version and current snapshot of the cygwin dll. It also happens with both current gdb and an old gdb 6.8.0.20080328-cvs that I have lying around. The hw.exe in question is your bog-standard hello world, compiled with -g -O0 using gcc4-4.5.3-3. kill -9 won't kill gdb; I have to use Windows task manager. If I've attached gdb to the hung gdb, I can kill it from there using the k instruction. Anyone else having similar problems? cheers, DaveK As far as i know, wait_sig thread in debugee is interrupted after stepping or breakpoint( n s si ni ). so, if you don't give cygwin sufficient time during gdb session until wait_sig thread handles signal about terminal, it hangs like you observed. -- 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
Re: Issue with binutils-2.23.1-1
On 2013-04-15 10:11, Christopher Faylor wrote: The original thread did not have an explanation of what the actual problem with objdump was so I don't really have any way of investigating it. Yaakov, can you explain what you think the problem is? All I know right now is in this thread: http://www.mail-archive.com/cygwin-ports-general@lists.sourceforge.net/msg01217.html http://www.mail-archive.com/cygwin-ports-general@lists.sourceforge.net/msg01220.html I have not had this problem with 2.23.51 snapshots, hence I have not investigated this further, and debuginfo packages are being created correctly on my system. 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
Re: Issue with binutils-2.23.1-1
On 2013-04-15 07:54, Chris Sutcliffe wrote: On 6 March 2013 08:40, Chris Sutcliffe wrote: I noticed a problem after upgrading to the 2.23.1-1 release of binutils that cygport was no longer generating debuginfo files. After digging in to it a little and following up on the cygwin-ports mailing list, Yaakov determined that the objdump included in the 2.23.1 release of binutils does not handle the -l flag properly. Reverting to 2.22.51-2 solved the issue for me and Yaakov confirmed that the issue does not exist in CVS HEAD either. This issue has resurfaced in the 2.23.52.20130309 release of bintuils currently shipping with Cygwin. My cygport based packages are no longer producing debuginfo packages. WFM. Are you having issues with all packages or just some? 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
Re: Issue with binutils-2.23.1-1
On 15 April 2013 18:32, Yaakov (Cygwin/X) wrote: On 2013-04-15 07:54, Chris Sutcliffe wrote: On 6 March 2013 08:40, Chris Sutcliffe wrote: I noticed a problem after upgrading to the 2.23.1-1 release of binutils that cygport was no longer generating debuginfo files. After digging in to it a little and following up on the cygwin-ports mailing list, Yaakov determined that the objdump included in the 2.23.1 release of binutils does not handle the -l flag properly. Reverting to 2.22.51-2 solved the issue for me and Yaakov confirmed that the issue does not exist in CVS HEAD either. This issue has resurfaced in the 2.23.52.20130309 release of bintuils currently shipping with Cygwin. My cygport based packages are no longer producing debuginfo packages. WFM. Are you having issues with all packages or just some? Build issue on my end, sorry for the noise. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- 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
