Comment 16 for bug 343602

I've tested the modified libc from http://people.ubuntu.com/~lool/glibc-neon/, on kernels both with and without the CONFIG_NEON enabled.

The libc hwcap setup for NEON appears to work fine.

I put some dummy libraries in /lib and /lib/neon and wrote a simple test program:
  * using a kernel with CONFIG_NEON disabled, the library from /lib is used
  * using a kernel with CONFIG_NEON enabled, the library from /lib/neon is used (as expected).

Regarding the comment above that NEON should imply VFP, I should clarify this a bit:
  * The presence of NEON support on hardware does not necessarily mean that VFP is there (although in practice we expect that it almost always will be)
  * If VFP and NEON are both present, this does imply some extra NEON floating-point functionality, which is not available if NEON is present but VFP is absent.

So if the kernel reports HWCAP_NEON, ld.so should not automatically assume that HWCAP_VFP is present (this matches the current ld.so behaviour, so it's OK).

However, code which uses NEON floating-point functionality (probably most real NEON code) can only be guaranteed to run reliably if HWCAP_NEON and HWCAP_VFP are both reported by the kernel. glibc support this for combinations of hwcaps as /lib/vfp/neon, /lib/neon/vfp (for example), which should achieve the desired result.

Here's the output of ldconfig -p (where I've put copies of libc.so.6 in /lib/neon /lib/neon/vfp and /lib/vfp/neon (there's already one in /lib/vfp, from libc6-vfp):
        libc.so.6 (libc6, hwcap: 0x0000000000001040, OS ABI: Linux 2.6.16) => /lib/neon/vfp/libc.so.6
        libc.so.6 (libc6, hwcap: 0x0000000000001040, OS ABI: Linux 2.6.16) => /lib/vfp/neon/libc.so.6
        libc.so.6 (libc6, hwcap: 0x0000000000001000, OS ABI: Linux 2.6.16) => /lib/neon/libc.so.6
        libc.so.6 (libc6, hwcap: 0x0000000000000040, OS ABI: Linux 2.6.16) => /lib/vfp/libc.so.6
        libc.so.6 (libc6, OS ABI: Linux 2.6.16) => /lib/libc.so.6

(I think that neon/vfp and vfp/neon are interchangeable, but there may be additional subtleties. When actually running an executable, I get /lib/neon/vfp/libc.so.6 linked in, but I don't currently know whether there is a real rule at work or it is just by coincidence that this library is chosen instead of /lib/vfp/neon/libc.so.6. Probably we should choose just one of these directory combinations and stick to it:

I vote for neon/vfp (since architecturally the extra functionality is really an extension to NEON rather than an extension to VFP).

In summary, it looks like everything now works as needed to support libraries with these different hwcap combinations.