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 >>

[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

[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

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

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

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

Re: [Mingw-w64-public] [Project News | New Builds]

On 2013-12-10 11:19, Alexpux wrote: > > 10 дек. 2013 г., в 7:11, asmwarrior написал(а): > >> On 2013-12-10 10:34, Alexpux wrote: >>>>>> Question 2: >>>>>> I can't find the python header files. >>>>> /opt/include/python

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. >>> /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

Re: [Mingw-w64-public] [Project News | New Builds]

On 2013-12-9 23:01, Alexpux wrote: > > 09 дек. 2013 г., в 18:48, asmwarrior > <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

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: >

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: >

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. ---

Re: [Mingw-w64-public] [Project News | New Builds]

On 2013-10-20 17:46, niXman wrote: > Hi, > >> > 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? > Yes. > >> > Or is this an alternative mingw-builds release? > Read please: > https://sourcefo

Re: [Mingw-w64-public] MSYS2

On 2013-10-3 18:46, Alexey Pavlov wrote: > New MSYS2 snapshots: > > 32-bit:x32-msys2-20131003.tar.xz > > > 64-bit:x64-msys2-20131003.tar.xz >

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

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. > >

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

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

[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 librar

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 > > > 64-bit:x64-msys2-beta2-20130909.tar.xz >

Re: [Mingw-w64-public] MSYS2

ory) # # 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_loc

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

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 i

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 > > > 64-bit: x64-msys2-alpha-20130709.tar.xz >

Re: [Mingw-w64-public] gdb is extremely slow

y 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 cv

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 > .

Re: [Mingw-w64-public] rubenvb's GCC 4.7.3 build

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" i

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

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 > > . > All toolchains since rev

[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

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 i

[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 ef

Re: [Mingw-w64-public] Fwd: [Development] Choosing a new MinGW for Qt 5

On 2012-9-1 0:00, Loaden wrote: > 2012/8/31 K. Frank > > > Also, I've had a problem with recent versions of mingw-w64 gdb. It's slow > as molasses loading up and/or initializing an application (minutes), but > once the application starts, it seems to be fi

Re: [Mingw-w64-public] [Mingw-users] Debugging with GDB on Windows / MinGW is painfully slow

b. 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

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 > <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. > > > >> >

Re: [Mingw-w64-public] [Mingw-users] Debugging with GDB on Windows / MinGW is painfully slow

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 s

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 > b

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 suppor

Re: [Mingw-w64-public] Fwd: [Qt-creator] [Development] mingw x64

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.

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'