* [Buildroot] C double type problem - at91sam9263
@ 2008-08-04 13:58 Richard Hardy
2008-08-04 14:16 ` Hinko Kocevar
0 siblings, 1 reply; 15+ messages in thread
From: Richard Hardy @ 2008-08-04 13:58 UTC (permalink / raw)
To: buildroot
> I see it too on cris architecture. I think it is uClibc related, at
least
> 0.9.29.
> I'll try to reproduce on x86..
> IMHO only printf is buggy, otherwise doubles and floats seem to have
> correct value.
When you say "doubles and floats seem to have correct value" how are you
testing them? I have tried using gdb to look at and set double values,
but I seem to get weird results. This is what led me to try to fprintf
the double values in the first place.
e.g. if I call a function with a double parameter set to "1.0", inside
the called function, gdb reports that parameter to have a value of
35532351778122413e-313. If I try to use gdb to "set" a double value I
get a segmentation fault. Integers seem to work ok.
Thanks,
Richard.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] C double type problem - at91sam9263
2008-08-04 13:58 [Buildroot] C double type problem - at91sam9263 Richard Hardy
@ 2008-08-04 14:16 ` Hinko Kocevar
2008-08-04 21:27 ` Matthew Dombroski
0 siblings, 1 reply; 15+ messages in thread
From: Hinko Kocevar @ 2008-08-04 14:16 UTC (permalink / raw)
To: buildroot
Richard Hardy wrote:
>> I see it too on cris architecture. I think it is uClibc related, at
> least
>> 0.9.29.
>> I'll try to reproduce on x86..
>> IMHO only printf is buggy, otherwise doubles and floats seem to have
>> correct value.
>
> When you say "doubles and floats seem to have correct value" how are you
> testing them?
I put a loop in your test program and expected correct number of iterations.
test = 100;
fprintf(stderr, "Test double = %f.\n", test);
while (test)
{
fprintf(stderr, "Test double = %f.\n", test);
test -= 2;
}
This spins 50-times.
On cris toolchain with gcc 4.3.1, uClibc 0.9.29:
Test double = 100000000.
Test double = 98000000.
Test double = 96000000.
Test double = 94000000.
Test double = 92000000.
Test double = 90000000.
Test double = 88000000.
Test double = 86000000.
Test double = 84000000.
Test double = 82000000.
Test double = 80000000.
Test double = 78000000.
Test double = 76000000.
Test double = 74000000.
Test double = 72000000.
Test double = 70000000.
Test double = 68000000.
Test double = 66000000.
Test double = 64000000.
Test double = 62000000.
Test double = 60000000.
Test double = 58000000.
Test double = 56000000.
Test double = 54000000.
Test double = 52000000.
Test double = 50000000.
Test double = 48000000.
Test double = 46000000.
Test double = 44000000.
Test double = 42000000.
Test double = 40000000.
Test double = 38000000.
Test double = 36000000.
Test double = 34000000.
Test double = 32000000.
Test double = 30000000.
Test double = 28000000.
Test double = 26000000.
Test double = 24000000.
Test double = 22000000.
Test double = 20000000.
Test double = 18000000.
Test double = 16000000.
Test double = 14000000.
Test double = 12000000.
Test double = 10000000.
Test double = 8000000.
Test double = 6000000.
Test double = 4000000.
Test double = 2000000.
On i386 toolchain with gcc 4.3.1, uClibc 0.9.29:
Test double = 100.000000.
Test double = 98.000000.
Test double = 96.000000.
Test double = 94.000000.
Test double = 92.000000.
Test double = 90.000000.
Test double = 88.000000.
Test double = 86.000000.
Test double = 84.000000.
Test double = 82.000000.
Test double = 80.000000.
Test double = 78.000000.
Test double = 76.000000.
Test double = 74.000000.
Test double = 72.000000.
Test double = 70.000000.
Test double = 68.000000.
Test double = 66.000000.
Test double = 64.000000.
Test double = 62.000000.
Test double = 60.000000.
Test double = 58.000000.
Test double = 56.000000.
Test double = 54.000000.
Test double = 52.000000.
Test double = 50.000000.
Test double = 48.000000.
Test double = 46.000000.
Test double = 44.000000.
Test double = 42.000000.
Test double = 40.000000.
Test double = 38.000000.
Test double = 36.000000.
Test double = 34.000000.
Test double = 32.000000.
Test double = 30.000000.
Test double = 28.000000.
Test double = 26.000000.
Test double = 24.000000.
Test double = 22.000000.
Test double = 20.000000.
Test double = 18.000000.
Test double = 16.000000.
Test double = 14.000000.
Test double = 12.000000.
Test double = 10.000000.
Test double = 8.000000.
Test double = 6.000000.
Test double = 4.000000.
Test double = 2.000000.
> I have tried using gdb to look at and set double values,
> but I seem to get weird results. This is what led me to try to fprintf
> the double values in the first place.
>
> e.g. if I call a function with a double parameter set to "1.0", inside
> the called function, gdb reports that parameter to have a value of
> 35532351778122413e-313. If I try to use gdb to "set" a double value I
> get a segmentation fault. Integers seem to work ok.
>
I'll do tests with gdb(server) tomorrow, I can run the test program under gdbserver
but it won't stop at breakpoints when I set them ?!?.
Regards,
Hinko
--
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] C double type problem - at91sam9263
2008-08-04 14:16 ` Hinko Kocevar
@ 2008-08-04 21:27 ` Matthew Dombroski
2008-08-05 8:31 ` Hinko Kocevar
0 siblings, 1 reply; 15+ messages in thread
From: Matthew Dombroski @ 2008-08-04 21:27 UTC (permalink / raw)
To: buildroot
On Tue, Aug 5, 2008 at 2:16 AM, Hinko Kocevar
<hinko.kocevar@cetrtapot.si> wrote:
> Richard Hardy wrote:
>>> I see it too on cris architecture. I think it is uClibc related, at
>> least
>>> 0.9.29.
>>> I'll try to reproduce on x86..
>>> IMHO only printf is buggy, otherwise doubles and floats seem to have
>>> correct value.
>>
I had this problem some time ago, as have others, and found the
solution to be disabling uClibc's locale support.
Not ideal, but at least you can display floats, dates, etc.
http://www.busybox.net/lists/buildroot/2007-March/002232.html
http://buildroot.uclibc.org/lists/buildroot/2008-June/008945.html
http://buildroot.uclibc.org/lists/buildroot/2008-April/008176.html
~Matthew
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] C double type problem - at91sam9263
2008-08-04 21:27 ` Matthew Dombroski
@ 2008-08-05 8:31 ` Hinko Kocevar
2008-08-05 9:15 ` Hinko Kocevar
0 siblings, 1 reply; 15+ messages in thread
From: Hinko Kocevar @ 2008-08-05 8:31 UTC (permalink / raw)
To: buildroot
Matthew Dombroski wrote:
> On Tue, Aug 5, 2008 at 2:16 AM, Hinko Kocevar
> <hinko.kocevar@cetrtapot.si> wrote:
>> Richard Hardy wrote:
>>>> I see it too on cris architecture. I think it is uClibc related, at
>>> least
>>>> 0.9.29.
>>>> I'll try to reproduce on x86..
>>>> IMHO only printf is buggy, otherwise doubles and floats seem to have
>>>> correct value.
>
> I had this problem some time ago, as have others, and found the
> solution to be disabling uClibc's locale support.
> Not ideal, but at least you can display floats, dates, etc.
>
> http://www.busybox.net/lists/buildroot/2007-March/002232.html
> http://buildroot.uclibc.org/lists/buildroot/2008-June/008945.html
> http://buildroot.uclibc.org/lists/buildroot/2008-April/008176.html
>
Right.
I've confirmed that floats for cris architecture with uClibc without locale work.
But what about i386 toolchain with uClibc and locale enabled? It seem to work in my case.. I'll redo the test with clean buildroot just to be sure.
Best regards,
Hinko
--
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] C double type problem - at91sam9263
2008-08-05 8:31 ` Hinko Kocevar
@ 2008-08-05 9:15 ` Hinko Kocevar
0 siblings, 0 replies; 15+ messages in thread
From: Hinko Kocevar @ 2008-08-05 9:15 UTC (permalink / raw)
To: buildroot
Hinko Kocevar wrote:
>
> But what about i386 toolchain with uClibc and locale enabled? It seem to work in my case.. I'll redo the test with clean buildroot just to be sure.
>
As stated above - i386 + uClibc 0.9.29 locale works fine when dealing with floats and date output is fine too.
Tested inside the chrooted busybox environment with:
$ /tmp/buildroot/build_i386/staging_dir/usr/bin/i386-linux-uclibc-gcc -static -O0 -ggdb3 test.c -o float.i386
$ cat test.c
#include <stdio.h>
#include <string.h>
int main (int argc, char *argv[])
{
double test;
test = 1.0;
fprintf(stderr, "Test double = %f.\n", test);
test /= 100;
fprintf(stderr, "Test double = %f.\n", test);
test = 10;
fprintf(stderr, "Test double = %f.\n", test);
while (test)
{
fprintf(stderr, "Test double = %f.\n", test);
test -= 2;
}
return 0;
}
$ sudo chroot ./root /bin/sh
/ $ ./float.i386
Test double = 1.000000.
Test double = 0.010000.
Test double = 10.000000.
Test double = 10.000000.
Test double = 8.000000.
Test double = 6.000000.
Test double = 4.000000.
Test double = 2.000000.
/ $ set
HISTFILE='/home/hinkok/.ash_history'
HOME='/home/hinkok'
IFS='
'
LOGNAME='root'
PATH='/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin'
PPID='25055'
PS1='\w \$ '
PS2='> '
PS4='+ '
PWD='/'
SHELL='/bin/bash'
SUDO_COMMAND='/bin/chroot ./root /bin/sh'
SUDO_GID='1000'
SUDO_UID='1000'
SUDO_USER='hinkok'
TERM='xterm'
USER='root'
_='./float.i386'
Maybe is the pregenerated locale data that is causing problems?? I'll test with own homebuilt locale data instead ..
Regards,
Hinko
--
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: br2.config
Url: http://busybox.net/lists/buildroot/attachments/20080805/7f0d2514/attachment-0002.txt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: uClibc.config
Url: http://busybox.net/lists/buildroot/attachments/20080805/7f0d2514/attachment-0003.txt
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] C double type problem - at91sam9263
@ 2008-08-06 13:16 Richard Hardy
2008-08-06 13:36 ` Hinko Kocevar
2008-08-06 16:37 ` Ulf Samuelsson
0 siblings, 2 replies; 15+ messages in thread
From: Richard Hardy @ 2008-08-06 13:16 UTC (permalink / raw)
To: buildroot
> -----Original Message-----
> From: Christopher Taylor [mailto:chtaylo3 at gmail.com]
> Sent: 05 August 2008 18:38
> To: Richard Hardy
> Cc: Ulf Samuelsson; buildroot at uclibc.org
> Subject: Re: [Buildroot] C double type problem - at91sam9263
>
> Could this be related to how you are compiling the code, uclibc, and
> the OS as far as endian-ness ? big vs middle vs little endian?
>
> just a thought. I've been burned by the middle-endianness on the
> arm9261. Last I looked there were some defects in how buildroot took
> your parameters and implemented them in uClibc and the kernel (I seem
> to remeber there was a bug in uClibc that buildroot incorrectly worked
> around, but I wouldn't swear to it)
>
> -Chris
>
Thanks very much for everyone who has given me some hints so far. I
think that, as suggested, the fprintf problem is an output problem
(rather than storage). I am sort-of ignoring that for the time being.
However, the reason that I was trying to print out double values in the
first place was that I am getting lots of segmentation faults when I do
calculations involving int64_t and double values.
I am using arm-linux-gcc v4.2.1., compiled on an intel Linux box to run
on an atmel at91sam9263.
For example, one problem I found was that I was getting stack
corruptions when using "-Os" as a compiler option in (some) functions
that were being passed int64_t and double values. I fixed that by using
"-O0" instead.
However, I am getting lots of other really weird segmentation faults
when I run the compiled program, which I am having to work around one by
one (I am trying to cross-compile and use ffmpeg which does lots of
complicated internal calculations for playing mpeg files).
Is it possible that gcc 4.2.1 is a very buggy compiler version? Can
anyone suggest whether I might be better to try another version (ideally
one that Buildroot supports), and if so, which one?
Thanks again,
Richard.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] C double type problem - at91sam9263
2008-08-06 13:16 Richard Hardy
@ 2008-08-06 13:36 ` Hinko Kocevar
2008-08-06 16:37 ` Ulf Samuelsson
1 sibling, 0 replies; 15+ messages in thread
From: Hinko Kocevar @ 2008-08-06 13:36 UTC (permalink / raw)
To: buildroot
Richard Hardy wrote:
> I am using arm-linux-gcc v4.2.1., compiled on an intel Linux box to run
> on an atmel at91sam9263.
>
> For example, one problem I found was that I was getting stack
> corruptions when using "-Os" as a compiler option in (some) functions
> that were being passed int64_t and double values. I fixed that by using
> "-O0" instead.
>
That sounds like a compiler problem...
> However, I am getting lots of other really weird segmentation faults
> when I run the compiled program, which I am having to work around one by
> one (I am trying to cross-compile and use ffmpeg which does lots of
> complicated internal calculations for playing mpeg files).
>
> Is it possible that gcc 4.2.1 is a very buggy compiler version? Can
> anyone suggest whether I might be better to try another version (ideally
> one that Buildroot supports), and if so, which one?
I guess you would be better off using latest compiler available in 4.2.x series - 4.2.3 or 4.2.4 that is. I had a lot of issues with different gcc versions for cris architecture (internal compiler errors, segafaults, etc.) and ended up using 4.3.1 that does the job for now ;)
my 2 c..
--
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] C double type problem - at91sam9263
2008-08-06 13:16 Richard Hardy
2008-08-06 13:36 ` Hinko Kocevar
@ 2008-08-06 16:37 ` Ulf Samuelsson
1 sibling, 0 replies; 15+ messages in thread
From: Ulf Samuelsson @ 2008-08-06 16:37 UTC (permalink / raw)
To: buildroot
> Is it possible that gcc 4.2.1 is a very buggy compiler version? Can
> anyone suggest whether I might be better to try another version (ideally
> one that Buildroot supports), and if so, which one?
Try using -O2.
Somewhere in a remote part of my brain it says that
you want this for the kernel.
Maybe applications are affected as well.
Best Regards
Ulf Samuelsson
Thanks again,
Richard.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] C double type problem - at91sam9263
@ 2008-08-05 10:51 Richard Hardy
2008-08-05 16:37 ` Christopher Taylor
0 siblings, 1 reply; 15+ messages in thread
From: Richard Hardy @ 2008-08-05 10:51 UTC (permalink / raw)
To: buildroot
> -----Original Message-----
> From: Ulf Samuelsson [mailto:ulf.samuelsson at atmel.com]
> Sent: 05 August 2008 12:21
> To: Richard Hardy; buildroot at uclibc.org
> Subject: Re: [Buildroot] C double type problem - at91sam9263
>
> ----- Original Message -----
>
> From: Richard Hardy <mailto:richardh@oakleafconsultancy.com>
> To: buildroot at uclibc.org
> Sent: Monday, August 04, 2008 12:29 PM
> Subject: [Buildroot] C double type problem - at91sam9263
>
>
>
> Hi Everyone,
>
> I am quite new to using buildroot and embedded linux systems in
> general. However, I have managed to use buildroot to get a (nearly)
> working system up and running for an at91sam9263 board. (kernel v
2.6.22,
> uClibc v 0.9.29)
>
>
>
> I have one annoying problem though. One of the packages I am
> compiling from source uses C's "double" type, and this does not seem
to be
> behaving as I need it to.
>
>
>
> I have created a simple example program:
>
>
>
> ...
>
> int main (int argc, char *argv[])
>
> {
>
> double test;
>
> test = 1;
>
> fprintf(stderr, "Test double = %f.\n", test);
>
> }
>
>
>
>
>
> Should you not be using "%lf" instead of "%f" ?
>
> fprintf(stderr, "Test double = %lf.\n", test);
>
> fprintf(stderr, "Test double = %f.\n", test);
>
> Best Regards
> Ulf Samuelsson
>
Yes, you are right. But, it makes no difference to the output.
Best regards,
Richard.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] C double type problem - at91sam9263
2008-08-05 10:51 Richard Hardy
@ 2008-08-05 16:37 ` Christopher Taylor
0 siblings, 0 replies; 15+ messages in thread
From: Christopher Taylor @ 2008-08-05 16:37 UTC (permalink / raw)
To: buildroot
Could this be related to how you are compiling the code, uclibc, and
the OS as far as endian-ness ? big vs middle vs little endian?
just a thought. I've been burned by the middle-endianness on the
arm9261. Last I looked there were some defects in how buildroot took
your parameters and implemented them in uClibc and the kernel (I seem
to remeber there was a bug in uClibc that buildroot incorrectly worked
around, but I wouldn't swear to it)
-Chris
On Tue, Aug 5, 2008 at 6:51 AM, Richard Hardy
<richardh@oakleafconsultancy.com> wrote:
>
>
>> -----Original Message-----
>> From: Ulf Samuelsson [mailto:ulf.samuelsson at atmel.com]
>> Sent: 05 August 2008 12:21
>> To: Richard Hardy; buildroot at uclibc.org
>> Subject: Re: [Buildroot] C double type problem - at91sam9263
>>
>> ----- Original Message -----
>>
>> From: Richard Hardy <mailto:richardh@oakleafconsultancy.com>
>> To: buildroot at uclibc.org
>> Sent: Monday, August 04, 2008 12:29 PM
>> Subject: [Buildroot] C double type problem - at91sam9263
>>
>>
>>
>> Hi Everyone,
>>
>> I am quite new to using buildroot and embedded linux systems in
>> general. However, I have managed to use buildroot to get a (nearly)
>> working system up and running for an at91sam9263 board. (kernel v
> 2.6.22,
>> uClibc v 0.9.29)
>>
>>
>>
>> I have one annoying problem though. One of the packages I am
>> compiling from source uses C's "double" type, and this does not seem
> to be
>> behaving as I need it to.
>>
>>
>>
>> I have created a simple example program:
>>
>>
>>
>> ...
>>
>> int main (int argc, char *argv[])
>>
>> {
>>
>> double test;
>>
>> test = 1;
>>
>> fprintf(stderr, "Test double = %f.\n", test);
>>
>> }
>>
>>
>>
>>
>>
>> Should you not be using "%lf" instead of "%f" ?
>>
>> fprintf(stderr, "Test double = %lf.\n", test);
>>
>> fprintf(stderr, "Test double = %f.\n", test);
>>
>> Best Regards
>> Ulf Samuelsson
>>
>
> Yes, you are right. But, it makes no difference to the output.
>
> Best regards,
> Richard.
>
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] C double type problem - at91sam9263
@ 2008-08-04 13:52 Richard Hardy
0 siblings, 0 replies; 15+ messages in thread
From: Richard Hardy @ 2008-08-04 13:52 UTC (permalink / raw)
To: buildroot
> Do you get any warnings when compiling your test program? What happens
if
> you: test = 1.0;
>
> I'm thinking maybe it's a casting problem.
>
> John
>
If I do:
test = 1.0;
fprintf(stderr, "Test double = %f.\n", test);
I get exactly the same results. i.e. it displays:
1000000
Richard.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] C double type problem - at91sam9263
@ 2008-08-04 10:29 Richard Hardy
2008-08-04 12:41 ` John Voltz
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Richard Hardy @ 2008-08-04 10:29 UTC (permalink / raw)
To: buildroot
Hi Everyone,
I am quite new to using buildroot and embedded linux systems in general.
However, I have managed to use buildroot to get a (nearly) working
system up and running for an at91sam9263 board. (kernel v 2.6.22, uClibc
v 0.9.29)
I have one annoying problem though. One of the packages I am compiling
from source uses C's "double" type, and this does not seem to be
behaving as I need it to.
I have created a simple example program:
...
int main (int argc, char *argv[])
{
double test;
test = 1;
fprintf(stderr, "Test double = %f.\n", test);
}
And the output that I see is:
Test double = 1000000.
I guess that this is due to one of the options, somewhere, in either the
Linux Kernel, uClibc or something else, but I don't know how to find out
which one.
Can anyone point me in the right direction of where to look?
Thanks for your help,
Richard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080804/8b13e62e/attachment.htm
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] C double type problem - at91sam9263
2008-08-04 10:29 Richard Hardy
@ 2008-08-04 12:41 ` John Voltz
2008-08-04 12:43 ` Hinko Kocevar
2008-08-05 10:20 ` Ulf Samuelsson
2 siblings, 0 replies; 15+ messages in thread
From: John Voltz @ 2008-08-04 12:41 UTC (permalink / raw)
To: buildroot
Do you get any warnings when compiling your test program? What happens if
you: test = 1.0;
I'm thinking maybe it's a casting problem.
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080804/014d0417/attachment.htm
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] C double type problem - at91sam9263
2008-08-04 10:29 Richard Hardy
2008-08-04 12:41 ` John Voltz
@ 2008-08-04 12:43 ` Hinko Kocevar
2008-08-05 10:20 ` Ulf Samuelsson
2 siblings, 0 replies; 15+ messages in thread
From: Hinko Kocevar @ 2008-08-04 12:43 UTC (permalink / raw)
To: buildroot
Richard Hardy wrote:
> Hi Everyone,
>
> I am quite new to using buildroot and embedded linux systems in general.
> However, I have managed to use buildroot to get a (nearly) working
> system up and running for an at91sam9263 board. (kernel v 2.6.22, uClibc
> v 0.9.29)
>
>
>
> I have one annoying problem though. One of the packages I am compiling
> from source uses C's "double" type, and this does not seem to be
> behaving as I need it to.
>
>
>
> I have created a simple example program:
>
>
>
> ...
>
> int main (int argc, char *argv[])
>
> {
>
> double test;
>
> test = 1;
>
> fprintf(stderr, "Test double = %f.\n", test);
>
> }
>
>
>
> And the output that I see is:
>
>
>
> Test double = 1000000.
>
>
>
>
>
> I guess that this is due to one of the options, somewhere, in either the
> Linux Kernel, uClibc or something else, but I don't know how to find out
> which one.
>
>
>
> Can anyone point me in the right direction of where to look?
I see it too on cris architecture. I think it is uClibc related, at least 0.9.29.
I'll try to reproduce on x86..
IMHO only printf is buggy, otherwise doubles and floats seem to have correct value.
Regards,
Hinko
--
?ETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar at cetrtapot.si
Http: www.cetrtapot.si
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] C double type problem - at91sam9263
2008-08-04 10:29 Richard Hardy
2008-08-04 12:41 ` John Voltz
2008-08-04 12:43 ` Hinko Kocevar
@ 2008-08-05 10:20 ` Ulf Samuelsson
2 siblings, 0 replies; 15+ messages in thread
From: Ulf Samuelsson @ 2008-08-05 10:20 UTC (permalink / raw)
To: buildroot
----- Original Message -----
From: Richard Hardy
To: buildroot at uclibc.org
Sent: Monday, August 04, 2008 12:29 PM
Subject: [Buildroot] C double type problem - at91sam9263
Hi Everyone,
I am quite new to using buildroot and embedded linux systems in general. However, I have managed to use buildroot to get a (nearly) working system up and running for an at91sam9263 board. (kernel v 2.6.22, uClibc v 0.9.29)
I have one annoying problem though. One of the packages I am compiling from source uses C's "double" type, and this does not seem to be behaving as I need it to.
I have created a simple example program:
.
int main (int argc, char *argv[])
{
double test;
test = 1;
fprintf(stderr, "Test double = %f.\n", test);
}
Should you not be using "%lf" instead of "%f" ?
fprintf(stderr, "Test double = %lf.\n", test);
fprintf(stderr, "Test double = %f.\n", test);
Best Regards
Ulf Samuelsson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080805/858a43c6/attachment.htm
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2008-08-06 16:37 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-04 13:58 [Buildroot] C double type problem - at91sam9263 Richard Hardy
2008-08-04 14:16 ` Hinko Kocevar
2008-08-04 21:27 ` Matthew Dombroski
2008-08-05 8:31 ` Hinko Kocevar
2008-08-05 9:15 ` Hinko Kocevar
-- strict thread matches above, loose matches on Subject: below --
2008-08-06 13:16 Richard Hardy
2008-08-06 13:36 ` Hinko Kocevar
2008-08-06 16:37 ` Ulf Samuelsson
2008-08-05 10:51 Richard Hardy
2008-08-05 16:37 ` Christopher Taylor
2008-08-04 13:52 Richard Hardy
2008-08-04 10:29 Richard Hardy
2008-08-04 12:41 ` John Voltz
2008-08-04 12:43 ` Hinko Kocevar
2008-08-05 10:20 ` Ulf Samuelsson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox