great, thanks !
On 01/25/2018 05:23 PM, Kai Tietz via Mingw-w64-public wrote:
Hello,
it is a common, but nevertheless wrong assumption, that %z formatter
is compatible for different runtimes. Especially msvcrt is all but
C99 compatible. If you have enabled the use our C99 compatible
printf/sc
Hello,
it is a common, but nevertheless wrong assumption, that %z formatter
is compatible for different runtimes. Especially msvcrt is all but
C99 compatible. If you have enabled the use our C99 compatible
printf/scanf implementation via the __USE_MINGW_ANSI_STDIO macro, then
you will see that %
Hi,
I'm looking for a portable way to print a size_t.
I thought "%zu" was the recommended way to do it, but I'm getting
unknown format warnings when printf() is called with "%zu".
I guess i can use something like %llu instead but shouldn't this work in
C99 mode really ? (must be missing somet
On Wed, Apr 1, 2015 at 4:33 PM, Martin Mitáš wrote:
>
>
> Dne 1. 4. 2015 v 10:13 Mattias Engdegård napsal(a):
> > 1 apr 2015 kl. 05.35 skrev Dongsheng Song :
> >
> >> In my testing, getenv() is very fast.
> >>
> >> *) unset PRINTF_EXPONENT_DIGITS
> >>
> >> preheat 1 times, then perform 10
Dne 1. 4. 2015 v 10:13 Mattias Engdegård napsal(a):
> 1 apr 2015 kl. 05.35 skrev Dongsheng Song :
>
>> In my testing, getenv() is very fast.
>>
>> *) unset PRINTF_EXPONENT_DIGITS
>>
>> preheat 1 times, then perform 100 times (use 4.6 seconds)
>> getenv cost: 4.6 us
>>
>> *) set P
1 apr 2015 kl. 05.35 skrev Dongsheng Song :
> In my testing, getenv() is very fast.
>
> *) unset PRINTF_EXPONENT_DIGITS
>
> preheat 1 times, then perform 100 times (use 4.6 seconds)
> getenv cost: 4.6 us
>
> *) set PRINTF_EXPONENT_DIGITS=3
> preheat 1 times, then perform 100
> patch is ok. I am still a bit curious to learn about that high delay
> caused by getenv ().
It was a while since I dissected it, but I believe getenv takes a lock. This
hurts multithreaded programs in particular. Even without a lock, getenv still
needs to do a linear string search through the
Hi Mattias,
patch is ok. I am still a bit curious to learn about that high delay
caused by getenv ().
Kai
2015-04-01 5:35 GMT+02:00 Dongsheng Song :
> Hi Mattias,
>
> Could you share your micro benchmark data ?
>
> In my testing, getenv() is very fast.
>
> *) unset PRINTF_EXPONENT_DIGITS
>
> pr
Hi Mattias,
Could you share your micro benchmark data ?
In my testing, getenv() is very fast.
*) unset PRINTF_EXPONENT_DIGITS
preheat 1 times, then perform 100 times (use 4.6 seconds)
getenv cost: 4.6 us
*) set PRINTF_EXPONENT_DIGITS=3
preheat 1 times, then perform 100
Cache getenv() looks a good idea !
Patch is OK for me.
On Wed, Apr 1, 2015 at 4:16 AM, Mattias Engdegård wrote:
> The functions in the __mingw_printf family are very slow because of the
> getenv(”PRINTF_EXPONENT_DIGITS”) call that is made every time, even when
> that information isn’t actually n
The functions in the __mingw_printf family are very slow because of the
getenv(”PRINTF_EXPONENT_DIGITS”) call that is made every time, even when that
information isn’t actually needed.
Please consider this patch. It only calls getenv once, caching the result (as
is traditionally done in librari
olks. problem resolved.
>
> From: K. Frank
>To: mingw64
>Sent: Friday, May 9, 2014 5:00 PM
>Subject: Re: [Mingw-w64-public] printf("%*.*f",d) broken?
>
>
>Hi Jim!
>
>On Fri, May 9, 2014 at 5:29 PM, Jim Michaels wrote:
>
.@zxid.org"
>To: jmich...@yahoo.com
>Cc: mingw-w64-public@lists.sourceforge.net; sampo-mi...@zxid.org
>Sent: Saturday, May 10, 2014 3:07 AM
>Subject: Re: [Mingw-w64-public] printf
>
>
>Jim Michaels said:
>> I could not find a good example on this because examp
3609/printf-variable-number-of-decimals-in-float
>
> From: K. Frank
>To: mingw64
>Sent: Friday, May 9, 2014 5:00 PM
>Subject: Re: [Mingw-w64-public] printf("%*.*f",d) broken?
>
>
>Hi Jim!
>
>On Fri, May 9, 2014 at 5:29
___
> From: K. Frank
>To: mingw64
>Sent: Friday, May 9, 2014 5:00 PM
>Subject: Re: [Mingw-w64-public] printf("%*.*f",d) broken?
>
>
>Hi Jim!
>
>On Fri, May 9, 2014 at 5:29 PM, Jim Michaels wrote:
>> I could not find a good example on this be
Jim Michaels said:
> I could not find a good example on this because examples in books are scarce
> as hen's teeth. search engines ignore the * character and maybe even
> interpret it like a wildcard. :-/ so examples on the web are out.
>
> #include
> int main(void) {
> double d=1234567890
Hi Jim!
On Fri, May 9, 2014 at 5:29 PM, Jim Michaels wrote:
> I could not find a good example on this because examples in books are scarce
> as hen's teeth. search engines ignore the * character and maybe even
> interpret it like a wildcard. :-/ so examples on the web are out.
>
> #include
> int
I could not find a good example on this because examples in books are scarce as
hen's teeth. search engines ignore the * character and maybe even interpret it
like a wildcard. :-/ so examples on the web are out.
#include
int main(void) {
double d=1234567890.123456789;
int width=7,precis
On 8/22/2012 02:35, Greg Peele wrote:
>
> Hi all,
> Did MinGW-w64 GCC change behavior at some point regarding printf and long
> long? My understanding is that you should use the Microsoft non-standard
> specifiers %I64d and %I64u and my GCC 4.5.1 is fine with it, but I get the
> following war
On Tue, Aug 21, 2012 at 3:11 PM, Greg Peele wrote:
>
>
>> Date: Tue, 21 Aug 2012 14:46:51 -0400
>> From: ear...@users.sourceforge.net
>> To: mingw-w64-public@lists.sourceforge.net
>> Subject: Re: [Mingw-w64-public] printf + long long on GCC 4.7.1
>>
>> O
> Date: Tue, 21 Aug 2012 14:46:51 -0400
> From: ear...@users.sourceforge.net
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] printf + long long on GCC 4.7.1
>
> On Tue, Aug 21, 2012 at 2:35 PM, Greg Peele wrote:
> >
> > If this is
On Tue, Aug 21, 2012 at 2:35 PM, Greg Peele wrote:
>
> If this is a spurious warning, I can use -Wno-format to suppress it (this
> inline method gets included a LOT of places in my code) but of course that
> loses the ability of using that warning as a legitimate way to warn about
> printf bugs.
>
Hi all,
Did MinGW-w64 GCC change behavior at some point regarding printf and long long?
My understanding is that you should use the Microsoft non-standard specifiers
%I64d and %I64u and my GCC 4.5.1 is fine with it, but I get the following
warning because of that in GCC 4.7.1 (rubenvb's build
011 11:50 AM
>Subject: Re: [Mingw-w64-public] printf issues...
>
>
>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, Ozk
- Original Message -
From: "David Cleaver"
>>> He has informed me that he is not in a cygwin environment. However, I
>>> forgot to
>>> ask what OS he was using.
He *is* watching - but a bit pressed for time.
The OS is Windows Vista64 - so I expect we're seeing a difference in msvc
r
Hello David!
On Sat, Dec 17, 2011 at 2:50 PM, David Cleaver wrote:
> ...
> I see lots of information online regarding when Visual Studio/Visual C++
> versions started being able to use the ll modifier (since version VC++
> 2003/7.1,
> apparently), but I don't see the same information detailing w
For VC 2003 you can see on msdn
http://msdn.microsoft.com/en-us/library/56e442dc%28v=vs.71%29.aspx
that 'll' wasn't supported.
Kai
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn W
2011/12/17 David Cleaver :
>
> 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
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
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:
Hello Everyone,
I seem to have run into an issue with printf with my native toolchain that
>
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:
>>> Hello Everyone,
>>>
>>> I seem to have run into an issue with printf with my native toolchain that
>>> someone else with the cross-com
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 hel
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 down what might be the difference between ou
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
float)e);
printf ("fe=%f\n", e);
printf ("ee=%e\n", e);
printf ("gd=%g (d)\n", (double)d);
cout<<"d="<
>From: Little
>To: mingw-w64-public@lists.sourceforge.net
>Sent: Tuesday, April 26, 2011 3:56
It's a new problem after 4.7-20110416.
-Original Message-
From: Simon de Graaf [mailto:s.degr...@tudelft.nl]
Sent: Wednesday, April 27, 2011 11:31 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] printf %f format does not work to print
doubles/floats
On Wed, Apr 27, 2011 at 6:30 PM, Simon de Graaf wrote:
> Yes, i have the same output (tested on XP Prof. 64 bit).
> I also verified my old 64 bit cross-compiler tree
> and it has the same problem
> ( archive: mingw-w64-bin_i686-linux_20100224.tar.bz2 ).
Well, I was ready to accept problems from
Yes, i have the same output (tested on XP Prof. 64 bit).
I also verified my old 64 bit cross-compiler tree
and it has the same problem
( archive: mingw-w64-bin_i686-linux_20100224.tar.bz2 ).
Thanks for your help and quick response.
On 27/04/11 17:17, Ozkan Sezer wrote:
> On Wed, Apr 27, 2011 at 5
On Wed, Apr 27, 2011 at 5:42 PM, Simon de Graaf wrote:
> Automatic build:
>
> mingw-w64-bin_i686-linux_20110423.tar.bz2
>
> Program code:
>
> #include
>
> int main ()
> {
> long double d = 16.125e-08;
> double e = 8.125e-08;
>
> printf ("ge=%g (f)\n", (float)e);
> printf ("ge=
Automatic build:
mingw-w64-bin_i686-linux_20110423.tar.bz2
Program code:
#include
int main ()
{
long double d = 16.125e-08;
double e = 8.125e-08;
printf ("ge=%g (f)\n", (float)e);
printf ("ge=%g\n", e);
printf ("fe=%f (f)\n", (float)e);
printf ("fe=%f\n", e)
On Wed, Apr 27, 2011 at 5:27 PM, Simon de Graaf wrote:
> Hi,
Hi: we might need a little bit more detail,
>
> I downloaded the latest cross-compiler and found out
Precisely which one?
> that the printf %f format does not work to print doubles/floats.
> It gives back a zero value.
>
Can you pl
Hi,
I downloaded the latest cross-compiler and found out
that the printf %f format does not work to print doubles/floats.
It gives back a zero value.
Regards
Simon de Graaf
--
WhatsUp Gold - Download Free Network Managem
On Tue, Dec 22, 2009 at 10:01 PM, Kai Tietz wrote:
> Well, we have here (at least for the native printf functions) to
> assume smallest supported feature-set. By using msvcrt.dll (Vista or
> newer) you are using in fact msvcr80.dll + feature set, which supports
> %ll specifier, but older ms runtim
2009/12/22 Alon Bar-Lev :
> On Tue, Dec 22, 2009 at 7:53 PM, Tor Lillqvist wrote:
>>> But this is *UGLY* And I don't have inttypes.h on all platforms...
>>> For example solaris8 does not define these constants.
>>
>> That is why there exists libraries and higher level languages that
>> make po
On Tue, Dec 22, 2009 at 7:53 PM, Tor Lillqvist wrote:
>> But this is *UGLY* And I don't have inttypes.h on all platforms...
>> For example solaris8 does not define these constants.
>
> That is why there exists libraries and higher level languages that
> make portability easier.
>
> For instanc
> But this is *UGLY* And I don't have inttypes.h on all platforms...
> For example solaris8 does not define these constants.
That is why there exists libraries and higher level languages that
make portability easier.
For instance, GLib has G_GINT64_FORMAT. And then there is Java.
--tml
On Tue, Dec 22, 2009 at 7:44 PM, Tor Lillqvist wrote:
>> I found [1], which states that Microsoft does not support %ll variant.
>> But I checked this in Visual Studio and it is supported.
>> So where is the catch?
>
> There are several different C libraries from Microsoft. Some support
> %ll, some
> I found [1], which states that Microsoft does not support %ll variant.
> But I checked this in Visual Studio and it is supported.
> So where is the catch?
There are several different C libraries from Microsoft. Some support
%ll, some don't. (They all support %I64d.) Use PRId64 etc from
, that's
Hello,
I found [1], which states that Microsoft does not support %ll variant.
But I checked this in Visual Studio and it is supported.
So where is the catch?
Thanks,
Alon.
[1]
http://sourceforge.net/tracker/index.php?func=detail&aid=2818436&group_id=2435&atid=102435
--
On Sun, Sep 20, 2009 at 4:52 AM, Kai Tietz wrote:
> To solve those kind of issues inttypes.h is there, and is btw also
> adjusted by our header-set when __USE_MINGW_ANSI_STDIO is defined. A
> mix mode between platform M$ printf formats and gnu'ish one is in
> general a bad idea.
FWIW, when VLC ha
On Sun, Sep 20, 2009 at 12:05 PM, Erik de Castro Lopo
wrote:
> Ozkan Sezer wrote:
>
>> Should I commit this then:
>>
>> Index: _mingw.h
>> ===
>> --- _mingw.h (revision 1397)
>> +++ _mingw.h (working copy)
>> @@ -441,20 +441,10 @@
>
Ozkan Sezer wrote:
> Should I commit this then:
>
> Index: _mingw.h
> ===
> --- _mingw.h (revision 1397)
> +++ _mingw.h (working copy)
> @@ -441,20 +441,10 @@
> #define _TRUNCATE ((size_t)-1)
> #endif
>
> -#ifndef __USE_MINGW_AN
On Sun, Sep 20, 2009 at 12:00 PM, Kai Tietz wrote:
> 2009/9/20 Ozkan Sezer :
>> On Sun, Sep 20, 2009 at 11:52 AM, Kai Tietz wrote:
>>> To solve those kind of issues inttypes.h is there, and is btw also
>>> adjusted by our header-set when __USE_MINGW_ANSI_STDIO is defined. A
>>> mix mode between p
2009/9/20 Ozkan Sezer :
> On Sun, Sep 20, 2009 at 11:52 AM, Kai Tietz wrote:
>> To solve those kind of issues inttypes.h is there, and is btw also
>> adjusted by our header-set when __USE_MINGW_ANSI_STDIO is defined. A
>> mix mode between platform M$ printf formats and gnu'ish one is in
>> general
On Sun, Sep 20, 2009 at 11:52 AM, Kai Tietz wrote:
> To solve those kind of issues inttypes.h is there, and is btw also
> adjusted by our header-set when __USE_MINGW_ANSI_STDIO is defined. A
> mix mode between platform M$ printf formats and gnu'ish one is in
> general a bad idea.
>
> Kai
>
Should
To solve those kind of issues inttypes.h is there, and is btw also
adjusted by our header-set when __USE_MINGW_ANSI_STDIO is defined. A
mix mode between platform M$ printf formats and gnu'ish one is in
general a bad idea.
Kai
2009/9/20 Kai Tietz :
> 2009/9/20 Ozkan Sezer :
>> On Sun, Sep 20, 2009
2009/9/20 Ozkan Sezer :
> On Sun, Sep 20, 2009 at 2:55 AM, Erik de Castro Lopo
> wrote:
>>
>> Please note, I am subscribed to the list. No need to CC me on reply.
>>
>> Ozkan Sezer wrote:
>>
>>> A question, though: Are you using gcc-3.4.5 or 4.4.0 as the mingw.org
>>> compiler for your w32 builds?
On Sun, Sep 20, 2009 at 2:55 AM, Erik de Castro Lopo
wrote:
>
> Please note, I am subscribed to the list. No need to CC me on reply.
>
> Ozkan Sezer wrote:
>
>> A question, though: Are you using gcc-3.4.5 or 4.4.0 as the mingw.org
>> compiler for your w32 builds? I think the warning may be a gcc-
Please note, I am subscribed to the list. No need to CC me on reply.
Ozkan Sezer wrote:
> A question, though: Are you using gcc-3.4.5 or 4.4.0 as the mingw.org
> compiler for your w32 builds? I think the warning may be a gcc-4.4+
> thing and not actually a mingw-w64 issue, but I don't know for
On Sun, Sep 20, 2009 at 1:08 AM, Erik de Castro Lopo
wrote:
> Ozkan Sezer wrote:
>
>> OK, applied this as rev. 1395:
>> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64?view=rev&revision=1395
>> Please test.
>
> Real close!
>
> I get the proper C99 behaviour if I compile with:
>
> x86_64-
Ozkan Sezer wrote:
> OK, applied this as rev. 1395:
> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64?view=rev&revision=1395
> Please test.
Real close!
I get the proper C99 behaviour if I compile with:
x86_64-w64-mingw32-gcc -Wall -std=c99 test.c -o test
but with this:
x86_64-
OK, applied this as rev. 1395:
http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64?view=rev&revision=1395
Please test.
--
Ozkan
On Sat, Sep 19, 2009 at 1:41 PM, Ozkan Sezer wrote:
> On Sat, Sep 19, 2009 at 1:38 PM, Kai Tietz wrote:
>> Ok, add it to our _mingw.h file, too. We can then simplif
On Sat, Sep 19, 2009 at 1:38 PM, Kai Tietz wrote:
> Ok, add it to our _mingw.h file, too. We can then simplify our logic
Will do.
> in our _mingw_printf_(push/pop).h headers, too, as we know that
> __USE_MINGW_ANSI_STDIO is defined in any case to zero or one, isn't
> it?
If you are referring to
Ok, add it to our _mingw.h file, too. We can then simplify our logic
in our _mingw_printf_(push/pop).h headers, too, as we know that
__USE_MINGW_ANSI_STDIO is defined in any case to zero or one, isn't
it?
Cheers,
Kai
2009/9/19 Ozkan Sezer :
> On Sat, Sep 19, 2009 at 1:13 PM, Erik de Castro Lopo
>
On Sat, Sep 19, 2009 at 1:13 PM, Erik de Castro Lopo
wrote:
> Ozkan Sezer wrote:
>
>> You need it with both. (Although, if your w32 toolchain is
>> a mingw.org toolchain and not ours, they may have automatically
>> defined __USE_MINGW_ANSI_STDIO as 1 upon seeing -std=c99. Kai,
>> should we do th
Ozkan Sezer wrote:
> You need it with both. (Although, if your w32 toolchain is
> a mingw.org toolchain and not ours, they may have automatically
> defined __USE_MINGW_ANSI_STDIO as 1 upon seeing -std=c99. Kai,
> should we do that?)
Yes, please!
Cheers,
Erik
--
---
On Sat, Sep 19, 2009 at 11:02 AM, Erik de Castro Lopo
wrote:
> Ozkan Sezer wrote:
>
>> Hmm, with my versions gcc-4.4.2 (svn r151768, patched but
>> nothing that would affect this) and mingw-w64 r1375-r1378,
>> I get:
>>
>> x86_64-pc-mingw32-gcc -Wall -std=gnu99 test.c
>> test.c: In function 'main'
Ozkan Sezer wrote:
> Hmm, with my versions gcc-4.4.2 (svn r151768, patched but
> nothing that would affect this) and mingw-w64 r1375-r1378,
> I get:
>
> x86_64-pc-mingw32-gcc -Wall -std=gnu99 test.c
> test.c: In function 'main':
> test.c:6: warning: unknown conversion type character 'z' in format
On Sat, Sep 19, 2009 at 9:20 AM, Erik de Castro Lopo
wrote:
> Ozkan Sezer wrote:
>
>> - Which svn revision of mingw-w64 headers and crt did you
>> use in your toolchain ?
>
> Same revision for both :
>
> Path: .
> URL: https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/trunk
> Reposi
Ozkan Sezer wrote:
> - Which svn revision of mingw-w64 headers and crt did you
> use in your toolchain ?
Same revision for both :
Path: .
URL: https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/trunk
Repository Root: https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64
Re
On Sat, Sep 19, 2009 at 1:12 AM, Erik de Castro Lopo
wrote:
> Using built-in specs.
> Target: x86_64-w64-mingw32
> Configured with: ../../../build/gcc/gcc/configure
> --target=x86_64-w64-mingw32
> --prefix=/Testing/build/root --with-sysroot=/Testing/build/root
> --enable-langu
Kai Tietz wrote:
> The issue is that the linux pre-build version of our toolchain is
> out-dated. You are using mingw-w64-bin_i686-linux_20090612.tar.bz2,
> which doesn't provide this feature.
Ok, I've built an i686 Linux to win64 cross compiler using the script:
https://mingw-w64.svn.source
NightStrike wrote:
> Any chance you'd like to contribute your builds? :)
Sure.
> We are in need of a 32-bit linux machine to run as a build slave.
My machine is a laptop and is not always on, nor is it always connected
to the net.
Erik
--
-
On Fri, Sep 18, 2009 at 7:35 AM, Erik de Castro Lopo
wrote:
> Erik de Castro Lopo wrote:
>
>> Ok, I've built an i686 Linux to win64 cross compiler using the script:
>>
>>
>> https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/experimental/buildsystem/makebuildroot.mk
>>
>> Unfortunately I
Erik de Castro Lopo wrote:
> Ok, I've built an i686 Linux to win64 cross compiler using the script:
>
>
> https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/experimental/buildsystem/makebuildroot.mk
>
> Unfortunately I am now getting "undefined reference to `sin'" on code
Sorry, please
Kai Tietz wrote:
> Hello Erik,
>
> The issue is that the linux pre-build version of our toolchain is
> out-dated. You are using mingw-w64-bin_i686-linux_20090612.tar.bz2,
> which doesn't provide this feature.
Ok, I've built an i686 Linux to win64 cross compiler using the script:
https://min
Hello Erik,
The issue is that the linux pre-build version of our toolchain is
out-dated. You are using mingw-w64-bin_i686-linux_20090612.tar.bz2,
which doesn't provide this feature.
Sadly we have at the moment a lack in machines for doing an automated
build for linux (32-bit). The 64-bit we provi
On Fri, Sep 18, 2009 at 1:14 AM, Erik de Castro Lopo
wrote:
> Ozkan Sezer wrote:
>
>> I'm not sure whether msvcrt supports the %z size_t conversion.
>
> I'm pretty damn sure it doesn't :-).
>
>> You can, however, use the posix compliant mingw version.
>
> Its not POSIX, its ISO C99 :-).
>
>> You
Ozkan Sezer wrote:
> I'm not sure whether msvcrt supports the %z size_t conversion.
I'm pretty damn sure it doesn't :-).
> You can, however, use the posix compliant mingw version.
Its not POSIX, its ISO C99 :-).
> You can do it by either of these two ways:
>
> 1. You can compile your source
On Thu, Sep 17, 2009 at 5:55 AM, Erik de Castro Lopo
wrote:
> Hi all,
>
> I'm using mingw-w64-bin_i686-linux_20090612.tar.bz2 which is the latest
> I can find and running into problems compiling stuff like:
>
> printf ("Bad file length (%" PRId64 " should be %zd).\n", retval, sizeof
> (data_ou
Hi all,
I'm using mingw-w64-bin_i686-linux_20090612.tar.bz2 which is the latest
I can find and running into problems compiling stuff like:
printf ("Bad file length (%" PRId64 " should be %zd).\n", retval, sizeof
(data_out)) ;
The code works correctly for standard modern gccs on Linux system
81 matches
Mail list logo
