On Sat, Apr 21, 2012 at 10:06 PM, andy fillebrown
wrote:
>> my bad, fixed:
>> https://builds.qt-project.org/job/gdb-windows/53/artifact/build-creator-gdb-mingw/qtcreator-gdb-7.4-MINGW32_NT-6.1-i686.tar.gz
>
> This works well. No breakpoint or callstack issues. Unfortunately,
> the debugging hel
On Sat, Apr 21, 2012 at 11:38 AM, wrote:
>
> On Apr 21, 2012, at 01:07 , ext André Pönitz wrote:
>> This is
>>
>> https://bugreports.qt-project.org/browse/QTCREATORBUG-5200
>>
>>
>> There had been rumours that this was solved in (really) recent gdb
>> builds like the ones that are intended to
On Apr 21, 2012, at 01:07 , ext André Pönitz wrote:
> This is
>
>https://bugreports.qt-project.org/browse/QTCREATORBUG-5200
>
>
> There had been rumours that this was solved in (really) recent gdb
> builds like the ones that are intended to be shipped with Creator 2.5.
>
> In theory, these
On Fri, Apr 20, 2012 at 7:07 PM, André Pönitz
wrote:
> On Fri, Apr 20, 2012 at 06:33:54PM -0400, andy fillebrown wrote:
>> Here are some attachments from a run using Creator 2.5 beta. The
>> project was built with the mingwbuild containing gcc 4.6.2 and gdb
>> 7.4. The .txt and .png suffixed wit
The make command in cygwin no longer support Dos-style pathname since make
v3.81. Mingw-w64 needs to be shipped with mingw32-make in windows.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Fri, Apr 20, 2012 at 06:33:54PM -0400, andy fillebrown wrote:
> Here are some attachments from a run using Creator 2.5 beta. The
> project was built with the mingwbuild containing gcc 4.6.2 and gdb
> 7.4. The .txt and .png suffixed with "call-stack" are the debugger
> log and a screen-capture
On Fri, Apr 20, 2012 at 3:23 PM, André Pönitz
wrote:
> On Fri, Apr 20, 2012 at 03:08:01PM -0400, andy fillebrown wrote:
>> [...]
>> GCC 4.6.2 and 4.7.0 from mingwbuilds do not have the slow startup
>> problem. There are still two issues, though.
>
> I still don't think the gcc matters much in thi
On Fri, Apr 20, 2012 at 03:08:01PM -0400, andy fillebrown wrote:
> [...]
> GCC 4.6.2 and 4.7.0 from mingwbuilds do not have the slow startup
> problem. There are still two issues, though.
I still don't think the gcc matters much in this case. gdb version
certainly does.
> 1) Breakpoints have to
On Fri, Apr 20, 2012 at 8:07 AM, André Pönitz
wrote:
> On Fri, Apr 20, 2012 at 11:19:50AM +0200, Pau Garcia i Quiles wrote:
>> On Fri, Apr 20, 2012 at 11:12 AM, andy fillebrown
>> wrote:
>> > On Fri, Apr 20, 2012 at 2:01 AM, André Pönitz
>> > wrote:
>> >> On Thu, Apr 19, 2012 at 10:34:21PM -0400
On Fri, Apr 20, 2012 at 11:19:50AM +0200, Pau Garcia i Quiles wrote:
> On Fri, Apr 20, 2012 at 11:12 AM, andy fillebrown
> wrote:
> > On Fri, Apr 20, 2012 at 2:01 AM, André Pönitz
> > wrote:
> >> On Thu, Apr 19, 2012 at 10:34:21PM -0400, andy fillebrown wrote:
> >>> I would add to the "proper com
Now wait a minute, I never said such a thing.
I said that the MinGW-w64 binaries are Cygwin-based now. Meaning, the
MinGW they release needs Cygwin DLLs to run.
The output they generate is still native Win32 binaries, which does
_not_ require Cygwin. (Anything else would be silly, since you cou
Hi,
I'd say you are confusing "mingw-w64 is available in Cygwin" (like
mingw.org is) with "mingw-w64-produced binaries need Cygwin DLLs".
I've been using mingw-w64 for zsync on Windows (
https://www.assembla.com/spaces/zsync-windows ) for quite some time
and the zsync.exe and zysncmake.exe binari
Take another look. They haven't produced pure MinGW binary releases
since the end of 2011. The front page says "The mingw-w64 toolchain has
been officially added to Cygwin mirrors", and when you look under the
"Releases" (and then under "Automated Builds") section to the left on
the front page,
On Fri, Apr 20, 2012 at 11:12 AM, andy fillebrown
wrote:
> On Fri, Apr 20, 2012 at 2:01 AM, André Pönitz
> wrote:
>> On Thu, Apr 19, 2012 at 10:34:21PM -0400, andy fillebrown wrote:
>>> I would add to the "proper compiler" list the ability to set debug
>>> breakpoints quickly and proper display o
On Fri, Apr 20, 2012 at 2:01 AM, André Pönitz
wrote:
> On Thu, Apr 19, 2012 at 10:34:21PM -0400, andy fillebrown wrote:
>> I would add to the "proper compiler" list the ability to set debug
>> breakpoints quickly and proper display of call stacks across .dll
>> boundaries. IMO those are the two t
On Thu, Apr 19, 2012 at 10:34:21PM -0400, andy fillebrown wrote:
> I would add to the "proper compiler" list the ability to set debug
> breakpoints quickly and proper display of call stacks across .dll
> boundaries. IMO those are the two things that bug me the most about
> the "distros" already me
No, MinGW-w64 doesn't depend on Cygwin.
http://openfoamwiki.net/index.php/Tip_Cross_Compiling_OpenFOAM_in_Linux_For_Windows_with_MinGW#Differences_between_mingw32_and_mingw-w32_versions
Mingw-w64 began as a spin-off from the mingw.org project, with the
original intent of building for 64-bit targe
On 19/04/2012 17:06, ext 1+1=2 wrote:
>> From the homepage of project, http://mingwbuilds.sourceforge.net/
>
>This is the MinGW-builds project ("mingwbuilds")
>This project was registered on SourceForge.net on Mar 30, 2012, and
> is described by the project team as follows:
>Snapshots a
I would add to the "proper compiler" list the ability to set debug
breakpoints quickly and proper display of call stacks across .dll
boundaries. IMO those are the two things that bug me the most about
the "distros" already mentioned. Waiting 2+ minutes for the debugger
to start, and then not bein
Hi,
>From the homepage of project, http://mingwbuilds.sourceforge.net/
This is the MinGW-builds project ("mingwbuilds")
This project was registered on SourceForge.net on Mar 30, 2012, and
is described by the project team as follows:
Snapshots and releases builds of the MinGW compiler that u
If you click the link in Daniels initial email, and onto the windows host
directory, you would see that the have both the 4.7.0 release and the 4.7.1
prerelease as binaries already.
--
Sent from my Nokia N9
On 4/19/12 16:14 ext Mark wrote:
2012/4/19
Hi Everyone,
After several complains from
2012/4/19 :
> After several complains from the community that GCC 4.4 shipped with both
> Creator and the Qt SDK is fairly outdated (and not C++11 compliant), we are
> going to ship a mingw.org-based GCC 4.6.2 with the next Qt Creator release.
> Even though we verified that this works with the Min
2012/4/19
> Hi Everyone,
>
> ** **
>
> After several complains from the community that GCC 4.4 shipped with both
> Creator and the Qt SDK is fairly outdated (and not C++11 compliant), we are
> going to ship a mingw.org-based GCC 4.6.2 with the next Qt Creator release.
> Even though we verifi
Hi Everyone,
After several complains from the community that GCC 4.4 shipped with both
Creator and the Qt SDK is fairly outdated (and not C++11 compliant), we are
going to ship a mingw.org-based GCC 4.6.2 with the next Qt Creator release.
Even though we verified that this works with the MinGW 4
24 matches
Mail list logo
