On 17 March 2012 04:32, Asa Sandahl <asa.sand...@linaro.org> wrote: > Hi! > > * V8 - SunSpider > The pieces for building in cbuild and parsing with the > linaro-toolchain-benchmark scripts are in place. Ran the SunSpider benchmark > across a few toolchains with the o2-neon and o3-neon variants. > I have documented my work on this page, but not analyzed the results yet. > https://wiki.linaro.org/AsaSandahl/Sandbox/JavaScriptBenchmark > > What worries me is that there is too much variation in some of the test > results. Probably caused by the garbage collection kicking in at > unpredictable times. I will try to monitor the gc and investigate if it can > be controlled somehow. > > I would like to do a gcc-4.4 run as well. Android's original toolchain is > based on gcc-4.4.3(?) and that is what I compared against when doing > measurements internally. > However, I have problem compiling C++ with gcc-4.4 - it is this one again: > home/asa-san/cbuild/slaves/ursa3/gcc-4.4.5/gcc-binary/bin/../libexec/gcc/armv7l-unknown-linux-gnueabi/4.4.5/cc1plus: > /home/asa-san/cbuild/slaves/ursa3/gcc-4.4.5/gcc-binary/lib/libstdc++.so.6: > version `GLIBCXX_3.4.14' not found (required by /usr/lib/libppl.so.7)
This is a problem with the auto builders. GCC itself is built against the system libraries which were originally built with GCC 4.5 and the 4.5 libstdc++. When we go to run a test, I put the just-built compiler in the LD_LIBRARY_PATH. This is good for built programs, but means the system libraries try to run against an earlier libstdc++. The hack around is to remove the LD_LIBRARY_PATH=foo from the script when building C++ programs. -- Michael _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
