So __aeabi_memcpy is looking to be resolved via a static link, which is why using -static works. I believe if you compiled foo.o a little differently, so that it expects a shared C library, then you could link to foo.a without specifying -static. Unfortunately, I'm not familiar with the RVCT compiler, or I'd tell you how.
I'm trying to compile libpng & zlib using the RVCT 4.0 armcc compiler. However armcc cannot find 'fcntl.h', which I assume is a standard C library. Cygwin has fcntl.h (and the associated files types.h and _types.h), but when I use those, I get various compilation errors.
The platforms and compilers discussed in this section apply specifically to embedded testing, which implies generation (and possibly validation) of tests on host, and execution of tests on a target board. If users perform only host-based testing of embedded code, platform/compiler support is determined by the main support table at the beginning of this document.
In most cases, using a cross-compiler requires preparing specific project configurations based on the built-in configurations for host-based compilers (GCC or Green Hills). If not specified otherwise, full code analysis is supported.
Texas Instruments, finally, have made a formal release, v4.6.1, of their TMS470 compiler incorporating various fixes allowing it to build a moderately patched FFmpeg. The performance remains somewhere between GCC and RVCT on average.
Regardless of which compiler is chosen, I cannot overstress the importance of testing. All compilers are crawling with bugs, and even the most innocent-looking code change can trigger one of them. When using a compiler other than GCC, extra caution is advised considering a lot of code is developed using only GCC and may thus fall prey to bugs unique to said other compiler.
A proper comparison of different compilers targeting ARM is long overdue, so I decided to do my part. I compiled FFmpeg using a selection of compilers, and measured the speed of the result when decoding various media samples. Since we are testing compilers, I disabled all hand-written assembler. The tests were run on a Beagle board clocked at 600 MHz.
The C++ compiler accepts the C++ language of the ISO/IEC 14882:1998 C++ standard (with some minor exceptions) and can be seen as a preprocessor or front end which accepts C++ source files or sources using C++ language features. The output generated by the C++ compiler is C, which can be translated by the C compiler. The C++ compiler also accepts embedded C++ language extensions.
OptionDescription--fpu=fpuWith this option you define the kind of FPU support with which you create your application.--unaligned-accessWith this option you tell the compiler to generate more efficient instructions to access unaligned 16-bit or larger data. Halfword or word load and store instructions are used instead of byte instructions. This option is only useful for cores that have support for unaligned access.--call=near
-mfTo address the memory of the ARM, you can use far 32-bit indirect calls or near 26-bit PC-relative calls.
This option is especially relevant for ARMv6-M. For other architectures near calls (the default) are preferred and the linker will generate veneers if necessary.