Hi,
I'm using a mingw64 port of gcc-4.7.0 on Windows Vista64:
#
C:\_32\Cx86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=c:/_64/alt/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/lto-wrapper.exe
Target:
On 7/21/2012 15:06, Sisyphus wrote:
Hi,
I'm using a mingw64 port of gcc-4.7.0 on Windows Vista64:
#
C:\_32\Cx86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
On Jul 20 20:46, Kai Tietz wrote:
2012/7/20 Ozkan Sezer seze...@gmail.com:
On 7/20/12, Corinna Vinschen vinsc...@redhat.com wrote:
On Jul 20 20:15, Corinna Vinschen wrote:
On Jul 20 19:45, Kai Tietz wrote:
2012/7/20 Corinna Vinschen vinsc...@redhat.com:
Hi,
The error codes
Hi,
I've seen a lot of chatter/patches going into MinGW-w64 for Cygwin support,
which is great, as I've noticed a lot of small inconsistencies and code
clarity issues are being fixed.
What I would like to know is if I could build a working Cygwin
cross-compiler using MinGW-w64 and if so, what
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
Hi asmwarrior!
Thanks for the link to your gdb build.
On Sat, Jul 21, 2012 at 12:59 AM, asmwarrior 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
2012/7/21 asmwarrior asmwarr...@gmail.com
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
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
Hello,
Npackd 1.17 (http://code.google.com/p/windows-package-manager/) will have a
64 bit version compiled using mingw-w64.
Please add it to the list of Projects successfully using MinGW-w64
Thank You
--
Live Security
On Sat, Jul 21, 2012 at 7:59 AM, asmwarrior 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
2012/7/21 Corinna Vinschen vinsc...@redhat.com:
Hi,
Since enum's are based on int anyway(*), defining their values as long
is not useful. The below patch removes all 'L' qualifiers from enum
values in the PSDK headers. Ok to apply?
Thanks,
Corinna
(*) Ignoring C++11 enum classes for
Hi guys,
Regarding GDB and Python:
I've got some WIP Python patches that were created for Necessitas Qt
Creator's NDK GDB for Android. They've since been merged into the
Google NDK:
https://android-review.googlesource.com/#/c/38501/
Using the patches in that merge request, it's possible to
Greetings fellow program(mers).
A situation occurred the other day where, using (cross compiled)
ffmpeg+libx264 with mingw-w64, --enable-pthreads and the mingw-w64
pthread library, some oddness would result, like the app would hang
eating up 100% cpu, seemingly doing nothing useful. I was told
δΊ 2012/7/22 13:12, Roger Pack ει:
Greetings fellow program(mers).
A situation occurred the other day where, using (cross compiled)
ffmpeg+libx264 with mingw-w64, --enable-pthreads and the mingw-w64
pthread library, some oddness would result, like the app would hang
eating up 100% cpu,
14 matches
Mail list logo
