Re: [Mingw-w64-public] GDB version information for ruben vb build
Hi Abir, Qt Project official releases are currently using mingw-builds toolchain releases which includes Python with pretty-printers. Also, mingw-builds project build their own (comprehensive) Qt releases. The toolchain that's likely to be used in 5.1.0 is (I think): http://heanet.dl.sourceforge.net/project/mingwbuilds/host-windows/releases/4.8.0/32-bit/threads-posix/dwarf/x32-4.8.0-release-posix-dwarf-rev2.7z . The URL for mingw-builds Qt-builds releases is: On Mon, Jun 3, 2013 at 5:47 AM, Abir Basak wrote: > I was using build by Ruben for Mingw W64 for long times with Qt Creator > IDE. However from version 2.7 onward it fails to debug using the gdb > shipped by it. The reason is most likely that it fails to parse the gdb > version information like GNU gdb (rubenvb-4.7.2-release) > 7.5.50.20120920-cvs (Or rather wrongly parses the gdb version as 4.7.2 and > disables most of gdb features like python support :( ) > My question is , is there any guidelines for what gdb version string > should look like? > > Thanks > abir > > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ 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 version information for ruben vb build
Sorry, gmail fail (Enter Key caused a Send rather than a newline..) The URL for mingw-builds Qt-builds releases is: http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/Qt-Builds/ On Mon, Jun 3, 2013 at 8:11 AM, Ray Donnelly wrote: > Hi Abir, > > Qt Project official releases are currently using mingw-builds toolchain > releases which includes Python with pretty-printers. Also, mingw-builds > project build their own (comprehensive) Qt releases. > > The toolchain that's likely to be used in 5.1.0 is (I think): > > > http://heanet.dl.sourceforge.net/project/mingwbuilds/host-windows/releases/4.8.0/32-bit/threads-posix/dwarf/x32-4.8.0-release-posix-dwarf-rev2.7z > . > > The URL for mingw-builds Qt-builds releases is: > > > > > > On Mon, Jun 3, 2013 at 5:47 AM, Abir Basak wrote: > >> I was using build by Ruben for Mingw W64 for long times with Qt Creator >> IDE. However from version 2.7 onward it fails to debug using the gdb >> shipped by it. The reason is most likely that it fails to parse the gdb >> version information like GNU gdb (rubenvb-4.7.2-release) >> 7.5.50.20120920-cvs (Or rather wrongly parses the gdb version as 4.7.2 and >> disables most of gdb features like python support :( ) >> My question is , is there any guidelines for what gdb version string >> should look like? >> >> Thanks >> abir >> >> >> -- >> Get 100% visibility into Java/.NET code with AppDynamics Lite >> It's a free troubleshooting tool designed for production >> Get down to code-level detail for bottlenecks, with <2% overhead. >> Download for free and get started troubleshooting in minutes. >> http://p.sf.net/sfu/appdyn_d2d_ap2 >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> >> > -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ 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 version information for ruben vb build
2013/6/3 Abir Basak
> I was using build by Ruben for Mingw W64 for long times with Qt Creator
> IDE. However from version 2.7 onward it fails to debug using the gdb
> shipped by it. The reason is most likely that it fails to parse the gdb
> version information like GNU gdb (rubenvb-4.7.2-release)
> 7.5.50.20120920-cvs (Or rather wrongly parses the gdb version as 4.7.2 and
> disables most of gdb features like python support :( )
> My question is , is there any guidelines for what gdb version string
> should look like?
>
I have just tried with
x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb
Qt Creator 2.7.1
CMake 2.8.11
on a clean system, to create a small test app
#include
using namespace std;
int main()
{
int i=4;
int j= i+4;
i = j-4;
cout << "Hello World!" << endl;
return 0;
}
built with
cmake -DCMAKE_BUILD_TYPE=Debug
mingw32-make
and set a break point in Qt Creator at the "i=j-4" line, and execution
stopped. I could see the values of i and j displayed.
What exactly are you doing and what "fails"?
Remember to set up gdb and your toolchain in Tools->Options->Build&Run
both under Compilers and Kits (set your sysroot and click on
auto-detect for the Debugger line).
Hope this helps,
Ruben
> Thanks
> abir
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
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 version information for ruben vb build (Ruben Van Boxem)
>
> > I was using build by Ruben for Mingw W64 for long times with Qt Creator
> > IDE. However from version 2.7 onward it fails to debug using the gdb
> > shipped by it. The reason is most likely that it fails to parse the gdb
> > version information like GNU gdb (rubenvb-4.7.2-release)
> > 7.5.50.20120920-cvs (Or rather wrongly parses the gdb version as 4.7.2
> and
> > disables most of gdb features like python support :( )
> > My question is , is there any guidelines for what gdb version string
> > should look like?
> >
>
> I have just tried with
>
> x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb
> Qt Creator 2.7.1
> CMake 2.8.11
>
> on a clean system, to create a small test app
>
> #include
>
>
> using namespace std;
>
>
> int main()
>
> {
>
> int i=4;
>
> int j= i+4;
>
> i = j-4;
>
> cout << "Hello World!" << endl;
>
> return 0;
>
> }
>
>
> built with
>
> cmake -DCMAKE_BUILD_TYPE=Debug
>
> mingw32-make
>
> and set a break point in Qt Creator at the "i=j-4" line, and execution
> stopped. I could see the values of i and j displayed.
>
> What exactly are you doing and what "fails"?
>
> Remember to set up gdb and your toolchain in Tools->Options->Build&Run
> both under Compilers and Kits (set your sysroot and click on
> auto-detect for the Debugger line).
>
> Hope this helps,
>
> Ruben
>
>
> I did the same, However debugging does not work :(
What does NOT work =>
locals and expressions or stack windows does NOT automatically
load/update on stepping. i.e each time you need to manually click "reload
full stack" to see the updated values.
Breakpoint & stepping does work.
It did work (and still works) with Qt Creator 2.6.2 last, and not any
release after that (i.e QtC 2.7.0, 2.7.1 & 2.8.0 beta)
All version of QtC also works with mingw builds gdb.
I presently do NOT use mingw builds as sometimes I get strange problems
with that dual target build (specifically when I use it with
boost.unit_test). I do NOT use Qt, I use Qt Creator just for my c++
projects with cmake or generic makefile project.
In the debugger log window it shows UNSUPPORTED GDB VERSION GNU gdb
(rubenvb-4.8.0) 7.5.91.20130322-cvs
If you look at the code which detect gdb version (extractGdbVersion
in debuggerprotocol.cpp ) , it returns wrong gdb version as 4.8.0 rather
than 7.5.91 , i.e. wrongly takes the version from bracketed gcc build
information). Though that may or may not be the cause of problem.
I have tested it with
x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb.7z (and also 4.7.2 and others)
QtC 2.7.1 (Build on 8th May 2013) QtC 2.7.0 and QtC 2.8.0 beta official
builds
On Windows 7 and Windows 8
>
> > Thanks
> > abir
> >
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
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 version information for ruben vb build (Ruben Van Boxem)
It seems clear to me that you should submit a patch that fixes this to Qt
Project, and also if possible file the boost unit_test issue with the
mingw-builds project.
On Mon, Jun 3, 2013 at 9:56 AM, Abir Basak wrote:
>
>
>> > I was using build by Ruben for Mingw W64 for long times with Qt Creator
>> > IDE. However from version 2.7 onward it fails to debug using the gdb
>> > shipped by it. The reason is most likely that it fails to parse the gdb
>> > version information like GNU gdb (rubenvb-4.7.2-release)
>> > 7.5.50.20120920-cvs (Or rather wrongly parses the gdb version as 4.7.2
>> and
>> > disables most of gdb features like python support :( )
>> > My question is , is there any guidelines for what gdb version string
>> > should look like?
>> >
>>
>> I have just tried with
>>
>> x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb
>> Qt Creator 2.7.1
>> CMake 2.8.11
>>
>> on a clean system, to create a small test app
>>
>> #include
>>
>>
>> using namespace std;
>>
>>
>> int main()
>>
>> {
>>
>> int i=4;
>>
>> int j= i+4;
>>
>> i = j-4;
>>
>> cout << "Hello World!" << endl;
>>
>> return 0;
>>
>> }
>>
>>
>> built with
>>
>> cmake -DCMAKE_BUILD_TYPE=Debug
>>
>> mingw32-make
>>
>> and set a break point in Qt Creator at the "i=j-4" line, and execution
>> stopped. I could see the values of i and j displayed.
>>
>> What exactly are you doing and what "fails"?
>>
>> Remember to set up gdb and your toolchain in Tools->Options->Build&Run
>> both under Compilers and Kits (set your sysroot and click on
>> auto-detect for the Debugger line).
>>
>> Hope this helps,
>>
>> Ruben
>>
>>
>> I did the same, However debugging does not work :(
> What does NOT work =>
> locals and expressions or stack windows does NOT automatically
> load/update on stepping. i.e each time you need to manually click "reload
> full stack" to see the updated values.
> Breakpoint & stepping does work.
>
> It did work (and still works) with Qt Creator 2.6.2 last, and not any
> release after that (i.e QtC 2.7.0, 2.7.1 & 2.8.0 beta)
>
> All version of QtC also works with mingw builds gdb.
> I presently do NOT use mingw builds as sometimes I get strange problems
> with that dual target build (specifically when I use it with
> boost.unit_test). I do NOT use Qt, I use Qt Creator just for my c++
> projects with cmake or generic makefile project.
>
> In the debugger log window it shows UNSUPPORTED GDB VERSION GNU gdb
> (rubenvb-4.8.0) 7.5.91.20130322-cvs
> If you look at the code which detect gdb version (extractGdbVersion
> in debuggerprotocol.cpp ) , it returns wrong gdb version as 4.8.0 rather
> than 7.5.91 , i.e. wrongly takes the version from bracketed gcc build
> information). Though that may or may not be the cause of problem.
>
> I have tested it with
> x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb.7z (and also 4.7.2 and others)
> QtC 2.7.1 (Build on 8th May 2013) QtC 2.7.0 and QtC 2.8.0 beta official
> builds
> On Windows 7 and Windows 8
>
>
>>
>> > Thanks
>> > abir
>> >
>>
>>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] InterlockedBitTestAndXXX
On Mon, Jun 3, 2013 at 12:26 AM, dw wrote: > I have found some problems with the InterlockedBitTestAndXXX functions. For > example: > > - Despite sezero's recent update, they still don't all have the "memory" > clobber. > - The constraints for the 64bit versions are incorrect (I vs J). > - There is no library definition for interlockedbittestandcomplement64. > > For these reasons (among others), I have created the attached patch. > Specifically it includes: > > Fixes for: > InterlockedBitTestAndSet, InterlockedBitTestAndReset, > InterlockedBitTestAndComplement, > InterlockedBitTestAndSet64, InterlockedBitTestAndReset64, > InterlockedBitTestAndComplement64 > _interlockedbittestandset, _interlockedbittestandreset, > _interlockedbittestandcomplement > _interlockedbittestandset64, _interlockedbittestandreset64, > _interlockedbittestandcomplement64 > > - While sezero recently added the (required) "memory" clobber to a number of > the InterlockedBitTestXXX methods, he didn't get all of them. Using the > macro for defining these methods makes them all consistent. > - The Bit parameter uses the "I" constraint on both 32bit and 64bit. 64bit > should use "J". > - Use symbolic names for asm statement for clarity. > - Support both att and intel dialects of assembler in public headers. > - InterlockedBitTestAndSet and _interlockedbittestandset were mapped to each > other via #define. However they should have different prototypes. This > patch declares InterlockedBitTestAndSet (and related) with p1 as volatile, > which is consistent with the MSVC definition. In the crt, these are > implemented with 'alias.' The inlines both use the same macro. > - Adds declarations for all methods in intrin.h. > - There was no library definition for interlockedbittestandcomplement64. > This required a new file. > - As with my other recent patches, this one uses macros so all > implementations (winnt.h and crt) use the same code. > > Cleanup: > - My previous patches have been using the cpp comment style (//). I have > replaced that with c style (/* */) to be consistent with the rest of the > file. > - I have renamed the file macro for intrin-mac.h from _INTRIN-MAC_ to > _INTRIN_MAC_. I'm not sure why this ever worked. > - I have added comments to intrin-mac.h describing the parameters for the > macros from previous patches. > > dw If you can prepare patches for your recent asm stuff against the stable branch, I would happily merge. -- O.S. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ 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 version information for ruben vb build (Ruben Van Boxem)
2013/6/3 Ray Donnelly
> It seems clear to me that you should submit a patch that fixes this to Qt
> Project, and also if possible file the boost unit_test issue with the
> mingw-builds project.
>
>
I took the liberty to submit a bug report to the Qt Project:
https://bugreports.qt-project.org/browse/QTCREATORBUG-9452
If any Qt guys are reading this, I'll be very happy if this is bumped to
anywhere but the bottom of the stack ;-)
Cheers,
Ruben
>
> On Mon, Jun 3, 2013 at 9:56 AM, Abir Basak wrote:
>
>>
>>
>>> > I was using build by Ruben for Mingw W64 for long times with Qt Creator
>>> > IDE. However from version 2.7 onward it fails to debug using the gdb
>>> > shipped by it. The reason is most likely that it fails to parse the gdb
>>> > version information like GNU gdb (rubenvb-4.7.2-release)
>>> > 7.5.50.20120920-cvs (Or rather wrongly parses the gdb version as 4.7.2
>>> and
>>> > disables most of gdb features like python support :( )
>>> > My question is , is there any guidelines for what gdb version string
>>> > should look like?
>>> >
>>>
>>> I have just tried with
>>>
>>> x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb
>>> Qt Creator 2.7.1
>>> CMake 2.8.11
>>>
>>> on a clean system, to create a small test app
>>>
>>> #include
>>>
>>>
>>> using namespace std;
>>>
>>>
>>> int main()
>>>
>>> {
>>>
>>> int i=4;
>>>
>>> int j= i+4;
>>>
>>> i = j-4;
>>>
>>> cout << "Hello World!" << endl;
>>>
>>> return 0;
>>>
>>> }
>>>
>>>
>>> built with
>>>
>>> cmake -DCMAKE_BUILD_TYPE=Debug
>>>
>>> mingw32-make
>>>
>>> and set a break point in Qt Creator at the "i=j-4" line, and execution
>>> stopped. I could see the values of i and j displayed.
>>>
>>> What exactly are you doing and what "fails"?
>>>
>>> Remember to set up gdb and your toolchain in Tools->Options->Build&Run
>>> both under Compilers and Kits (set your sysroot and click on
>>> auto-detect for the Debugger line).
>>>
>>> Hope this helps,
>>>
>>> Ruben
>>>
>>>
>>> I did the same, However debugging does not work :(
>> What does NOT work =>
>> locals and expressions or stack windows does NOT automatically
>> load/update on stepping. i.e each time you need to manually click "reload
>> full stack" to see the updated values.
>> Breakpoint & stepping does work.
>>
>> It did work (and still works) with Qt Creator 2.6.2 last, and not any
>> release after that (i.e QtC 2.7.0, 2.7.1 & 2.8.0 beta)
>>
>> All version of QtC also works with mingw builds gdb.
>> I presently do NOT use mingw builds as sometimes I get strange problems
>> with that dual target build (specifically when I use it with
>> boost.unit_test). I do NOT use Qt, I use Qt Creator just for my c++
>> projects with cmake or generic makefile project.
>>
>> In the debugger log window it shows UNSUPPORTED GDB VERSION GNU gdb
>> (rubenvb-4.8.0) 7.5.91.20130322-cvs
>> If you look at the code which detect gdb version (extractGdbVersion
>> in debuggerprotocol.cpp ) , it returns wrong gdb version as 4.8.0 rather
>> than 7.5.91 , i.e. wrongly takes the version from bracketed gcc build
>> information). Though that may or may not be the cause of problem.
>>
>> I have tested it with
>> x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb.7z (and also 4.7.2 and
>> others)
>> QtC 2.7.1 (Build on 8th May 2013) QtC 2.7.0 and QtC 2.8.0 beta official
>> builds
>> On Windows 7 and Windows 8
>>
>>
>>>
>>> > Thanks
>>> > abir
>>> >
>>>
>>>
>>
>>
>> --
>> Get 100% visibility into Java/.NET code with AppDynamics Lite
>> It's a free troubleshooting tool designed for production
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>> http://p.sf.net/sfu/appdyn_d2d_ap2
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>>
>
>
> --
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Mingw-w64-public mailing list
Re: [Mingw-w64-public] Mingw-w64-public Digest, Vol 69, Issue 5
> It seems clear to me that you should submit a patch that fixes this to Qt
> Project, and also if possible file the boost unit_test issue with the
> mingw-builds project.
>
> I will try to do so (It is kind of hard for an IDE user to submit IDE
patch :( ). And that is why I asked the (original) question
"is there any guidelines for what gdb version string should look like?" as
reply to my post in Qt Creator mailing list suggests to "ask the person
providing that GDB build to not patch the version
string, or at least to not deviate too much from what other distributions
do" :)
cheers
abir
>> > I was using build by Ruben for Mingw W64 for long times with Qt Creator
> >> > IDE. However from version 2.7 onward it fails to debug using the gdb
> >> > shipped by it. The reason is most likely that it fails to parse the
> gdb
> >> > version information like GNU gdb (rubenvb-4.7.2-release)
> >> > 7.5.50.20120920-cvs (Or rather wrongly parses the gdb version as 4.7.2
> >> and
> >> > disables most of gdb features like python support :( )
> >> > My question is , is there any guidelines for what gdb version string
> >> > should look like?
> >> >
> >>
> >> I have just tried with
> >>
> >> x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb
> >> Qt Creator 2.7.1
> >> CMake 2.8.11
> >>
> >> on a clean system, to create a small test app
> >>
> >> #include
> >>
> >>
> >> using namespace std;
> >>
> >>
> >> int main()
> >>
> >> {
> >>
> >> int i=4;
> >>
> >> int j= i+4;
> >>
> >> i = j-4;
> >>
> >> cout << "Hello World!" << endl;
> >>
> >> return 0;
> >>
> >> }
> >>
> >>
> >> built with
> >>
> >> cmake -DCMAKE_BUILD_TYPE=Debug
> >>
> >> mingw32-make
> >>
> >> and set a break point in Qt Creator at the "i=j-4" line, and execution
> >> stopped. I could see the values of i and j displayed.
> >>
> >> What exactly are you doing and what "fails"?
> >>
> >> Remember to set up gdb and your toolchain in Tools->Options->Build&Run
> >> both under Compilers and Kits (set your sysroot and click on
> >> auto-detect for the Debugger line).
> >>
> >> Hope this helps,
> >>
> >> Ruben
> >>
> >>
> >> I did the same, However debugging does not work :(
> > What does NOT work =>
> > locals and expressions or stack windows does NOT automatically
> > load/update on stepping. i.e each time you need to manually click "reload
> > full stack" to see the updated values.
> > Breakpoint & stepping does work.
> >
> > It did work (and still works) with Qt Creator 2.6.2 last, and not any
> > release after that (i.e QtC 2.7.0, 2.7.1 & 2.8.0 beta)
> >
> > All version of QtC also works with mingw builds gdb.
> > I presently do NOT use mingw builds as sometimes I get strange problems
> > with that dual target build (specifically when I use it with
> > boost.unit_test). I do NOT use Qt, I use Qt Creator just for my c++
> > projects with cmake or generic makefile project.
> >
> > In the debugger log window it shows UNSUPPORTED GDB VERSION GNU gdb
> > (rubenvb-4.8.0) 7.5.91.20130322-cvs
> > If you look at the code which detect gdb version (extractGdbVersion
> > in debuggerprotocol.cpp ) , it returns wrong gdb version as 4.8.0 rather
> > than 7.5.91 , i.e. wrongly takes the version from bracketed gcc build
> > information). Though that may or may not be the cause of problem.
> >
> > I have tested it with
> > x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb.7z (and also 4.7.2 and
> others)
> > QtC 2.7.1 (Build on 8th May 2013) QtC 2.7.0 and QtC 2.8.0 beta official
> > builds
> > On Windows 7 and Windows 8
> >
>
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
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 version information for ruben vb build (Ruben Van Boxem) (Ruben Van Boxem)
> > > It seems clear to me that you should submit a patch that fixes this to Qt > > Project, and also if possible file the boost unit_test issue with the > > mingw-builds project. > > > > > I took the liberty to submit a bug report to the Qt Project: > https://bugreports.qt-project.org/browse/QTCREATORBUG-9452 > > If any Qt guys are reading this, I'll be very happy if this is bumped to > anywhere but the bottom of the stack ;-) > > Thanks for filing the bug report. Though the problem is not specific to Mingw w64, I asked it this mailing list as Qt Creator mailing list suggested " ask the person providing that GDB build to not patch the version string, or at least to not deviate too much from what other distributions do" Thanks abir > Cheers, > > Ruben > > -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] PRIu64 and uint64_t
In MinGW564 the code:
#define __STDC_FORMAT_MACROS 1
#include
..
..
uint64_t i = 0;
printf("i = %" PRIu64 "\n", i);
leads to a "unknown conversion type character 'l' in format". In MiGW32 it
compiles witout a warning.
The command that I use is
x86_64-w64-mingw32-gcc-4.8.0.exe -fexceptions -O3 -Winline -Wall -c ... -
o...
Is PRIu64 not the correct macro for printf family with uint64_t?
Thanks,
Gunnar
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] __faststorefence and mingw-w64 philosophy
2013/6/3 dw :
> So, a question about __faststorefence. The current implementation in
> winnt.h is incorrect. I have 3 alternates to propose, and which one is
> "best" depends on the goals of the mingw-w64 project. One approach is "just
> do what MSVC does." However, there's also something to be said for
> "generate the fastest possible code." And for completeness, there's also
> "use a built-in." Details with pros/cons below.
>
> First, the current code:
>
> __MINGW_INTRIN_INLINE void __faststorefence(void) {
> __asm__ __volatile__ ("" ::: "memory");
> }
>
> While the "memory" clobber generates a readwritebarrier() for the compiler,
> __faststorefence must also generate some type of fence instruction for the
> processor (sfence, mfence, lock).
>
> So, we can:
>
> 1) Just map this to __sync_synchronize(). This does the full memory
> compiler barrier, and generates an mfence instruction.
> pros:
> - Uses builtin.
>
> cons:
> - Generates mfence instead of sfence (see timing #'s below).
> - Generates mfence even if compiled with -mno-sse (mfence is sse2).
> - Generates mfence instead of the "lock or DWORD PTR [rsp], 0" which MSVC
> generates.
>
> 2) Map this to the same as MSVC. The "memory" clobber ensures the compiler
> barrier, and the "lock" provides the fence:
>
> asm ("lock or %[zero], (%%rsp)" :: [zero] "ri" (0) : "memory", "cc")
>
> pros:
> - consistent with MSVC.
>
> cons:
> - While sfence may have been slower when first introduced, it's faster than
> "or" now (see #'s below).
>
> 3) Use code like:
>
> __MINGW_INTRIN_INLINE void x__faststorefence(void) {
>
> #ifdef __SSE__ // defined by gcc when sse instructions are available
> asm ("sfence" ::: "memory");
> #else
> asm ("lock or %[zero], (%%rsp)" :: [zero] "ri" (0) : "memory", "cc");
> #endif
>
> }
>
> Pros:
> - Uses the faster sfence if available.
> - Falls back to "or" for max compatibility.
>
> cons:
> - Not consistent with MSVC.
> - SFENCE is not necessarily the fastest on all processors.
>
> I ran some timings using x64 on my i7, and this is what I find:
>
> _mm_sfence: 3,589,817,193
> lock or : 14,960,719,245
> _mm_mfence: 19,608,594,657
>
> Obviously these results are going to be both highly hw specific and depend
> heavily on the code surrounding them. Still...
>
> If I were going to pick, I'd probably go with #3. It isn't 100% identical
> to MSVC, but it effectively produces the same results, and will (at least on
> current processors) generate faster code.
>
> Opinions?
>
> dw
I think option #3 is that one I prefer too. Just one thing about
SSE-instruction. For 64-bit we can assume that SSE has to be present
in any case. Just for 32-bit we should check in headers for the
__SSE__ macro, and in the intrinsic-function (none-inline) we should
default to none-SSE version.
Kai
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] PRIu64 and uint64_t
Le 03/06/2013 13:00, Gunnar a écrit :
> In MinGW564 the code:
>
> #define __STDC_FORMAT_MACROS 1
> #include
>
> ..
> ..
>
> uint64_t i = 0;
> printf("i = %" PRIu64 "\n", i);
>
>
>
> leads to a "unknown conversion type character 'l' in format". In MiGW32 it
> compiles witout a warning.
>
> The command that I use is
>
> x86_64-w64-mingw32-gcc-4.8.0.exe -fexceptions -O3 -Winline -Wall -c ... -
> o...
>
>
> Is PRIu64 not the correct macro for printf family with uint64_t?
Try with #define __USE_MINGW_ANSI_STDIO 1
PRIu64 is not known by MS version of printf
For details see http://sourceforge.net/apps/trac/mingw-w64/wiki/gnu%20printf
> Thanks,
> Gunnar
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] __faststorefence and mingw-w64 philosophy
Le 03/06/2013 13:57, Kai Tietz a écrit :
> 2013/6/3 dw :
>> 3) Use code like:
>>
>> __MINGW_INTRIN_INLINE void x__faststorefence(void) {
>>
>> #ifdef __SSE__ // defined by gcc when sse instructions are available
>> asm ("sfence" ::: "memory");
>> #else
>> asm ("lock or %[zero], (%%rsp)" :: [zero] "ri" (0) : "memory", "cc");
>> #endif
>>
>> }
>>
>> Pros:
>> - Uses the faster sfence if available.
>> - Falls back to "or" for max compatibility.
>>
>> cons:
>> - Not consistent with MSVC.
>> - SFENCE is not necessarily the fastest on all processors.
>>
>> I ran some timings using x64 on my i7, and this is what I find:
>>
>> _mm_sfence: 3,589,817,193
>> lock or : 14,960,719,245
>> _mm_mfence: 19,608,594,657
>>
>> Obviously these results are going to be both highly hw specific and depend
>> heavily on the code surrounding them. Still...
>>
>> If I were going to pick, I'd probably go with #3. It isn't 100% identical
>> to MSVC, but it effectively produces the same results, and will (at least on
>> current processors) generate faster code.
>>
>> Opinions?
>>
>> dw
>
> I think option #3 is that one I prefer too. Just one thing about
> SSE-instruction. For 64-bit we can assume that SSE has to be present
> in any case. Just for 32-bit we should check in headers for the
> __SSE__ macro, and in the intrinsic-function (none-inline) we should
> default to none-SSE version.
__SSE__ should always be defined with x86_64 so just checking for
__SSE__ might be simpler and will give the fastest version.
Thus the same definition could be used for both inline and intrinsic.
> Kai
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] Add winstring.h and corresponding runtimeobject imports
---
mingw-w64-crt/Makefile.am | 6 +-
mingw-w64-crt/lib32/runtimeobject.def | 25 +
mingw-w64-crt/lib64/runtimeobject.def | 29 +
mingw-w64-headers/include/winstring.h | 202 ++
4 files changed, 260 insertions(+), 2 deletions(-)
create mode 100644 mingw-w64-crt/lib32/runtimeobject.def
create mode 100644 mingw-w64-crt/lib64/runtimeobject.def
create mode 100644 mingw-w64-headers/include/winstring.h
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 4ce1258..71c9f15 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -542,7 +542,8 @@ lib32_DATA = \
lib32/libxapofx.a lib32/libx3daudio.a lib32/libd3dx9.a \
lib32/libd3dx10.a lib32/libd3dx11.a lib32/libd3dcsxd.a \
lib32/libd3dcompiler.alib32/libwinhttp.alib32/libmsvcr110.a \
- lib32/libdevmgr.a lib32/libdevobj.a lib32/libdevrtl.a
+ lib32/libdevmgr.a lib32/libdevobj.a lib32/libdevrtl.a\
+ lib32/libruntimeobject.a
if ! W32API
lib32_DATA += lib32/libglut.a
@@ -1043,7 +1044,8 @@ lib64_DATA = \
lib64/libxinput.a lib64/libxaudio.a lib64/libxaudiod.a \
lib64/libxapofx.a lib64/libx3daudio.a lib64/libd3dx9.a \
lib64/libd3dx10.a lib64/libd3dx11.a lib64/libd3dcsxd.a \
- lib64/libd3dcompiler.alib64/libwinhttp.alib64/libmsvcr110.a
+ lib64/libd3dcompiler.alib64/libwinhttp.alib64/libmsvcr110.a \
+ lib64/libruntimeobject.a
lib64/libcrtdll.a lib64/libmsvcrt.a lib64/libmsvcr80.a: lib64/lib%.a:
lib64/%.def
$(DTDEF64) $< --dllname $*.dll
diff --git a/mingw-w64-crt/lib32/runtimeobject.def
b/mingw-w64-crt/lib32/runtimeobject.def
new file mode 100644
index 000..c49fc51
--- /dev/null
+++ b/mingw-w64-crt/lib32/runtimeobject.def
@@ -0,0 +1,25 @@
+LIBRARY "api-ms-win-core-winrt-string-l1-1-0.dll"
+EXPORTS
+HSTRING_UserFree@8
+HSTRING_UserMarshal@12
+HSTRING_UserSize@12
+HSTRING_UserUnmarshal@12
+WindowsCompareStringOrdinal@12
+WindowsConcatString@12
+WindowsCreateString@12
+WindowsCreateStringReference@16
+WindowsDeleteString@4
+WindowsDeleteStringBuffer@4
+WindowsDuplicateString@8
+WindowsGetStringLen@4
+WindowsGetStringRawBuffer@8
+WindowsInspectString@24
+WindowsIsStringEmpty@4
+WindowsPreallocateStringBuffer@12
+WindowsPromoteStringBuffer@8
+WindowsReplaceString@16
+WindowsStringHasEmbeddedNull@8
+WindowsSubstring@12
+WindowsSubstringWithSpecifiedLength@16
+WindowsTrimStringEnd@12
+WindowsTrimStringStart@12
diff --git a/mingw-w64-crt/lib64/runtimeobject.def
b/mingw-w64-crt/lib64/runtimeobject.def
new file mode 100644
index 000..c211978
--- /dev/null
+++ b/mingw-w64-crt/lib64/runtimeobject.def
@@ -0,0 +1,29 @@
+LIBRARY "api-ms-win-core-winrt-string-l1-1-0.dll"
+EXPORTS
+HSTRING_UserFree
+HSTRING_UserFree64
+HSTRING_UserMarshal
+HSTRING_UserMarshal64
+HSTRING_UserSize
+HSTRING_UserSize64
+HSTRING_UserUnmarshal
+HSTRING_UserUnmarshal64
+WindowsCompareStringOrdinal
+WindowsConcatString
+WindowsCreateString
+WindowsCreateStringReference
+WindowsDeleteString
+WindowsDeleteStringBuffer
+WindowsDuplicateString
+WindowsGetStringLen
+WindowsGetStringRawBuffer
+WindowsInspectString
+WindowsIsStringEmpty
+WindowsPreallocateStringBuffer
+WindowsPromoteStringBuffer
+WindowsReplaceString
+WindowsStringHasEmbeddedNull
+WindowsSubstring
+WindowsSubstringWithSpecifiedLength
+WindowsTrimStringEnd
+WindowsTrimStringStart
diff --git a/mingw-w64-headers/include/winstring.h
b/mingw-w64-headers/include/winstring.h
new file mode 100644
index 000..b395cef
--- /dev/null
+++ b/mingw-w64-headers/include/winstring.h
@@ -0,0 +1,202 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the mingw-w64 runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+#ifndef __WINSTRING_H__
+#define __WINSTRING_H__
+
+#include
+#include
+
+#if _WIN32_WINNT >= _WIN32_WINNT_WIN8
+
+// Declaring a handle dummy struct for HSTRING the same way DECLARE_HANDLE
does.
+typedef struct HSTRING__{
+int unused;
+} HSTRING__;
+
+typedef HSTRING__* HSTRING;
+
+typedef HANDLE HSTRING_BUFFER;
+
+typedef struct HSTRING_HEADER {
+ union {
+PVOID Reserved1;
+#if (_WIN64)
+char Reserved2[24];
+#else
+char Reserved2[20];
+#endif
+ } Reserved;
+} HSTRING_HEADER;
+
+/* */
+
+void __stdcall HSTRING_UserFree(
+ unsigned long *pFlags,
+ HSTRING *ppidl
+);
+
+unsigned char* __stdcall HSTRING_UserMarshal(
+ unsigned long *pFlags,
+ unsigned char *pBuffer,
+ HSTRING *ppidl
+);
+
+unsigned long __stdcall HSTRING_UserSize(
+ unsigned long *pFlags,
+ unsigned long StartingSize,
+ HSTRING *ppidl
+);
+
+unsigned char* __stdcall HSTRING_UserUnmarshal(
+ unsigned long *pFlags,
+ unsigned char *pBuffer,
+ HSTRING *ppidl
+);
+
+#ifdef _WIN64
+void __stdcall HSTRING_UserFree64(
+ unsigned long *pFlags,
+ HSTRING *p
Re: [Mingw-w64-public] [PATCH] Add winstring.h and corresponding runtimeobject imports
2013/6/3 Rafaël Carré :
> ---
> mingw-w64-crt/Makefile.am | 6 +-
> mingw-w64-crt/lib32/runtimeobject.def | 25 +
> mingw-w64-crt/lib64/runtimeobject.def | 29 +
> mingw-w64-headers/include/winstring.h | 202
> ++
> 4 files changed, 260 insertions(+), 2 deletions(-)
> create mode 100644 mingw-w64-crt/lib32/runtimeobject.def
> create mode 100644 mingw-w64-crt/lib64/runtimeobject.def
> create mode 100644 mingw-w64-headers/include/winstring.h
>
> diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
> index 4ce1258..71c9f15 100644
> --- a/mingw-w64-crt/Makefile.am
> +++ b/mingw-w64-crt/Makefile.am
> @@ -542,7 +542,8 @@ lib32_DATA = \
>lib32/libxapofx.a lib32/libx3daudio.a lib32/libd3dx9.a \
>lib32/libd3dx10.a lib32/libd3dx11.a lib32/libd3dcsxd.a \
>lib32/libd3dcompiler.alib32/libwinhttp.alib32/libmsvcr110.a \
> - lib32/libdevmgr.a lib32/libdevobj.a lib32/libdevrtl.a
> + lib32/libdevmgr.a lib32/libdevobj.a lib32/libdevrtl.a\
> + lib32/libruntimeobject.a
>
> if ! W32API
> lib32_DATA += lib32/libglut.a
> @@ -1043,7 +1044,8 @@ lib64_DATA = \
>lib64/libxinput.a lib64/libxaudio.a lib64/libxaudiod.a \
>lib64/libxapofx.a lib64/libx3daudio.a lib64/libd3dx9.a \
>lib64/libd3dx10.a lib64/libd3dx11.a lib64/libd3dcsxd.a \
> - lib64/libd3dcompiler.alib64/libwinhttp.alib64/libmsvcr110.a
> + lib64/libd3dcompiler.alib64/libwinhttp.alib64/libmsvcr110.a \
> + lib64/libruntimeobject.a
>
> lib64/libcrtdll.a lib64/libmsvcrt.a lib64/libmsvcr80.a: lib64/lib%.a:
> lib64/%.def
> $(DTDEF64) $< --dllname $*.dll
> diff --git a/mingw-w64-crt/lib32/runtimeobject.def
> b/mingw-w64-crt/lib32/runtimeobject.def
> new file mode 100644
> index 000..c49fc51
> --- /dev/null
> +++ b/mingw-w64-crt/lib32/runtimeobject.def
> @@ -0,0 +1,25 @@
> +LIBRARY "api-ms-win-core-winrt-string-l1-1-0.dll"
> +EXPORTS
> +HSTRING_UserFree@8
> +HSTRING_UserMarshal@12
> +HSTRING_UserSize@12
> +HSTRING_UserUnmarshal@12
> +WindowsCompareStringOrdinal@12
> +WindowsConcatString@12
> +WindowsCreateString@12
> +WindowsCreateStringReference@16
> +WindowsDeleteString@4
> +WindowsDeleteStringBuffer@4
> +WindowsDuplicateString@8
> +WindowsGetStringLen@4
> +WindowsGetStringRawBuffer@8
> +WindowsInspectString@24
> +WindowsIsStringEmpty@4
> +WindowsPreallocateStringBuffer@12
> +WindowsPromoteStringBuffer@8
> +WindowsReplaceString@16
> +WindowsStringHasEmbeddedNull@8
> +WindowsSubstring@12
> +WindowsSubstringWithSpecifiedLength@16
> +WindowsTrimStringEnd@12
> +WindowsTrimStringStart@12
> diff --git a/mingw-w64-crt/lib64/runtimeobject.def
> b/mingw-w64-crt/lib64/runtimeobject.def
> new file mode 100644
> index 000..c211978
> --- /dev/null
> +++ b/mingw-w64-crt/lib64/runtimeobject.def
> @@ -0,0 +1,29 @@
> +LIBRARY "api-ms-win-core-winrt-string-l1-1-0.dll"
> +EXPORTS
> +HSTRING_UserFree
> +HSTRING_UserFree64
> +HSTRING_UserMarshal
> +HSTRING_UserMarshal64
> +HSTRING_UserSize
> +HSTRING_UserSize64
> +HSTRING_UserUnmarshal
> +HSTRING_UserUnmarshal64
> +WindowsCompareStringOrdinal
> +WindowsConcatString
> +WindowsCreateString
> +WindowsCreateStringReference
> +WindowsDeleteString
> +WindowsDeleteStringBuffer
> +WindowsDuplicateString
> +WindowsGetStringLen
> +WindowsGetStringRawBuffer
> +WindowsInspectString
> +WindowsIsStringEmpty
> +WindowsPreallocateStringBuffer
> +WindowsPromoteStringBuffer
> +WindowsReplaceString
> +WindowsStringHasEmbeddedNull
> +WindowsSubstring
> +WindowsSubstringWithSpecifiedLength
> +WindowsTrimStringEnd
> +WindowsTrimStringStart
> diff --git a/mingw-w64-headers/include/winstring.h
> b/mingw-w64-headers/include/winstring.h
> new file mode 100644
> index 000..b395cef
> --- /dev/null
> +++ b/mingw-w64-headers/include/winstring.h
> @@ -0,0 +1,202 @@
> +/**
> + * This file has no copyright assigned and is placed in the Public Domain.
> + * This file is part of the mingw-w64 runtime package.
> + * No warranty is given; refer to the file DISCLAIMER.PD within this package.
> + */
> +#ifndef __WINSTRING_H__
> +#define __WINSTRING_H__
> +
> +#include
> +#include
Here we need to include additionally rpc.h header. Also we need here
to include winapifamily.h.
Also so some parts from this header should be put into hstring.h
header AFAIC read, it seems to be an idl-based generated file, so
this can come later ...
> +#if _WIN32_WINNT >= _WIN32_WINNT_WIN8
Hmm, true that API is Windows8 based, but do we really need to add
here this guard ... anyway it won't hurt AFAICS.
> +
> +// Declaring a handle dummy struct for HSTRING the same way DECLARE_HANDLE
> does.
> +typedef struct HSTRING__{
> +int unused;
> +} HSTRING__;
> +
> +typedef HSTRING__* HSTRING;
> +
> +typedef HANDLE HSTRING_BUFFER;
> +
> +typedef struct HSTRING_HEADER {
> + union {
> +PVOID Reserved1;
> +#if (_WIN64
Re: [Mingw-w64-public] [PATCH] Add winstring.h and corresponding runtimeobject imports
On 6/3/2013 22:18, Rafaël Carré wrote: > new file mode 100644 > index 000..c49fc51 > --- /dev/null > +++ b/mingw-w64-crt/lib32/runtimeobject.def > @@ -0,0 +1,25 @@ > +LIBRARY "api-ms-win-core-winrt-string-l1-1-0.dll" > new file mode 100644 > index 000..c211978 > --- /dev/null > +++ b/mingw-w64-crt/lib64/runtimeobject.def > @@ -0,0 +1,29 @@ > +LIBRARY "api-ms-win-core-winrt-string-l1-1-0.dll" > Are you sure about these? The library names do not match the DLL, these DLLs are internal versioned copies. signature.asc Description: OpenPGP digital signature -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] PRIu64 and uint64_t
On 6/3/2013 20:16, Rafaël Carré wrote:
> Le 03/06/2013 13:00, Gunnar a écrit :
>> In MinGW564 the code:
>>
>> #define __STDC_FORMAT_MACROS 1
>> #include
>>
>> ..
>> ..
>>
>> uint64_t i = 0;
>> printf("i = %" PRIu64 "\n", i);
>>
>>
>>
>> leads to a "unknown conversion type character 'l' in format". In MiGW32 it
>> compiles witout a warning.
>
> Try with #define __USE_MINGW_ANSI_STDIO 1
>
> PRIu64 is not known by MS version of printf
>
> For details see http://sourceforge.net/apps/trac/mingw-w64/wiki/gnu%20printf
No, something is wrong here, the inttypes.h declaration should have
matched the appropriate printf versions. Some work went in to make sure
either C99 and MS printf formats are declared depending on the printf used.
Please show a minimal test case to duplicate the issue.
signature.asc
Description: OpenPGP digital signature
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Runtime for Cygwin
Hi, all! When using latest mingw-w64 runtime from trunk for Cygwin I have error: http://pastebin.com/9WVgE1Gu Regards, Alexey. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Runtime for Cygwin
2013/6/3 Алексей Павлов : > Hi, all! > > When using latest mingw-w64 runtime from trunk for Cygwin I have error: > http://pastebin.com/9WVgE1Gu > > Regards, Alexey. Hmm, means that Interlocked-Functions getting defined twice with different prototypes. Corinna, any idea here? Regards, Kai -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Runtime for Cygwin
I have this error only on 64-bit Cygwin 2013/6/3 Kai Tietz > 2013/6/3 Алексей Павлов : > > Hi, all! > > > > When using latest mingw-w64 runtime from trunk for Cygwin I have error: > > http://pastebin.com/9WVgE1Gu > > > > Regards, Alexey. > > Hmm, means that Interlocked-Functions getting defined twice with > different prototypes. > Corinna, any idea here? > > Regards, > Kai > > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Do I select the right build type
Hello, zhangxinghai, As I remember it is possible to compile wxWidgets library with Ruben's toolchain on MSYS. At the end of configure command details of guess should be correct for 32 bit os. Regards -- 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] [Website] Work on a Download page
Hi, I've uploaded a new version of that page: http://notk.org/~adrien/picker.php As you'll see, quite a lot of things have changed and the page should feel lighter and more intuitive. Some of the new data isn't completely right and there are a few cosmetics change to do. Apart from that, I hope you will find it is a big step in the right direction and that the UI layout is good. (also, the block of text at the top with explanations has grown a bit more than expected but that's easy to change) On Thu, May 30, 2013, Ruben Van Boxem wrote: > Let's get things straight: the number of Linux distros providing a > MinGW-w64 toolchain is only going to keep increasing (currently: > Debian+derivatives, Ubuntu+derivatives Fedora+relatives, OpenSUSE, Arch, > gentoo, etc...) I don't see any of these have much interest in keeping yet > another web page in sync. I'm sure there will be exceptions, but you can't > rely on exceptions. Besides, they all have their own package management > functions that might advertise mingw-w64 in one way or another depending on > a user search. Linux users don't typically use google to find their > packages. This whole updating becomes even more undoable when you factor in > 3rd party packages, which a distro may or may not provide, and update. > > I'm just trying to warn you for trying the nigh impossible for IMHO little > value. So far this hasn't been a concern. I can't predict how things will evolve and I'm not expecting them to stay the same forever but I think it's better to just wait and see. > > > > > As for the additional softwares, I strongly believe they matter. C++ > > makes this even more important because of the incompatible exception > > handling mechanisms. > > I've also never enjoyed having to hunt for unreliable prebuilt binaries > > on tens of websites and software authors don't usually enjoy having to > > build binaries themselves either (tbh, I've seen reactions vary between > > disliking it, hating it and despising it). > > > > I think the regular MinGW(-w64) developer will either be or become quickly > accustomed to building all his/her dependencies from source. Granted, > that's far from ideal, but there'd need to be a huge packaging effort to > remedy this. > That packaging effort is actually there and with some care it has been possible to reuse OpenSuSe's well-tested packages for years now. Building takes time, especially on msys and cygwin. Doing it by hand also means that upgrading to a newer version or removing a library is very painful. I truly believe it's the way to go. I hope that with my latest changes to the page, the (fairly long) list of packages is now nicer. -- 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] __faststorefence and mingw-w64 philosophy
>> I think option #3 is that one I prefer too. Just one thing about >> SSE-instruction. For 64-bit we can assume that SSE has to be present >> in any case. Just for 32-bit we should check in headers for the >> __SSE__ macro, and in the intrinsic-function (none-inline) we should >> default to none-SSE version. > __SSE__ should always be defined with x86_64 so just checking for > __SSE__ might be simpler and will give the fastest version. > > Thus the same definition could be used for both inline and intrinsic. Per MS docs, __faststorefence is only defined for x64. While I assume it would work, the current winnt.h doesn't define it for x86 and I wasn't planning to add it. Being able to just assume that __SSE__ is defined certainly makes the code cleaner. The reason I didn't was that it is possible that someone could be compiling with -mno-sse for some reason. Ignore this? There is a similar question for MemoryBarrier(). The mfence instruction is SSE2. Check for __SSE2__ or not? dw -- 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
[Mingw-w64-public] build wx with tdm-gcc successfully
hello I have just succeeded in building wx 2.9.4 with tdm-gcc-64 4.7.1-3,I'm very glad.Thanks for all help. I invoke the command mingw32-make -f makefile.gcc -j4 BUILD=release SHARED=1 MONOLITHIC=0 UNICODE=1 CXXFLAGS="-m32 -pipe -fno-keep-inline-dllexport -Os" LDFLAGS=-m32 CFLAGS=-m32 RCFLAGS="-F pe-i386" I also find I must change makefile.gcc,add RCFLAGS to MAKEARGS,and add $(RCFLAGS) to all windres command line. Is there an alternate way more quick and simple?Can I avoid modifying every windres command? Next I will try compile under msys using tdm-gcc,how to specify file format to pe-i386 for windres? I also try to build with ruben's toolchain. Best Regards -- 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] build wx with tdm-gcc successfully
I suggest not to use multiple lib gcc here, unless you know -m32 *windres*needs -F pe-i386. You can choose one gcc with only x86 or x64. On Tue, Jun 4, 2013 at 11:23 AM, zhangxinghai wrote: > hello > I have just succeeded in building wx 2.9.4 with tdm-gcc-64 4.7.1-3,I'm > very glad.Thanks for all help. > I invoke the command > mingw32-make -f makefile.gcc -j4 BUILD=release SHARED=1 MONOLITHIC=0 > UNICODE=1 CXXFLAGS="-m32 -pipe -fno-keep-inline-dllexport -Os" > LDFLAGS=-m32 CFLAGS=-m32 RCFLAGS="-F pe-i386" > I also find I must change makefile.gcc,add RCFLAGS to MAKEARGS,and add > $(RCFLAGS) to all windres command line. > Is there an alternate way more quick and simple?Can I avoid modifying > every windres command? > Next I will try compile under msys using tdm-gcc,how to specify file > format to pe-i386 for windres? > I also try to build with ruben's toolchain. > Best Regards > > > > > > -- > 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 > > -- Best Regards, xunxun -- 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] InterlockedBitTestAndXXX
On Tue, Jun 4, 2013 at 1:58 AM, dw wrote: > >> If you can prepare patches for your recent asm stuff against the stable >> branch, I would happily merge. > > It might make sense to hold off on this a bit. I have several more that I'm > working on. > OK, > Also, I hate asking questions that expose my ignorance, but sometimes it's > the only way to learn. So, what exactly are you referring to when you say > "the stable branch?" Presumably some other svn? The trunk is the development version 3.x. e have stable v1.x and 2.x branches, see: http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/stable/ Those asm stuff should be identical between those two. > > dw -- O.S. -- 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] build wx with tdm-gcc successfully
2013/6/4 zhangxinghai > hello > I have just succeeded in building wx 2.9.4 with tdm-gcc-64 4.7.1-3,I'm > very glad.Thanks for all help. > I invoke the command > mingw32-make -f makefile.gcc -j4 BUILD=release SHARED=1 MONOLITHIC=0 > UNICODE=1 CXXFLAGS="-m32 -pipe -fno-keep-inline-dllexport -Os" > LDFLAGS=-m32 CFLAGS=-m32 RCFLAGS="-F pe-i386" > I also find I must change makefile.gcc,add RCFLAGS to MAKEARGS,and add > $(RCFLAGS) to all windres command line. > Is there an alternate way more quick and simple?Can I avoid modifying > every windres command? > Next I will try compile under msys using tdm-gcc,how to specify file > format to pe-i386 for windres? > I also try to build with ruben's toolchain. > Hi, I have also succeeded in building wxWidgets with my GCC 4.7 and 4.6 releases. It seems only GCC 4.8 has a problem. You can use MSYS and configure using --host=i686-w64-mingw32 Ruben Best Regards > > > > > > -- > 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 > > -- 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
