Re: [Mingw-w64-public] Set a larger pch file size limit? was : can anyone supply a debug version of cc1plus.exe?
On 2015-5-31 16:22, asmwarrior wrote: On 2015-5-23 9:39, asmwarrior wrote: I just want to hunt the GCC bug: (big pch file will crash cc1plus.exe) 56926 – Crash (without ICE) while compiling Boost.Math - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 It turns out that build the GCC and G++ myself is too complex for me, so I would like to see if someone can supply a debug version of tool chain, so that I can run them under gdb to see where it crashed. BTW: I see that the latest LD can have separate debug file generated, so maybe, we can use it. Thanks. Hi, with Kai's suggestion: https://sourceforge.net/p/mingw-w64/bugs/382/ I guess that the hard limit value is 128M, and I would suggest a larger value for this variable. See here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926#c16 Any one would like to try a new build of gcc? There are some similar related discussion, see: 1, mingw - cc1plus.exe crash when using large precompiled header file http://stackoverflow.com/questions/10841306/cc1plus-exe-crash-when-using-large-precompiled-header-file 2, MinGW-w64 - for 32 and 64 bit Windows / Mailing Lists https://sourceforge.net/p/mingw-w64/mailman/message/30846624/ Thanks. Hi, good news, since I don't see any one rebuild a gcc chain by a larger pch_VA_max_size value recently. Today, I do it myself by modify the cc1plus.exe in a binary editor, just changed the values in the three referenced instructions. I changed the value from 128M to 512M. See details here: Comment 17 - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926#c17 Now, the modified cc1plus.exe never crash with a 200M pch file. So, the crash issue can to solved now!!! asmwarrior -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Set a larger pch file size limit? was : can anyone supply a debug version of cc1plus.exe?
On 2015-5-23 9:39, asmwarrior wrote: I just want to hunt the GCC bug: (big pch file will crash cc1plus.exe) 56926 – Crash (without ICE) while compiling Boost.Math - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 It turns out that build the GCC and G++ myself is too complex for me, so I would like to see if someone can supply a debug version of tool chain, so that I can run them under gdb to see where it crashed. BTW: I see that the latest LD can have separate debug file generated, so maybe, we can use it. Thanks. Hi, with Kai's suggestion: https://sourceforge.net/p/mingw-w64/bugs/382/ I guess that the hard limit value is 128M, and I would suggest a larger value for this variable. See here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926#c16 Any one would like to try a new build of gcc? There are some similar related discussion, see: 1, mingw - cc1plus.exe crash when using large precompiled header file http://stackoverflow.com/questions/10841306/cc1plus-exe-crash-when-using-large-precompiled-header-file 2, MinGW-w64 - for 32 and 64 bit Windows / Mailing Lists https://sourceforge.net/p/mingw-w64/mailman/message/30846624/ Thanks. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] can anyone supply a debug version of cc1plus.exe?
I just want to hunt the GCC bug: (big pch file will crash cc1plus.exe) 56926 – Crash (without ICE) while compiling Boost.Math - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 It turns out that build the GCC and G++ myself is too complex for me, so I would like to see if someone can supply a debug version of tool chain, so that I can run them under gdb to see where it crashed. BTW: I see that the latest LD can have separate debug file generated, so maybe, we can use it. Thanks. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is there a way to figure out why - cc1plus.exe has stopped working
On 2015-4-15 10:48, Norbert Pfeiler wrote: PCH on Windows did crash for *.gch files greater than 150 MiB or something. I don’t think that got fixed recently This is the bug report: Bug 56926 – Crash (without ICE) while compiling Boost.Math https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On 2013-12-10 20:53, Ray Donnelly wrote: Hi, Would it be possible to point me to these patches you've got? I'd like to take a look. Ray. Hi, Ray, do you mean my local patches to GDB when I build it under Windows 32bit? There are many, currently the most important ones, I think are those two: 1, https://sourceware.org/bugzilla/show_bug.cgi?id=15559 The patch in comment 8 (https://sourceware.org/bugzilla/attachment.cgi?id=7227action=diff) With this patch, I can let GDB to simulate a correct inferior call if the inferior(debugee) is built from MinGW GCC version7.0. 2,https://sourceware.org/bugzilla/show_bug.cgi?id=12127 I have a patch to fix this crash issue (see comment 6). But I think I don't need this patch because it was fixed in GDB GIT HEAD about two weeks ago(see comment 7). If you are still building GDB 7.6.2(release two days ago), I think you need to packport the fix to GDB 7.6.2. The fix can be view in this link https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=38e1f2a7d503d8abd788456782287383e0a0cfe8 All other patches are quite minor, such as * workaround performance issue http://sourceware.org/bugzilla/show_bug.cgi?id=15412 (patch in comment 3) * Pierre Muller's patches to fix display of tabulation character for mingw hosts, see https://sourceware.org/ml/gdb-patches/2013-11/msg00224.html Yuanhui Zhang -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On 2013-12-6 16:42, niXman wrote: Hi guys! I'm pleased to announce the new builds of MinGW-W64 based on the GCC-4.8.2 at rev.1. Changes from rev.0 is: - Binutils updated to 2.24 - MinGW-w64 v3 rev.6391 - Backport MinGW-w64 runtime commits from trunk to stable version: 6303: Fixed conflicts with xmmintrin.h. 6332: Install libvfw32.a once again 6385: Update shlwapi.def for Win7 32-bit 6386: Update shlwapi.def for Win7 64-bit 6390: Update shell32.def from Win7 - Update make to latest from git. - Fix installing gcc libraries for Python - Relocate c++ headers to target/include/c++ Links: Hi, thanks for your work. I just download this one: i686-4.8.2-release-posix-dwarf-rt_v3-rev1.7z I would like to use this GCC toolchain to build GDB with Python support. I was using the official Python Windows installer, and build GDB against the official Python dll, since the official Python was build with MSVC, and link against msvcr90.dll. The result GDB will have both link to msvcrt.dll and msvcr90.dll(indirectly through python27.dll), this may cause some potential problems since they have different c-run-time libraries. Now, I would try to link against the Python import library shipped with the MinGW-Build i686-4.8.2-release-posix-dwarf-rt_v3-rev1.7z. Question 1: I found that there are two .a files: libpython2.7.a and libpython2.7.dll.a, both under: \i686-4.8.2-release-posix-dwarf-rt_v3-rev1\mingw32\opt\lib\python2.7\config folder. So, which should I use? Question 2: I can't find the python header files. Question 3: When build GDB against official python installation, I just add some option to GDB toplevel configure like: --with-python=/python/python Where under MSYS, I have a mount that E:\code\python27/python (More details on how to build GDB can be found my own wiki page [1]) Note that E:\code\python27 is the folder I install the official python 2.7.x, so if I would like to link to the shipped python, what is the correct configure option? Question 4: What does https://github.com/niXman/mingw-builds/blob/master/sources/gdb-wrapper/gdb-wrapper.c used for? I vaguely remember you have some script code to rename the GDB.exe to some other name, and renamed gdb-wrapper.exe to GDB.exe. It does some PYTHONPATH related changes, but refer to Ruben's post here [2], it is quite safe to put the python27.dll along side the gdb.exe and put all the python script files under bin folder too. Thanks. Yuanhui Zhang [1] https://sourceforge.net/p/gdbmingw/wiki/Build%20GDB%20under%20MSYS/ [2] https://groups.google.com/d/msg/comp.lang.python/-DE5LmBbAC0/xv6q059ez-oJ -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On 2013-12-6 16:42, niXman wrote: Hi guys! I'm pleased to announce the new builds of MinGW-W64 based on the GCC-4.8.2 at rev.1. Changes from rev.0 is: - Binutils updated to 2.24 - MinGW-w64 v3 rev.6391 - Backport MinGW-w64 runtime commits from trunk to stable version: 6303: Fixed conflicts with xmmintrin.h. 6332: Install libvfw32.a once again 6385: Update shlwapi.def for Win7 32-bit 6386: Update shlwapi.def for Win7 64-bit 6390: Update shell32.def from Win7 - Update make to latest from git. - Fix installing gcc libraries for Python - Relocate c++ headers to target/include/c++ Another issue is that 32 bit GDB can't handle a inferior call of a non-static member function, so even a simple p v[0] command will fail if v is a std::vector. See this bug: GDB Bug 15559–Method call and calling convention https://sourceware.org/bugzilla/show_bug.cgi?id=15559 I have a nasty patch to handle/workaround this there(in the comment 8 of the above Bug report), hope it wil be helpful. Yuanhui Zhang -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On 2013-12-9 23:01, Alexpux wrote: 09 дек. 2013 г., в 18:48, asmwarrior asmwarrior-re5jqeeqqe8avxtiumw...@public.gmane.org mailto:asmwarrior-re5jqeeqqe8avxtiumw...@public.gmane.org написал(а): Hi, thanks for your work. I just download this one: i686-4.8.2-release-posix-dwarf-rt_v3-rev1.7z I would like to use this GCC toolchain to build GDB with Python support. Our toolchain has GDB builded with Python support. Thanks for the reply, but I just want to build GDB myself, because I have several local GDB patches (against GDB git head) to workaround some GDB issue under Windows. I was using the official Python Windows installer, and build GDB against the official Python dll, since the official Python was build with MSVC, and link against msvcr90.dll. The result GDB will have both link to msvcrt.dll and msvcr90.dll(indirectly through python27.dll), this may cause some potential problems since they have different c-run-time libraries. Now, I would try to link against the Python import library shipped with the MinGW-Build i686-4.8.2-release-posix-dwarf-rt_v3-rev1.7z. Question 1: I found that there are two .a files: libpython2.7.a and libpython2.7.dll.a, both under: \i686-4.8.2-release-posix-dwarf-rt_v3-rev1\mingw32\opt\lib\python2.7\config folder. So, which should I use? dll.a OK. Question 2: I can't find the python header files. toolchain/opt/include/python2.7 Well, I don't see a folder named include under the opt folder, is this a package error? Question 3: When build GDB against official python installation, I just add some option to GDB toplevel configure like: --with-python=/python/python Where under MSYS, I have a mount that E:\code\python27/python (More details on how to build GDB can be found my own wiki page [1]) Note that E:\code\python27 is the folder I install the official python 2.7.x, so if I would like to link to the shipped python, what is the correct configure option? https://github.com/Alexpux/mingw-builds/blob/develop/scripts/gdb.sh#L55-L78 To link with our Python you MUST add «-D__USE_MINGW_ANSI_STDIO=1» to CFLAGS and CXXFLAGS Thanks, I see, the related option is: --with-python=$PREFIX/opt/bin/python-config.sh Question 4: What does https://github.com/niXman/mingw-builds/blob/master/sources/gdb-wrapper/gdb-wrapper.c used for? I vaguely remember you have some script code to rename the GDB.exe to some other name, and renamed gdb-wrapper.exe to GDB.exe. It does some PYTHONPATH related changes, but refer to Ruben's post here [2], it is quite safe to put the python27.dll along side the gdb.exe and put all the python script files under bin folder too. This is wrapper to start GDB with Python from opt subfolder. OK, I see. BTW: Is it possible to include the expat and zlib library in MinGW-toolchain. If not, I need to build them before build GDB. Thanks. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On 2013-12-10 10:34, Alexpux wrote: Question 2: I can't find the python header files. toolchain/opt/include/python2.7 Well, I don't see a folder named include under the opt folder, is this a package error? This stuff is removed from toolchain. Thanks. Well this be fixed in the feature release? The shipped GDB in MinGW-Builds is build with -static-libgcc options which do not link to libgcc_s_dw2-1.dll (GDB default build options) But the shipped python27.dll was depend on libgcc_s_dw2-1.dll. I suggest that the python27.dll built with -static-libgcc too. BTW: Is it possible to include the expat and zlib library in MinGW-toolchain. If not, I need to build them before build GDB. zlib is already in toolchain. Expat you need to build itself. I search the zlib in MinGW-Build achieves, I get two match files: zlib.h under i686-4.8.2-release-posix-dwarf-rt_v3-rev1\mingw32\i686-w64-mingw32\include zlib1.dll under \i686-4.8.2-release-posix-dwarf-rt_v3-rev1\mingw32\opt\bin So, this is not enough to pass the configure test on zlib of GDB, I still need to build zlib, and install the import library. Thanks. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On 2013-12-10 11:19, Alexpux wrote: 10 дек. 2013 г., в 7:11, asmwarrior asmwarr...@gmail.com написал(а): On 2013-12-10 10:34, Alexpux wrote: Question 2: I can't find the python header files. toolchain/opt/include/python2.7 Well, I don't see a folder named include under the opt folder, is this a package error? This stuff is removed from toolchain. Thanks. Well this be fixed in the feature release? yes. Nice to hear. The shipped GDB in MinGW-Builds is build with -static-libgcc options which do not link to libgcc_s_dw2-1.dll (GDB default build options) But the shipped python27.dll was depend on libgcc_s_dw2-1.dll. I suggest that the python27.dll built with -static-libgcc too. Need to try. Ok, hope it will be done in the next release, thanks. BTW: Is it possible to include the expat and zlib library in MinGW-toolchain. If not, I need to build them before build GDB. zlib is already in toolchain. Expat you need to build itself. I search the zlib in MinGW-Build achieves, I get two match files: zlib.h under i686-4.8.2-release-posix-dwarf-rt_v3-rev1\mingw32\i686-w64-mingw32\include Yes. This is where it place. Also zlib static library libz.a in i686-4.8.2-release-posix-dwarf-rt_v3-rev1\mingw32\i686-w64-mingw32/lib zlib1.dll under \i686-4.8.2-release-posix-dwarf-rt_v3-rev1\mingw32\opt\bin So, this is not enough to pass the configure test on zlib of GDB, I still need to build zlib, and install the import library. Why not using zlib from i686-4.8.2-release-posix-dwarf-rt_v3-rev1\mingw32\i686-w64-mingw32? I would like to if the import zlib library exists, but as I have said before, there is no such library under: i686-4.8.2-release-posix-dwarf-rt_v3-rev1\mingw32\i686-w64-mingw32/lib So, I guess it was still removed from the tool-chain before the release? Thanks. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On 2013-12-10 12:46, Alexpux wrote: We provide only static library for zlib and it named «libz.a». Try to search… So, I guess it was still removed from the tool-chain before the release? No. It present. Oh, I found libz.a was there: i686-4.8.2-release-posix-dwarf-rt_v3-rev1\mingw32\i686-w64-mingw32\lib I'm sorry about my mistake! Yuanhui Zhang -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Press any key to continue...
On 2013-11-6 23:59, Incongruous wrote: I would like to remove the ‘Press any key to continue...’ from the console when using Code::Blocks, anyone? Ask this question on Codeblocks forum (http://forums.codeblocks.org) please. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
On 2013-10-20 3:29, Alexey Pavlov wrote: *ANNOUNCING* first GCC-4.8.2 builds with latest stable mingw-w64 runtime v3. Program *versions* in builds: 1. /GCC-4.8.2. / 2. /binutils-2.23.2. / 3. /mingw-w64 runtime rev.6346. / 4. /gdb-7.6.1. / 5. /python-2.7.5./ 6. /GNU Make 4.0 from git./ *GCC-4.8.2 *builded with bootstrap and next languages support: c,c++,ada,fortran,objc,obj-c++. *Links:* *32-bit:* posix-sjlj:i686-4.8.2-release-posix-sjlj-rt_v3-rev0.7z http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.8.2/threads-posix/sjlj/i686-4.8.2-release-posix-sjlj-rt_v3-rev0.7z/download posix-dwarf:i686-4.8.2-release-posix-dwarf-rt_v3-rev0.7z http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.8.2/threads-posix/dwarf/i686-4.8.2-release-posix-dwarf-rt_v3-rev0.7z/download win32-sjlj:i686-4.8.2-release-win32-sjlj-rt_v3-rev0.7z http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.8.2/threads-win32/sjlj/i686-4.8.2-release-win32-sjlj-rt_v3-rev0.7z/download win32-dwarf:i686-4.8.2-release-win32-dwarf-rt_v3-rev0.7z http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.8.2/threads-win32/dwarf/i686-4.8.2-release-win32-dwarf-rt_v3-rev0.7z/download *64-bit:* posix-sjlj:x86_64-4.8.2-release-posix-sjlj-rt_v3-rev0.7z http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.2/threads-posix/sjlj/x86_64-4.8.2-release-posix-sjlj-rt_v3-rev0.7z/download posix-seh : x86_64-4.8.2-release-posix-seh-rt_v3-rev0.7z http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4..8.2/threads-posix/seh/x86_64-4.8.2-release-posix-seh-rt_v3-rev0.7z/download win32-sjlj:x86_64-4.8.2-release-win32-sjlj-rt_v3-rev0.7z http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.2/threads-win32/sjlj/x86_64-4.8.2-release-win32-sjlj-rt_v3-rev0.7z/download win32-seh: x86_64-4.8.2-release-win32-seh-rt_v3-rev0.7z http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.2/threads-win32/seh/x86_64-4.8.2-release-win32-seh-rt_v3-rev0.7z/download *Toolchains sources:* src-4.8.2-release-rt_v3-rev0.tar.7z http://sourceforge.net/projects/mingw-w64/files/Toolchain%20sources/Personal%20Builds/mingw-builds/4.8.2/src-4.8.2-release-rt_v3-rev0.tar.7z/download *Build scripts:* https://github.com/niXman/mingw-builds Regards, Alexey. Hi, Thanks. So, in the feature, all the mingw-builds packages will be hold in http://sourceforge.net/projects/mingw-w64/files instead of mingw-builds site? Or is this an alternative mingw-builds release? Yuanhui Zhang -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2
On 2013-10-3 18:46, Alexey Pavlov wrote: New MSYS2 snapshots: 32-bit:x32-msys2-20131003.tar.xz http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-20131003.tar.xz/download 64-bit:x64-msys2-20131003.tar.xz http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-20131003.tar.xz/download *Changes*: Updates: - file-5.15; - m4-1.4.17; - texinfo-5.2; - vim-7.4.050. - GNU Make 3.99.93; Regards, Alexey. Thanks for your work. I see that the beta2 is removed from the package's name compared with the last release x32-msys2-beta2-20130909.tar.xz. So, this becomes finall stable release? Yuanhui Zhang -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Detecting libexpat library failed with undefined reference to _time32
On 2013-10-3 12:27, LRN wrote: Always use --build=i686-w64-mingw32 or --build=x86_64-w64-mingw32 when using mingw-w64 toolchains (obviously, for cross-toolchains you would use --host=i686-w64-mingw32 and --host=x86_64-w64-mingw32). - --build=mingw32 only works for mingw.org toolchains. [arch]-w64-mingw32 has other benefits too (at least at this moment; see the config.guess thread). Thanks for your explanation. I have just opened the config.log to see what is the benefits. But I can't see much. Here is the result of my build case: configure:3962: checking build system type configure:3976: result: i386-pc-mingw32 configure:3996: checking host system type configure:4009: result: i386-pc-mingw32 configure:4029: checking target system type configure:4042: result: i386-pc-mingw32 Do you mean that i686-w64-mingw32 will have better optimization code generated? (code instruction for i686, not i386) Thanks. Yuanhui Zhang -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Detecting libexpat library failed with undefined reference to _time32
Hi, I'm using D:\mingw-builds\x32-4.8.1-posix-dwarf-rev5 to build GDB under
MSYS.
I have manually download the iconv, zlib, expat, and build and install them to
/mingw.
(in fstab, I have a line: D:\mingw-builds\x32-4.8.1-posix-dwarf-rev5\mingw32
/mingw)
Now, I found that detecting expat library failed, this is the snippet of the
config.log:
configure:7888: checking for libexpat
configure:7907: mingw32-gcc -o conftest.exe -O0 -g -D__USE_MINGW_ACCESS
-I/mingw/include -static-libstdc++ -static-libgcc -Wl,--stack,12582912
conftest.c -lm/mingw/lib/libexpat.a 5
D:/mingw-builds/x32-4.8.1-posix-dwarf-rev5/mingw32/lib/libexpat.a(xmlparse.o):
In function `time':
d:/mingw-builds/x32-4.8.1-posix-dwarf-rev5/mingw32/i686-w64-mingw32/include/time.h:242:
undefined reference to `_time32'
collect2.exe: error: ld returned 1 exit status
configure:7907: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME
| #define PACKAGE_TARNAME
| #define PACKAGE_VERSION
| #define PACKAGE_STRING
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define __EXTENSIONS__ 1
| #define _ALL_SOURCE 1
| #define _GNU_SOURCE 1
| #define _POSIX_PTHREAD_SEMANTICS 1
| #define _TANDEM_SOURCE 1
| #define PACKAGE gdb
| #define DEBUGDIR /mingw/lib/debug
| #define DEBUGDIR_RELOCATABLE 1
| #define BINDIR /mingw/bin
| #define GDB_DATADIR /mingw/share/gdb
| #define GDB_DATADIR_RELOCATABLE 1
| #define AUTO_LOAD_DIR $debugdir:$datadir/auto-load
| #define AUTO_LOAD_SAFE_PATH $debugdir:$datadir/auto-load
| #define DEFAULT_BFD_ARCH bfd_i386_arch
| #define DEFAULT_BFD_VEC i386pe_vec
| #define PKGVERSION (GDB)
| #define REPORT_BUGS_TO http://www.gnu.org/software/gdb/bugs/
| #define HAVE_LIBM 1
| #define SIZEOF_UNSIGNED_LONG_LONG 8
| #define SIZEOF_UNSIGNED_LONG 4
| #define SIZEOF_UNSIGNED___INT128 0
| #define JIT_READER_DIR /mingw/lib/gdb
| #define JIT_READER_DIR_RELOCATABLE 1
| /* end confdefs.h. */
| #include expat.h
| int
| main ()
| {
| XML_Parser p = XML_ParserCreate (0);
| ;
| return 0;
| }
configure:7917: result: no
configure:7942: error: expat is missing or unusable
I just open the time.h:242, there is a line:
__CRT_INLINE time_t __cdecl time(time_t *_Time) { return _time32(_Time); }
Now, my question is: where does _time32 defined? How to solve my problem?
I'm working under Windows XP
Thanks
Yuanhui Zhang
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Detecting libexpat library failed with undefined reference to _time32
On 2013-10-3 3:15, Yaakov (Cygwin/X) wrote:
On 2013-10-02 13:55, LRN wrote:
On 02.10.2013 22:50, Alexey Pavlov wrote:
2013/10/2 LRN wrote:
(offtopic: it looks like a bug that gdb links to libexpat.a instead of
libexpat.dll.a)
FWIW, this also affects libiconv and libintl when building with NLS.
Why it a bug? I'm build GDB with static libexpat very often.
Because nothing htere indicates that it should be linked statically. It
should be linked statically when you make a static build, and linked
dynamically by default (or when it's clearly stated by configure or m4
macro that static libexpat is needed). I don't see any of that here
(though i have to admit that gdb configure system is one big mystery).
The problem is with lib-link.m4:AC_LIB_HAVE_LINKFLAGS macro and the old
config.rpath at the top of cygnus trees (binutils, gcc, gdb, cygwin, newlib).
Either use the attached patch when building any of these packages, or
configure then with --without-libiconv-prefix --without-libintl-prefix (and
for gdb, --without-libexpat-prefix).
Yaakov
Cygwin Ports
I configure gdb like:
../gdb/configure \
CFLAGS=-O0 -g \
--prefix=/mingw \
--host=mingw32 \
--build=mingw32 \
--target=mingw32 \
--with-python=/python/python \
--with-expat \
--disable-nls
I build iconv, zlib, expat library with --enable-static --disable-shared
option, and install them to /mingw, so I think your patch is not necessary in
my case, right?
I build gdb very often with such option, and it works OK with an old MinGW-w64
GCC 4.6.3, the failure happens when I try to build gdb with
mingw-builds\x32-4.8.1-posix-dwarf-rev5
I see the symbol __time32 is in the msvcrt library, here is the result:
$ nm -A --defined-only /mingw/i686-w64-mingw32/lib/*.a | grep _time32
D:/mingw-builds/x32-4.8.1-posix-dwarf-rev5/mingw32/i686-w64-mingw32/lib/libmsvcr
100.a:dcrfs01238.o: I __imp___time32
D:/mingw-builds/x32-4.8.1-posix-dwarf-rev5/mingw32/i686-w64-mingw32/lib/libmsvcr
100.a:dcrfs01238.o: T __time32
D:/mingw-builds/x32-4.8.1-posix-dwarf-rev5/mingw32/i686-w64-mingw32/lib/libmsvcr
110.a:dkhfs01310.o: I __imp___time32
D:/mingw-builds/x32-4.8.1-posix-dwarf-rev5/mingw32/i686-w64-mingw32/lib/libmsvcr
110.a:dkhfs01310.o: T __time32
D:/mingw-builds/x32-4.8.1-posix-dwarf-rev5/mingw32/i686-w64-mingw32/lib/libmsvcr
80.a:dkbgs00593.o: I __imp___time32
D:/mingw-builds/x32-4.8.1-posix-dwarf-rev5/mingw32/i686-w64-mingw32/lib/libmsvcr
80.a:dkbgs00593.o: T __time32
D:/mingw-builds/x32-4.8.1-posix-dwarf-rev5/mingw32/i686-w64-mingw32/lib/libmsvcr
90.a:daacs01070.o: I __imp___time32
D:/mingw-builds/x32-4.8.1-posix-dwarf-rev5/mingw32/i686-w64-mingw32/lib/libmsvcr
90.a:daacs01070.o: T __time32
D:/mingw-builds/x32-4.8.1-posix-dwarf-rev5/mingw32/i686-w64-mingw32/lib/libmsvcr
90d.a:dgpbs01133.o: I __imp___time32
D:/mingw-builds/x32-4.8.1-posix-dwarf-rev5/mingw32/i686-w64-mingw32/lib/libmsvcr
90d.a:dgpbs01133.o: T __time32
D:/mingw-builds/x32-4.8.1-posix-dwarf-rev5/mingw32/i686-w64-mingw32/lib/libmsvcr
t.a:desfs01239.o: I __imp___time32
D:/mingw-builds/x32-4.8.1-posix-dwarf-rev5/mingw32/i686-w64-mingw32/lib/libmsvcr
t.a:desfs01239.o: T __time32
D:\mingw-builds\x32-4.8.1-posix-dwarf-rev5\mingw32\bin\nm.exe: D:/mingw-builds/x
32-4.8.1-posix-dwarf-rev5/mingw32/i686-w64-mingw32/lib/libruntimeobject.a: File
format not recognized
BTW: the below code build successfully
#include time.h
int main() {
time_t t;
_time32(t);
}
I'm not sure the failure reason of detecting expat library in gdb.
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Detecting libexpat library failed with undefined reference to _time32
On 2013-10-3 9:50, asmwarrior wrote: I'm not sure the failure reason of detecting expat library in gdb. OK, I find the reason. There is another GCC in my system's PATH variable. Though the mouted /mingw has the high precedence in the PATH, but the configure script wrongly detect gcc in another GCC, not the one mouted /mingw. The reason is configure script first try to detect mingw32-gcc.exe, secondly gcc.exe. But x32-4.8.1-posix-dwarf-rev5\mingw32\bin does not have mingw32-gcc.exe, it has either gcc.exe and i686-w64-mingw32-gcc-4.8.1.exe. So, the mingw32-gcc.exe in another GCC was detected and used. After fixing the PATH, gdb build successfully now. I'm sorry about the noise in this maillist. Yuanhui Zhang -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2
On 2013-9-9 17:25, Alexey Pavlov wrote: New MSYS2 snapshots: 32-bit:x32-msys2-beta2-20130909.tar.xz http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-beta2-20130909.tar.xz/download 64-bit:x64-msys2-beta2-20130909.tar.xz http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-beta2-20130909.tar.xz/download *Changes*: Updates: - sync with Cygwin sources; - rewrite msys2_shell.bat and mingw_shell..bat to use mintty by default; - gettext-0.18.3.1; - subversion-1.8.3; - vim-7.4.016. New added: - docbook-xml (4.1-5.0); - posix-manpages; - unzip-6.0; - zip-3.0. Regards, Alexey. I see there are a lot of exe files under libexec\git-core have the same file size, does that by design? I extract msys2 by 7zip such as: git-prune.exe git-push.exe Oh, I see the same issue under PortableGit-1.8.3-preview20130601\libexec\git-core which is based on msys1 Yuanhui Zhang -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2
On 2013-7-10 1:21, Alexey Pavlov wrote: Upload new MSYS2 snapshots: 32-bit: x32-msys2-alpha-20130709.tar.xz http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130709.tar.xz/download 64-bit: x64-msys2-alpha-20130709.tar.xz http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-alpha-20130709.tar.xz/download Changes: - update git to 1.8.3.2; - update sed to 4.2.2; - update automake to 1.14; - update GNU Make to latest git snapshot; - update xz to 5.0.5; - add bashdb-4.2-0.8; Regards, Alexey. First, many thanks to your contribution. My suggestion is: Is it possible to include the vim in your packages, when I use the git tool, I need the vim (especially in git rebase -i interactive mode), the MSYSGit package do have vim. see: http://msysgit.googlecode.com/files/PortableGit-1.8.3-preview20130601.7z Another question is: Is it possible to fix the bug in Git-svn module, many people has reported it on msysgit site, but they said it's hard to update the Perl module, see my report and msysgit dev's reply here: https://groups.google.com/d/msg/msysgit/yWbGLFwTFuA/BU0MStkbEpgJ and https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions#subversion-is-too-old-for-git-svn-to-work-properly-cant-you-guys-keep-your-software-up-to-date. Thanks. Yuanhui Zhang -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2
On 2013-7-15 18:15, Alexey Pavlov wrote: Need to see how many dependencies it has. If not big then maybe I do it. E:\code\msys\PortableGit-1.8.3-preview20130601\share\vim\vim73\vim.exe It's dependency can be seen in attachment png image. Another question is: Is it possible to fix the bug in Git-svn module, many people has reported it on msysgit site, but they said it's hard to update the Perl module, see my report and msysgit dev's reply here: https://groups.google.com/d/msg/msysgit/yWbGLFwTFuA/BU0MStkbEpgJ and https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions#subversion-is-too-old-for-git-svn-to-work-properly-cant-you-guys-keep-your-software-up-to-date. Thanks. MSYS2 has subversion 1.8.0. Also git-svn script is on /libexec/git-core folder. Did you try it on MSYS2? I have tried, but failed like below: zyh23@zyh /d/test_msys2/git_local $ git svn clone file:///d:/test_msys2/svn_repo/ D:/test_msys/git_local/svn_r epo 3 [main] perl 9224 child_info_fork::abort: unable to remap msys-svn_diff-1 -0.dll to same address as parent (0xDE) - try running rebaseall 2 [main] perl 11780 child_info_fork::abort: unable to remap msys-svn_diff- 1-0.dll to same address as parent (0xDE) - try running rebaseall zyh23@zyh /d/test_msys2/git_local $ git svn clone file:///d:/test_msys2/svn_repo/ /d/test_msys/git_local/svn_r epo 2 [main] perl 12092 child_info_fork::abort: unable to remap msys-svn_diff- 1-0.dll to same address as parent (0xDE) - try running rebaseall zyh23@zyh /d/test_msys2/git_local $ git svn clone file:///d/test_msys2/svn_repo/ /d/test_msys/git_local/svn_re po 2 [main] perl 11956 child_info_fork::abort: unable to remap msys-svn_diff- 1-0.dll to same address as parent (0xDE) - try running rebaseall 2 [main] perl 4784 child_info_fork::abort: unable to remap msys-svn_diff-1 -0.dll to same address as parent (0xDE) - try running rebaseall zyh23@zyh /d/test_msys2/git_local $ Thanks Yuanhui Zhang attachment: vim_depends.png-- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2
On 2013-7-15 18:44, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15.07.2013 12:02, asmwarrior wrote: My suggestion is: Is it possible to include the vim in your packages, when I use the git tool, I need the vim (especially in git rebase -i interactive mode), the MSYSGit package do have vim. see: http://msysgit.googlecode.com/files/PortableGit-1.8.3-preview20130601.7z Having vim is ok, but you don't need to have it. You can configure git to use a different editor. I, for example, use Far Manager (you do need to write a script wrapper to call it correctly). Thanks, I have tried NotePad++ by the instruction by this link: http://stackoverflow.com/questions/10564/how-can-i-set-up-an-editor-to-work-with-git-on-windows It works fine. Yuanhui Zhang -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2
On 2013-7-15 22:28, Alexpux wrote: zyh23@zyh /d/test_msys2/git_local $ git svn clone file:///d/test_msys2/svn_repo/ /d/test_msys/git_local/svn_re po 2 [main] perl 11956 child_info_fork::abort: unable to remap msys-svn_diff- 1-0.dll to same address as parent (0xDE) - try running rebaseall 2 [main] perl 4784 child_info_fork::abort: unable to remap msys-svn_diff-1 -0.dll to same address as parent (0xDE) - try running rebaseall You need to rebase dlls. Open CMD and cd to MSYS/bin. Then run: dash /bin/rebaseall Hi, Alexpux, many thanks. I did that, and now git svn works OK, see the log: -- zyh23@zyh /d/test_msys2/git_local $ git svn clone file:///d/test_msys2/svn_repo/ D:/test_msys2/git_local/svn_r epo Initialized empty Git repository in /d/test_msys2/git_local/svn_repo/.git/ A a.txt r1 = c69d4171f52ef3a1f9b41637256665a6aaffc6c4 (refs/remotes/git-svn) Checked out HEAD: file:///d/test_msys2/svn_repo r1 zyh23@zyh /d/test_msys2/git_local $ ls svn_repo zyh23@zyh /d/test_msys2/git_local $ cd svn_repo zyh23@zyh /d/test_msys2/git_local/svn_repo $ git status # On branch master # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: a.txt # no changes added to commit (use git add and/or git commit -a) zyh23@zyh /d/test_msys2/git_local/svn_repo $ git commit -a -m hi [master aa63b4c] hi 1 file changed, 2 insertions(+), 1 deletion(-) zyh23@zyh /d/test_msys2/git_local/svn_repo $ git log commit aa63b4c2c0cb30ce09d02cdfc179bd6d5eaf93d5 Author: asmwarrior asmwarr...@gmail.com Date: Tue Jul 16 08:59:18 2013 +0800 hi commit c69d4171f52ef3a1f9b41637256665a6aaffc6c4 Author: zyh23 zyh23@d980fa90-3f2b-a94b-91d2-d8c81855ffcd Date: Mon Jul 15 11:27:01 2013 + add first file git-svn-id: file:///d/test_msys2/svn_repo@1 d980fa90-3f2b-a94b-91d2-d8c81855 zyh23@zyh /d/test_msys2/git_local/svn_repo $ git svn dcommit Committing to file:///d/test_msys2/svn_repo ... M a.txt Committed r2 M a.txt r2 = 75ddd7d7220f9ccb46ff59fd475b8e7cda785200 (refs/remotes/git-svn) No changes between aa63b4c2c0cb30ce09d02cdfc179bd6d5eaf93d5 and refs/remotes/git -svn Resetting to the latest refs/remotes/git-svn zyh23@zyh /d/test_msys2/git_local/svn_repo $ - NOTE: the below command does not work. (we should use d instread of d: when describe the svn address) $ git svn clone file:///d:/test_msys2/svn_repo/ D:/test_msys2/git_local/svn_r epo Now, I will report this good news to msysgit forum. Yuanhui Zhang -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] gdb is extremely slow
On 2013-6-8 2:44, Etienne Sandré-Chardonnal wrote: Dear all, I am using gcc 4.8.0 builds from ruben (seh version, 32 and 64 bits) gcc (version 7.5.91) is extremely slow, displaying the locals in some complex classes (MainWindow) in QtCreator takes a few minutes, fully unusable. Is there a workaround, and can this be related to links below, despite the fact I'm still using 7.5? http://sourceware.org/bugzilla/show_bug.cgi?id=15412 Hi, I have a workaround patch (Disable the python pretty printer for types) in the above link, you can try it and build GDB. I have a GDB build myself (32 bit), which contains this workaround, see: http://forums.codeblocks.org/index.php?topic=11301.0 http://sourceware.org/bugzilla/show_bug.cgi?id=15519 It looks like this bug is partially fixed in the GDB cvs? (See the above link) Asmwarrior -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Is it the gcc or mingw64 that cause the failure of wx building?
On 2013-6-6 14:01, zhangxinghai wrote: HI,recently I tried several mingw and mingw-w64 version to build wx 2.9.4 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb /gcc-4.8-release/i686-w64-mingw32-gcc-4.8.0-win32_rubenvb.7z/download ..failed mingw64+gcc4.8 When you say failed, you should tell us what's the failure log messages, also you should mention what's your make options. Thanks. -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] rubenvb's GCC 4.7.3 build
On 2013-5-5 20:26, Ruben Van Boxem wrote: Hi everyone, I am late to the party, I know, but I am now uploading GCC 4.7.3, built with: GCC 4.7.4 MinGW-w64 v2.0.8 binutils v2.23.2 gdb 7.5 Available at your local sourceforge mirror (still uploading at the time of this email): http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.7-release/ http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-4.7-release/ http://sourceforge.net/projects/mingw-w64/files/Toolchain%20sources/Personal%20Builds/rubenvb/release/ Next up is GCC 4.6.4, which is building now. Ruben I tested the one named i686-w64-mingw32-gcc-dw2-4.7.4-release-win32_rubenvb.7z under WinXP(sp3), but I see even a simple program will report an error like: ... _vswprintf could not be located in the dynamic link library msvcrt.dll. asmwarrior -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] seek a python library built from mingw/mingw64?
On 2012-12-13 12:42, Алексей Павлов wrote: Hi! You may download any toolchain that you need from https://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4..7.2 https://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.7.2. All toolchains since rev2 contains prebuilded Python-2.7.3 in opt subdirectory and gdb that in toolchain work with this python. Thanks for the info, I will try it. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] seek a python library built from mingw/mingw64?
On 2012-12-13 17:21, Václav Šmilauer wrote: Hi, when I run the gdb (python enabled) under drmemory, like: drmemory gdb.exe I see a lot of error reports regarding about memory error related to python dll, like below: (ERROR 3) Since I assume drmemory is something akin to valgrind, I can generally comment on its combination with Python. Python uses some smart techniques of managing its own memory (including reads from unititialized chunks) which look suspicicous to analysis programs. See http://svn.python.org/projects/python/trunk/Misc/README.valgrind for details. Ok, so drmemory may report some false-errors, which is not actually memory errors. I filed the issuehttp://bugs.python.org/issue16472 about msvcrt/msvcr90, but it is not (yet) conclusive. (Don't get me wrong I would be very glad if there were an official mingw-built version of python. I just wanted to say that the distributed MSVC binary works. HTH, Vaclav Hi, thanks. Sorry, I'm not quite understand your bug report on python site. As a conclusion, do you mean that it is safe to build/run a python-enabled gdb (under msys+mingw) which link to official python lib (msvcr90)? -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Any chance to update the MSYS package host in mingw64 site?
On 2012-12-11 19:27, niXman wrote: 2012/12/11 asmwarrior: I use this one: MSYS-2023.zip, and it was one year old. Thanks. https://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/ Hi, Thanks. I see you just updated the Msys packages in your site yesterday. Yuanhui Zhang -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] seek a python library built from mingw/mingw64?
Hi, when I run the gdb (python enabled) under drmemory, like: drmemory gdb.exe I see a lot of error reports regarding about memory error related to python dll, like below: (ERROR 3) .. Error #3: UNADDRESSABLE ACCESS: reading 0x03318010-0x03318014 4 byte(s) # 0 python27.dll!PyObject_Free +0xf (0x1e00f74f python27.dll+0xf74f) # 1 python27.dll!PyObject_Free +0x1a5(0x1e00f8e6 python27.dll+0xf8e6) # 2 python27.dll!PyLong_New+0x6b (0x1e00957a python27.dll+0x957a) # 3 python27.dll!PyMarshal_ReadLongFromFile+0x144(0x1e0271c7 python27.dll+0x271c7) # 4 python27.dll!PyMarshal_ReadLongFromFile+0x1c4(0x1e027247 python27.dll+0x27247) # 5 python27.dll!PyDict_DelItem+0x3a8(0x1e015729 python27.dll+0x15729) # 6 python27.dll!PyInstance_New+0x30e(0x1e01654f python27.dll+0x1654f) # 7 python27.dll!PyCFunction_Call +0x27 (0x1e015d18 python27.dll+0x15d18) # 8 python27.dll!PyEval_CallObjectWithKeywords +0x5e (0x1e015c8f python27.dll+0x15c8f) # 9 python27.dll!PyEval_EvalFrameEx+0x11f5 (0x1e012426 python27.dll+0x12426) #10 python27.dll!PyEval_EvalCodeEx +0x106(0x1e0106e7 python27.dll+0x106e7) #11 python27.dll!PyEval_EvalCode +0x1c (0x1e001e5d python27.dll+0x1e5d) Note: @0:00:05.859 in thread 189780 Note: next higher malloc: 0x03318660-0x033187f0 Note: 0x03318010-0x03318014 overlaps memory 0x03317b68-0x03318638 that was freed Note: instruction: mov0x10(%eax) - %edx . So, I suspect that this is caused that mingw use msvcrt.dll, but the python2.7.3 release was built from MSVC, so it has another kind of c runtime library. If possible, I need to build gdb which should link to a python libary(built from mingw). I see this: https://github.com/niXman/mingw-builds/tree/master/patches/Python-2.7.3 There are too many patches, and I even don't know how to build it. So, I wish there is a pre-build python library release from mingw/mingw64. Thanks. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Any chance to update the MSYS package host in mingw64 site?
I use this one: MSYS-2023.zip, and it was one year old. Thanks. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Debugging with GDB on Windows / MinGW is painfully slow
On 2012-7-21 15:07, Eran Ifrah wrote: On Sat, Jul 21, 2012 at 7:59 AM, asmwarrior asmwarrior-re5jqeeqqe8avxtiumw...@public.gmane.org mailto:asmwarr...@gmail.com wrote: On 2012-7-21 11:38, K. Frank wrote: As I mentioned above, my gdb version is 7.3.0. You can try a recent gdb (mostly the gdb build from gdb cvs HEAD) If anybody knows of a recent mingw or mingw-w64 build of gdb that addresses this issue, please chime in. You can try my build of gdb CVS (32bit) see: http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000 Thanks. There is one (minor?) problem with your gdb: it seems to requires python installation... and the binaries are quite huge I prefer the current MinGW way packing things: everything in a single directory and there is no need to alter 'PATH' not to mention that python pollutes C:\Windows\ ... (and other places?), which makes it hard to move around my working environment Yes, the gdb build by me has dependency on python 2.7, but in-fact, you don't need to put python.exe's path in your PATH environment. If I remember correctly, you can just copy python27.dll and the folder Lib, and maybe some msvcrt.dll to your MinGW/bin, the gdb should work fine. And I believe that using this way, the whole gdb package should be portable. I mean the official python27.dll was build from MSVC, so you need some MS crt dlls, besides that, python27.dll will automatically search its own library named Lib in the same folder. After such copying, you can safely uninstall your python distribution, because all you needed is copied to MinGW/bin. I'm just a little lazy to package my build gdb with such python files. On the bright side, your gdb seems to be the fastest from the all the gdb's I have tested so far. The thing that did the change was changing the workflow a littlet: * start gdb * break at main * place pending breakpoints * continue as opposed to: * start gdb * place pending breakpoints * continue The above two method should not have many difference from my point of view, I know a little about how gdb handling pending breakpoints, when a new dll loaded, gdb try to see the sources of the dll may matches the pending bps, so it mainly scan all the debug information in the dll. The more dll loaded, the more time you needed. BTW: I usually debug codeblocks(which have 10+ plugins as dlls) under gdb, I see gdb works just fine. (start up quite soon when you have pending bps) asmwarrior -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Mingw-users] Debugging with GDB on Windows / MinGW is painfully slow
On 2012-7-21 23:24, K. Frank wrote: There's one point I'm not certain of: I assume -- perhaps incorrectly -- that I will need a 64-bit build of gdb to debug 64-bit executables. As I understand it, the application being debugged runs in-process inside of gdb. Is this true, or can I freely mix a 32-bit gdb with 64-bit applications (and vice versa)? I have no experience of 64bit gdb nor 64bit executables. All of my system/application is 32bit. So, I can't say much, sorry. If I remember correct, there are some 64bit gdb from qt/qtcreator's site. asmwarrior -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Mingw-users] Debugging with GDB on Windows / MinGW is painfully slow
On 2012-7-21 11:38, K. Frank wrote: As I mentioned above, my gdb version is 7.3.0. You can try a recent gdb (mostly the gdb build from gdb cvs HEAD) If anybody knows of a recent mingw or mingw-w64 build of gdb that addresses this issue, please chime in. You can try my build of gdb CVS (32bit) see: http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000 asmwarrior -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Move asprintf and vasprintf into libmingwex.a instead of being inline funcions in stdio.h
On 2012-6-30 22:23, Ray Donnelly wrote: I've attached a fairly simple patch as requested by Kai on IRC which allows GDB to be compiled successfully. Good. I see this kind of build error several months ago when building GDB under MSYS. For me, I have a workaround, I just disable the nls support by passing the option --disable-nls to the configure, otherwise, I will see build errors. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Move asprintf and vasprintf into libmingwex.a instead of being inline funcions in stdio.h
On 2012-6-30 23:01, asmwarrior wrote: Good. I see this kind of build error several months ago when building GDB under MSYS. For me, I have a workaround, I just disable the nls support by passing the option --disable-nls to the configure, otherwise, I will see build errors. BTW, the build error of GDB I see is described in the wiki page: http://code.google.com/p/qp-gcc/wiki/build_gdb_msys_en gcc -s -static -mtune=i686 -D__USE_MINGW_ACCESS -I. -I../../gdb/gdb -I../../gdb/gdb/common -I../../gdb/gdb/config -DLOCALEDIR=\/E/test/installnew/share/locale\ -DHAVE_CONFIG_H -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../opcodes/.. -I../../gdb/gdb/../readline/.. -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../libdecnumber -I../../gdb/gdb/../libdecnumber -I../../gdb/gdb/gnulib -Ignulib-IF:/cb/python272/include -IF:/cb/python272/include -Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wno-format -Werror -c -o python.o -MT python.o -MMD -MP -MF .deps/python.Tpo -fno-strict-aliasing -DNDEBUG -fwrapv ../../gdb/gdb/python/python.c cc1.exe: warnings being treated as errors In file included from F:/cb/python272/include/Python.h:121:0, from ../../gdb/gdb/python/python-internal.h:50, from ../../gdb/gdb/python/python.c:48: F:/cb/python272/include/pyerrors.h:315:0: error: snprintf redefined d:\code\mingw_gcc4.5.4.20110428_static_win32\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.4/../../../../i686-pc-mingw32/include/libintl.h:375:0: note: this is the location of the previous definition F:/cb/python272/include/pyerrors.h:316:0: error: vsnprintf redefined d:\code\mingw_gcc4.5.4.20110428_static_win32\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.4/../../../../i686-pc-mingw32/include/libintl.h:380:0: note: this is the location of the previous definition I'm not sure your patch fix the conflict in the python header files. Thanks. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Fwd: [Qt-creator] [Development] mingw x64
On 2011-11-2 20:09, Pau Garcia i Quiles wrote: Hi, Ruben, do you know why gdb seems to be slow at the start of session? It seems to be the only thing preventing Qt and Qt Creator from adopting mingw-w64 as the official gcc toolchain on Windows and supporting x64. Thank you -- Forwarded message -- From: andy fillebrown andy.fillebrown-re5jqeeqqe8avxtiumw...@public.gmane.org Date: Wed, Nov 2, 2011 at 1:01 PM Subject: Re: [Qt-creator] [Development] mingw x64 To: Yves Bailly yves.bailly-6m3h0zxyszhqfi55v6+...@public.gmane.org Cc: qt-creator-x+mzmtya7i0kk94pdny...@public.gmane.org Howdy, FWIW, Qt and Qt Creator both built out of the box using Ruben's mingw w64 4.6.3 build, and the python based debugging helpers all seems to be working when debugging in Qt Creator, which is great! Gdb takes a long time to set breakpoints at the start of a session, though. I've seen this with other versions of mingw/gdb, too, so it's probably not a mingw w64 specific problem, but it keeps me from using mingw w64 as my main toolchain on Windows. For now I'm sticking with the mingw toolchain from the Qt sdk. Cheers, ~ andy.f On Wed, Nov 2, 2011 at 3:15 AM, Yves Bailly yves.bailly-6m3h0zxyszhqfi55v6+...@public.gmane.org wrote: Le 29/10/2011 14:14, Pau Garcia i Quiles a écrit : Another benefit of mingw-w64 is large file support via _FILE_OFFSET_BITS=64, which makes very easy to support cross-platform applications that deal with 2 GB files. No other MinGW flavor supports that, AFAIK. Let me second that, adding the fact that some of us poor developers for desktop sometime need to handle more than 4GB of RAM... not everyone is writing small-mobile-embeded apps ;-) Support for mingw-x64 is a long lasting and real need. About gdb working or not, for my own case it doesn't matter much. Regards, -- /- Yves Bailly - Software developper -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Qt-creator mailing list qt-creator-x+mzmtya7i0kk94pdny...@public.gmane.org http://lists.qt-project.org/mailman/listinfo/qt-creator Hi, I always meet the gdb slow start session problem, but have you ever try this patch: http://sourceware.org/ml/gdb-patches/2011-11/msg00141.html It looks like the comparison of files takes a lot of time if your app has many dll loading on the start up session. A related topic can be found here: Re: configure file to debug codecompletion plugin http://forums.codeblocks.org/index.php/topic,12951.msg87332.html#msg87332 Also, you can try my build gdb.exe, see: [OT] unofficial MinGW GDB gdb with python released - http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000 asmwarrior ollydbg from codeblocks' forum -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] gcc --enable-plugin experimental built on windows
This is a nice feature. The test result of plotting a top level declaration of a cpp file can be see in: http://sourceforge.net/mailarchive/message.php?msg_id=28248411 Sounds great! asmwarrior ollydbg from codeblocks' forum -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
