I think that is controlled by the soname conventions.
With a few exceptions (libc, ??) it goes like:
gcc ... ... -lavformat ... ...
Which gets string mangled into: libavformat.so (the processing of "-l') - - -
Then the library search path is traversed, looking for that file ;
-L<whatever>:/lib:/usr/lib
With a bit of sysroot thrown in for the flavor.
Found (in the above case):
sym-link, libavformat.so -> libavformat.so.53.0
Possible will be a chain of symlinks until you reach the full version named library file.
Now your specific symbol name is about the "exception" I mentioned above, the C library.
You might be able to change which one that gcc is referring to in its "specs" file.
gcc --dump-specs (I think) should print it for you; grep can find it for you.
Otherwise you will have to dig through the release notes of the toolchain bundle to see which version C library the tool chain was built against.
GLIBC_2.7 replaced GLIBC_2.6 somewhere along the line between 4.2 and 4.7
We already know (the hard way) that we don't want to use gcc-4.7 with the old Kindles;
You may have to use the "power of Buildroot" to churn out a gcc-4.6 tool chain with the older glibc release selected.
How much tea can you drink in the hours that will take to execute?
