Hello,
I am currently trying to determine how much I can optimize OpenCV using the
ARM's VFP and the Linaro nano image. I have downloaded the
arm-linux-gnueabihf-gcc & arm-linux-gnueabihf-g++ compilers, successfully
cross-compiled OpenCV using those compilers (with -O3 -mfloat-abi=hard
-ftree-vectorize -funroll-loops), and compiled an example OpenCV program
with the arm-linux-gnueabihf-g++ compiler (with the same flags). However,
when I try and run my executable within Linaro (running on a gumstix overo)
I get "/lib/arm-linux-gnueabihf/libm.so.6: version `GLIBC_2.15' not found
(required by /usr/lib/libopencv_core.so.2.2).
I assume that this is because on my build machine (x86 Ubuntu 10.04) where
I cross compiled the OpenCV libraries I am using libc-2.15, and on the
target (gumstix) the loader can't find libc-2.15. However, within the
gcc-linaro-arm-linux-gnueabihf-4.7 tar ball I downloaded today, there is a
libc-2.15.so file in there that I copied into /lib/ on the gumstix. Still
no success though when I try running my executable.
Any recommendations on things to try? I am hesitant to just put a newer
version of glibc in Linaro as it seems like that could screw a lot of
things up. Should I attempt to re-build OpenCV somehow with an older
version of glibc (namely libc-2.13)?
Also, please let me know if this is the wrong forum for this question and
where I should post it instead.
Thanks,
Derek
== Progress ==
-Spawned CBUILD tasks with and without the patch proposed by Chung-Lin
Tang to test current status of "Fix EPILOGUE_USES regression in
CoreMark". Job is still in the queue.
-Read references listed in gcc/ira.c to understand gcc IRA and went
through the source code.
-Experimented with simple test cases to analyse IRA debug output.
== Plan for next week ==
- Analyse CoreMark results if ready and work on improvements.
- Start with research for Removing unnecessary zero/sign extends when
not working on "Fix EPILOGUE_USES regression in CoreMark.
== Progress ==
* Vectorizer
- Progressing on the global structure alias analysis (discussions, drafts,
failed attempts)
- Interesting Linpack results for vectorizer, investigating performance
- http://www.systemcall.org/blog/2013/02/llvm-vectorizer/
- http://llvm.org/bugs/show_bug.cgi?id=15247
* Buildbots
- Took Chromebook out, since Pandas are fast enough
- Creating LNT test-suite buildbot
- http://llvm.org/viewvc/llvm-project?view=revision&revision=175081
- http://lab.llvm.org:8011/builders/clang-native-arm-lnt
- Still a few rounds until it works properly
* Distributed Builds
- Distributed compilation works somewhat on Pandas
-
http://www.systemcall.org/blog/2013/02/distributed-compilation-on-a-pandabo…
- It's better, cheaper and easier to use Chromebooks / Arndales, though...
* LAVA
- Tracking LLVM git repo in git.linaro.org
- Trying to build from that repo, LAVA doesn't like it... :/
* EuroLLVM
- We're not sponsoring it any more, will still help organize
== Plan ==
* Continue Global Alias Analysis, I seem to be getting close to something
worth sending (and learning a lot in the process)
* Make sure LNT buildbot is up and running with vectorizer (O3)
* Check with Dave Piggot why git.linaro doesn't work with LAVA
* Inspect why some (loop+bb) vectorized results are poor on ARM
Progress:
* rebased qemu-linaro and sorted out with Serge what he requires
in the way of patches for Ubuntu's upcoming code freeze. I plan
to set up and test the 2013.03 release a week or two early both
so that there is a patchset ready for the Ubuntu freeze and also
to avoid clashing with Connect week.
* some patches to clean up QEMU's logging functions so they can
be used more widely in place of ad-hoc printf
* cleanup patchset to get rid of sysbus_add_memory() function
* LP:1079080 -- fixed serious bug in QEMU's Thumb-mode srs insn
* upstream discussion about what to do about QEMU's disassembler
license-clash issues:
http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg02122.html
* NB: I now work a 4 day week, excluding Wednesdays
-- PMM
I downloaded the aarch64 binaries to a ubuntu machine:
wink@ssi-primary:~$ uname -a
Linux ssi-primary 3.5.0-21-generic #32-Ubuntu SMP Tue Dec 11 18:51:59 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux
And when I try to run gcc-4.7.3:
wink@ssi-primary:~$ ls -al
~/aarch64-toolchain/gcc-linaro-aarch64-linux-gnu-4.7+bzr115029-20121015+bzr2506_linux/bin/aarch64-linux-gnu-gcc-4.7.3
-rwxr-xr-x 1 wink wink 553068 Oct 18 14:21
/home/wink/aarch64-toolchain/gcc-linaro-aarch64-linux-gnu-4.7+bzr115029-20121015+bzr2506_linux/bin/aarch64-linux-gnu-gcc-4.7.3
I get a file not found:
wink@ssi-primary:~$ strace
/home/wink/aarch64-toolchain/gcc-linaro-aarch64-linux-gnu-4.7+bzr115029-20121015+bzr2506_linux/bin/aarch64-linux-gnu-gcc-4.7.3
-v
execve("/home/wink/aarch64-toolchain/gcc-linaro-aarch64-linux-gnu-4.7+bzr115029-20121015+bzr2506_linux/bin/aarch64-linux-gnu-gcc-4.7.3",
["/home/wink/aarch64-toolchain/gcc"..., "-v"], [/* 19 vars */]) = -1
ENOENT (No such file or directory)
dup(2) = 3
fcntl(3, F_GETFL) = 0x8002 (flags
O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7fa688be5000
lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(3, "strace: exec: No such file or di"..., 40strace: exec: No such
file or directory
) = 40
close(3) = 0
munmap(0x7fa688be5000, 4096) = 0
exit_group(1) = ?
I must have done something real stupid, any help appreciated.
-- Wink
== Progress ==
* Very short working week.
* Discussions about next steps in Lava integration.
* Followed up on Arndale/GCC build issues.
== Next week ==
* Review pending Backports
* Investigate bootstrap ICE PR56184 further
== Future ==
* Run HOT/COLD partitioning benchmarks
* Analyse ARM results
* On x86_64 to see what the actual benefit we could get
* fix-gcc-multiarch-testing
* Come up with strawman proposal for updating testsuite to handle
testing with varying command-line options.
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
== Progress ==
* 64-bits ops in Neon: upstream accepted the patch for gcc-4.9-stage1
* smin-umin: several benchmarks runs necessary to confirm that the
generic patch I suspected actually caused the regression. However, it
also brings improvements in other benches (office-type).
* looked at libasan: very little configuration seems necessary, but
running a sample program under qemu leads to asan runtime complains.
* internal tasks
== Next ==
* smin-umin: run benchmarks on trunk to confirm the regression is also present.
* vectorizer cost model: handle Richard's feedback.
* get more codecs sample codes.
* libasan: understand error messages
Christophe.
== Progress ==
* February merge 4.6 and 4.7
- backport a patch from upstream to resolve conflicts
- this backport introduced some merge issues
- fix pushed and merge request ongoing
* Boehm GC AArch64 support:
- libatomic_ops maintainer rework the patch to make the usage of
gcc atomic builtins available on the other targets
- test exhibit some failures
* libunwind aarch64 support
- bug status moved to critical
- configuration and machine description done
- implementation ongoing
* Aarch64 porting meeting:
- Cancelled this week
== Next ==
* February merge 4.6 and 4.7
- log new testsuite failures in launchpad
* Boehm GC AArch64 support:
- fix libatomic_ops
- validate GCC's Boehm gc integration
* libunwind aarch64 support
- conitnue.
