On 7/11/2013 11:21 PM, xunxun wrote:
-Wl,--large-address-aware is only for x86 target
Thank you. I've removed this option, since my target is x64, and the compile
completes successfully.
-David C.
--
See
Hello everyone,
I was previously using an old Ozkan build, from 2011-11-01. I compiled a
project and when that got to the stage to use ld.exe, I got the following error:
ld.exe: unrecognized option '--large-address-aware'
I thought this may have been due to me using an old tool chain, so I
Thank you for giving me suggestions of things to try. I have tried pushing and
popping r8,r9,r10,r11,rcx, and rdx. However, this did not change the behavior
of the program.
I looked at the documentation you mentioned and they seem to say that r10/r11
should be considered volatile (ie,
Tietz wrote:
Hi,
such failures a commonly caused by inline-assembler not treating
memory-ref proper. I assume that inline assembler doesn't specify
explicit memory-clobber/modify. Newer gcc versions are here more
strict then older versions.
Kai
2012/2/20 David Cleaver:
Hello everyone
Hello everyone,
I have run into a very strange problem and I am not sure what might be causing
it. I am compiling the latest svn of gmp-ecm (right now it is 1746) and
depending on whether I insert a few extra print statements or not, one certain
test in gmp-ecm will either run to completion
Hello Everyone,
I seem to have run into an issue with printf with my native toolchain that
someone else with the cross-compiler does not have. I was hoping someone here
could help us track down what might be the difference between our two builds.
We ran tests based off of the following test
On 12/17/2011 9:24 AM, Ozkan Sezer wrote:
On Sat, Dec 17, 2011 at 4:49 PM, David Cleaver wrote:
Hello Everyone,
I seem to have run into an issue with printf with my native toolchain that
someone else with the cross-compiler does not have. I was hoping someone
here
could help us track
On 12/17/2011 10:41 AM, Kai Tietz wrote:
2011/12/17 Ozkan Sezer:
On Sat, Dec 17, 2011 at 6:09 PM, David Cleaver wrote:
On 12/17/2011 9:24 AM, Ozkan Sezer wrote:
On Sat, Dec 17, 2011 at 4:49 PM, David Cleaver wrote:
I know that putting
#define __USE_MINGW_ANSI_STDIO 1
at the top
On 6/30/2011 05:20, Torbjorn Granlund wrote:
Currently (i think) GMP configures and builds under MinGW-64, but GMP's
performance leaves a lot to be desired, mainly since the GMP x86_64
assembly does not work with Windows64's calling conventions. (GMP's
performance is very dependent on
JonY wrote:
The tarball has symlinks in them, so I don't think they'll work with
MSYS out of the box.
If possible, I suggest using Cygwin instead of MSYS if you want Unix-ish
symlinks.
I'm not particularly looking for symlinks. I was just needing access to
autoconf and autoreconf.
Hello everyone,
I was wondering if there is a way to find out what _all_ is defined in the
mingw64 environment? Is there a way to get gcc to output this information? Is
there already a list somewhere? Is there another program that can somehow
gather this info? I'm wanting to know
Hello everyone,
I've recently decided to learn pthreads. I've just finished writing my first
pthreads program, and have been able to fix most of the problems that gcc
reported to me. However, I am now getting undefined reference errors and am
not sure why. Can someone help me diagnose this
Ozkan Sezer wrote:
AFAIK, you may not tell the difference, and I'm afraid
that the 20100123 version you just tried may not have
been compiled against expat either. FWIW, I will compile
gdb against expat in my next personal builds. ... and
even made a version just now, see if this works for
Hello again,
I know it wasn't long ago that I was asking about using %llu in fscanf or
sscanf. However, I am wondering if anything has changed in this regard? Does
MingW64 support %llu in the scanf functions?
Also, in the future, is there an easy way for me to find out this information
on
Hello all,
I'm now trying to read in 64-bit values from a file. They are stored in
decimal
(base-10) format, and I am trying to read them in with:
unsigned long long number;
fscanf(input, %llu, number);
However, it is only reading in the least-significant 32-bits of the number on
any given
Kai Tietz wrote:
Yes, you did. I assume you are using a XP, or earlier Operating System
of Windows, am I right?
Yes, I am using Windows XP Pro 64-bit edition.
To be portable use instead of '%ll' the MS specific '%I64'. At the
moment the scanf functions aren't part of the
NightStrike wrote:
On 3/20/08, David Cleaver wrote:
1) Do I need to add c:\mw64\bin to my path?
Yup. I'd put it first, too: PATH=C:\mw64\bin;%PATH%
Awesome! After using tar under cygwin (I originally used a program called
7-zip) to re-extract all the files to c:\mw64, all the files
NightStrike wrote:
No, it's just not setup right. The msys.bat file configures a system
properly based on if you're 64-bit windows or 32-bit windows. So
start your shell with that instead of starting sh.exe directly. You
can use the --norxvt option to msys.bat to use a normal windows
18 matches
Mail list logo
