ARMv4 vs ARMv6
andy at openmoko.com
Thu Oct 16 11:42:04 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
|> Can you take me through what you think the toolchain situation would
|> look like after we decided that we support v4 and v6 separately? What's
|> in that tarball then? There are two tarballs now for v4 or v6, or there
|> are both sets of libs in there to link against, or what? When a guy
|> builds his package, he can generate v4 and v6 binary packages simply,
|> and it is still valid to generate only v4 to satisfy use on both
| I beleive this is where it gets a little complex.
| gcc in the toolchain would be quite happy making armv6 or armv4
| binaries. But the libraries shipped would only be one or the other. This
| is one of the things OE hides from you. 80% of the time linking against
| the wrong arch of libraries works anyway. But knowing users they will
| find that 20% with regular annoyance.
Sounds right... but since we control at least the toolchain environment,
we can do things like have ./usr/lib as a symlink that points to either
./usr/lib-v4 or ./usr/lib-v6 as an example, and a "great big switch"
script you run to configure what you are cooking for. That'll also take
care of unpacking opkg into build host correctly if the symlink is
forced then, as far as it knows it just goes in /usr/lib but actually
it'd be the right underlying one. Then we can continue to just have one
toolchain offering that targets everything that works the same way as now.
I guess it can all be figured out but it is going to need some thought
and work it seems.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the devel