This is a clean install of Gentoo on a Raspberry Pi (natively, not cross-compiled). I changed the CHOST to "armv6zk-hardfloat-linux-gnueabi" and rebuilt all packages in the system. There are no remnants of the old "armv6j-hardfloat-linux-gnueabi" anywhere, as best I can tell.

Everything was working perfectly until I tried to upgrade from sys-libs/glibc-2.16.0 to 2.17. The entire build succeeded, including installation to the staging area in /var/tmp/portage/sys-libs/glibc-2.17/image, but then Portage aborted in the middle of the merge process with:

The merge was successful, except for a bunch of ldconfig errors complaining about machine type 40, probably because all the shared objects in the /mnt/raspi tree are ARM objects, but /sbin/ldconfig is for x86_64. No big deal there. I ran "ldconfig -v" on the Raspberry Pi, and everything looked good.

So which is it? The dynamic linker can't find libgcc_s.so.1, but /etc/ld.so.cache knows where it is.

Even more perplexing: if I symlink /usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2/libgcc_s.so.1 at /usr/lib/libgcc_s.so.1, then everything works, even though the ld.so.cache has libgcc_s.so.1 only in /usr/lib/gcc/armv6zk-hardfloat-linux-gnueabi/4.7.2. It's almost as though the entry for libgcc_s.so.1 in ld.so.cache isn't being used at all.

Could this be a new bug in the dynamic linker in glibc 2.17?

I'm rebuilding sys-devel/gcc-4.7.2-r1 right now (with the symlink in place) just to see if that fixes it.

This is a clean install of Gentoo on a Raspberry Pi (natively, not cross-compiled). I changed the CHOST to "armv6zk-hardfloat-linux-gnueabi" and rebuilt all packages in the system. There are no remnants of the old "armv6j-hardfloat-linux-gnueabi" anywhere, as best I can tell.

They also found that armv6zk yields worse optimization flags than armv6j, there should therefore be no need to change; you're more likely to make it worse than better.

The SoC in the Raspberry Pi is a BCM2835, which contains an ARM1176JZFS with a VFP coprocessor. [source]
This page says the arm1176jzf-s core should use a CHOST of "armv6zk-hardfloat-linux-gnueabi" for hardfp.

I'm aware of the benchmarking that was done of armv6j versus armv6zk, and the results were mixed and equivocal in my opinion. I chose to use armv6zk because it is the canonically correct choice for the actual CPU on the board. Gentoo is about choice, is it not? I followed Gentoo's CHOST migration guide, and I'm not a bumbling newb; I've been using Gentoo since about 2005.

So while I appreciate your trying to get me the best performance possible out of Gentoo on my Raspberry Pi, you haven't answered any of my questions or solved my problem.

I chose to use armv6zk because it is the canonically correct choice for the actual CPU on the board. Gentoo is about choice, is it not? ... So while I appreciate your trying to get me the best performance possible out of Gentoo on my Raspberry Pi, you haven't answered any of my questions or solved my problem.

Why exactly is this choice the correct one? As far as you seem to care, your choice seems quite uneducated. The only real benefit I think you could get are security extensions, but since you did not mention them you are likely not going to use them; therefore what you really achieve is just a cut in performance. I was just making sure that you're not pursuing the wrong goal, because you haven't told me the right goal; after all, you're changing the CHOST to a target for which you seem not to know if it gains you in a positive or negative way. Therefore you're stating a X-Y problem here that needs to be clarified, but if you really just want to be blind then go ahead and fix the problem and enjoy what is likely to be a slower security extended Raspberry Pi; the missing piece is:

If you changed too much apart from the guide, you may have broken this approach too. Also, you may want to build the toolchain once again...

PS: I am running a Raspberry Pi myself and find changing the CHOST something interesting to look into, therefore I was wondering whether you knew of an actual positive benefit other than the security extensions.

Thanks for re-affirming, so this would mean that all this would do is make the toolchain itself slower (and provide support for building security extensions into it, if the toolchain at all supports that).

I chose to use armv6zk because it is the canonically correct choice for the actual CPU on the board. Gentoo is about choice, is it not? ... So while I appreciate your trying to get me the best performance possible out of Gentoo on my Raspberry Pi, you haven't answered any of my questions or solved my problem.

Why exactly is this choice the correct one?

Why would Gentoo say "The following list describes the appropiate [sic] CHOSTs for specific ARM cores" if the CHOSTs in the table were not in fact the appropriate CHOSTs for the specific ARM cores listed? I try to be as specific and accurate as possible about how I describe my target CPU to GCC. I trust GCC to make correct decisions about which instructions and instruction sequences will execute fastest on the target. And moreover, I trust that future improvements to GCC will improve my performance if I'm correctly specifying my CPU but could actually hurt my performance if I'm incorrectly specifying my CPU.

In the end, my whole objective in all of this is to squeeze every last bit of speed I can out of the Pi. So, to appease my curiosity, I ran nbench with four different sets of CFLAGS:

So it seems the -march flag doesn't have much of an impact here (maybe because GCC doesn't do anything with TrustZone?). The significant difference is attributable to the -mtune flag, and it seems that tuning for the arm1176jzf-s, although that is the actual core in the Raspberry Pi, results in slower performance (especially on the bitfield test) than tuning for the arm1136jf-s.

Thanks. I'll try that to see if it solves this dynamic linkage problem. If it does, I'll pay you the bounty. Do you have a Bitcoin address? (If you don't yet have one, now's a good time to make one.)

Regardless of whether that solves the linkage problem, I'll be switching my CHOST back to "armv6j-hardfloat-linux-gnueabi", as that's tied for the best of the bunch and is the present recommendation from the embedded group.

Thanks. I'll try that to see if it solves this dynamic linkage problem.

The GCC profile name appears to be "armv6zk-hardfloat-linux-gnueabi-4.7.2", not "armv6zk-hardfloat-linux-gnueabi".

The command you gave appears to be equivalent to running "gcc-config 1" (where 1 is the index of armv6zk-hardfloat-linux-gnueabi-4.7.2 in `gcc-config -l`). I had already switched my profile and recompiled both gcc and glibc under the new profile.

Are you running glibc 2.17 on your Raspberry Pi yet? I'm really thinking they changed something in the dynamic linker that broke it.

Are you running glibc 2.17 on your Raspberry Pi yet? I'm really thinking they changed something in the dynamic linker that broke it.

No, installed it last year and I barely upgrade it as long as it does its media job fine.

If that exact line (adapted to use the -4.7.2 difference you noticed) doesn't work then I have no idea for a direct fix, I saw this mentioned in one or another guide.

You may be onto something with that dynamic linker bug, for which there may likely be no direct fix but you'll surely want to report it at https://bugs.gentoo.org such that the toolchain herd is aware of it.

Hmm... What about starting from a lower stage than stage3 such that you don't have to change the CHOST and can start from the right CHOST right away? Not sure how reasonable this approach is on a RPi, though...

I have the same problem on RPi with the latest updates but CHOST=armv6j-hardfloat-linux-gnueabi and not changed.

Glad to know I'm not the only one. I'm still rebuilding back to armv6j-hardfloat-linux-gnueabi. (The Pi ain't exactly a race horse. I do use distcc, but that doesn't help the second stage of the GCC build.)