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 eve
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 just
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, destroy
2 11:48 PM, Kai 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.
>
&g
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 or
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:
>>&g
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 hopin
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 pr
> 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 depend
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 autoreco
Hello everyone,
I have just joined a project where I will need access to autoconf and
autoreconf. I am running Windows XP x64, I use Msys as my shell, and have put
sezero's latest build at the front of the path so I can build 64-bit binaries.
The start of my path looks like:
$ echo $PATH
.:/c/
Hello everyone,
I was wondering if there is a way to find out what _all_ is "define"d 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 (includi
Ozkan Sezer wrote:
>
> pthreads-20100604.zip requires the no-underscore x64 abi which our
> old x64-toolchains from before 2010-04-28 weren't aware of, hence the
> errors you are seeing. Please use a new toolchain and all should be
> well.
>
>
> --
> O.S.
>
Perfect, I just downloaded the 201
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
Hello everyone,
I currently have a program that I've written that I think could benefit from
being multi-threaded. However, I don't yet know how to write multi-threaded
programs, so I don't know what "libraries" are out there or which ones will
work
(or are included) with mingw64. Can someon
Hello all,
I've recently come across a program that includes sys/resource.h and uses that
for measuring the runtime of some code. I know that Mingw64 does not have this
file, but I was wondering why? Is it something that cannot be done on a
Windows
platform?
Also, I see that there is a stru
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 f
Kai Tietz wrote:
> Hello David,
>
> The problem you've shown is reasoned by using a gdb built without
> libexpat. You can download a more current version from our SF file
> sections (see Tools), which is build with libexpat. If gdb isn't built
> by it, debugging information from DLLs won't be loa
Hello all,
This may be the wrong list to ask this, but I'm not sure where else to ask.
I'm
working on a project that I can compile just fine, but when I run the program
it
crashes silently. This isn't my project, it is a project that I've come across
and would like to help out on. This pro
Hello, I'm not sure if this will be the proper place to ask this. If not,
could someone suggest a better place to ask.
I'm having a bit of trouble with a small function I've created. It is supposed
to multiply 2 64-bit numbers, divide the result (possibly up to a 128-bit
number) by another 6
JonY wrote:
> There is no such macro as __MINGW64__, use __MINGW64_VERSION_MAJOR
> instead, its guaranteed to be defined if you include any mingw-w64
> headers.
>
> I think __USE_MINGW_ANSI_STDIO only applies to the printf family, the
> scanf family has not been ported yet, so you'll need to use
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
m
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 __USE_MINGW_ANSI
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
Hello,
I'm having problems printing out values that are larger than 32 bits. My usual
printf using %llu only outputs the lower 32 bits of my 64-bit numbers.
Here's an example program that produces incorrect output.
#include
typedef unsigned long long u64_t;
int main(int argc, char* argv[])
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
>
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
Hello everyone,
I would like to start using mingw-w64, but am unsure of what to do. I've just
downloaded the latest mingw-w64-bin-x86_64-mingw_20080320.tar.bz2 and extracted
it to its own folder "c:\mw64". I'm running Windows XP 64-bit edition and
would
like to build 64-bit windows binaries.
28 matches
Mail list logo
