On Tue, Sep 28, 2010, Hector Oron wrote:
> The build failure in valgrind is:
> checking for a supported CPU... no (armv5tel)
> configure: error: Unsupported host architecture. Sorry
> make: *** [config.status] Error 1
>
> In the configure.in there is a check for:
> [...]
> # ARCH_MAX reflects the most that this CPU can do: for example if it
> # is a 64-bit capable PowerPC, then it must be set to ppc64 and not ppc32.
> # Ditto for amd64. It is used for more configuration below, but is not used
> # outside this file.
> case "${host_cpu}" in
> [...]
>
> armv7*)
> AC_MSG_RESULT([ok (${host_cpu})])
> ARCH_MAX="arm"
> ;;
>
> *)
> AC_MSG_RESULT([no (${host_cpu})])
> AC_MSG_ERROR([Unsupported host architecture. Sorry])
> ;;
> esac
ah, that's bad
I think that's broken even for us; it's a bit too fragile to look at
uname, especially for distros where the buildd might be a big iron, but
the binaries need to run everywhere. The triplet isn't good enough as
it carries too little information.
What worked well for me on ARM (NOT on x86 though) is probing of the
toolchain defaults; the ffmpeg source package has good examples of how
I configure various builds depending on the toolchain. Basically, try
to build something v7, if that works you can use v7 instructions. Same
for NEON, VFP etc. (debian/confflags in ffmpeg)
> I need to find out if current valgrind code could work on `armv4t'
> (which is Debian default).
Hmm before Julian started working on v7, someone was putting efforts
into an ARM port which wasn't specifically v7 or Thumb or NEON or
anything. I think the current valgrind SVN can simulate NEON on
non-NEON and vice-versa, but I'm not sure, and I don't know whether it
can run e.g. armv7 binaries on armv4. In any case, I would expect that
armv4 on armv4 should be within reach since I understand armv7 is a
superset.
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
