On Mon, 28 Jun 2010, Sergei Gavrikov wrote:
On Mon, 28 Jun 2010, Simon Kallweit wrote:
On 06/28/2010 02:59 PM, John Dallaway wrote:
Hi Simon
Simon Kallweit wrote:
Here is the updated patch.
Added a generic implementation for the NextPow2, which is currently
suboptimal but mimics what the x86 implementation is doing. Also removed
the introduced change in include/ustl/uctrstrm.h so it should build
again with -fno-rtti.
Thank you. Tests are now building fine for M5272C3 but there's an error
building for the synthetic target on my CentOS 5 (32-bit) box:
gcc -L/var/tmp/ustl-test/install/lib -Ttarget.ld -o
/var/tmp/ustl-test/install/tests/language/cxx/ustl/current/tests/bvt23
tests/bvt23.o -g -nostdlib -Wl,--gc-sections -Wl,-static
tests/bvt23.o: In function `ustl::simd::fround<double,
int>::operator()(double const&) const':
/var/tmp/ustl-test/install/include/ustl/simd.h:109: undefined reference
to `lrint'
/var/tmp/ustl-test/install/include/ustl/simd.h:109: undefined reference
to `lrint'
/var/tmp/ustl-test/install/include/ustl/simd.h:109: undefined reference
to `lrint'
tests/bvt23.o: In function `ustl::simd::fround<float,
int>::operator()(float const&) const':
/var/tmp/ustl-test/install/include/ustl/simd.h:107: undefined reference
to `lrintf'
/var/tmp/ustl-test/install/include/ustl/simd.h:107: undefined reference
to `lrintf'
/var/tmp/ustl-test/install/include/ustl/simd.h:107: undefined reference
to `lrintf'
collect2: ld returned 1 exit status
make[1]: ***
[/var/tmp/ustl-test/install/tests/language/cxx/ustl/current/tests/bvt23]
Error 1
make[1]: Leaving directory `/var/tmp/ustl-test/language/cxx/ustl/current'
make: *** [tests] Error 2
Are you seeing this error?
It builds fine on my Ubuntu 10.04 LTS 32-bit :/
Hi Simon
and John,
I built successfully uSTL tests using the Simon's latest patch for
arm7tdmi, i386 pc (i386-elf-gcc from eCosCentric) targets.
But, when I tried to build it for i386linux target I got the same error
likes John got.
Simon, I often run update-manager :-( and my stuff is
[snip]
I will try to investigate in the issue tonight.
Hi
I could not understand why a build with native GCC wanted 'lrint'
http://www.opengroup.org/onlinepubs/009695399/functions/lrint.html
I tried a hack (added libm.a to linker GROUP), and that helped...
$ sed -i 's,libgcc_eh.a,& libm.a,' install/lib/target.ld
$ grep GROUP install/lib/target.ld
GROUP(libtarget.a libgcc.a libsupc++.a libgcc_eh.a libm.a)
Well, this was brutal hack, but it was possible to build all tests on my
Linux box. Should we implement 'lrint' in eCos libm?
Sergei
