Discussion:
armhf toolchain with glibc 2.13
Aaron R
2016-01-30 13:35:11 UTC
Permalink
Hi,

My ARM target runs glibc 2.13 and I am having a hard time finding a
linaro toolchain for it. It seems like all the ones I have found ship with
glibc 2.15 (even old ones).

Where can I find the binaries for a linux toolchain that targets armhf
with glibc 2.13?

Thanks in advance
Jim Wilson
2016-02-01 19:49:23 UTC
Permalink
Post by Aaron R
My ARM target runs glibc 2.13 and I am having a hard time finding a
linaro toolchain for it. It seems like all the ones I have found ship with
glibc 2.15 (even old ones).
If you link statically, most code compiled against a newer glibc is
likely to work. One potential problem is that a newer glibc might
call a newer kernel syscall entry point, which may not exist in your
kernel if you have an old one, but this is likely to be a rare
problem. And of course anything that requires dynamic linking won't
work if statically linked, but this is usually only a problem for
large and complex programs.
Post by Aaron R
Where can I find the binaries for a linux toolchain that targets armhf
with glibc 2.13?
It looks like we have some very old releases that used eglibc-2.13
http://releases.linaro.org/archive/12.03/components/toolchain/binaries/
This was only tested on 4 year old linux versions which are obsolete,
and is so old that we don't support it anymore. This being one of the
very first binary toolchain releases from Linaro, I have no idea how
well it works.

You may be better off if you build one yourself. If you can copy files
off of your target, then create a target sysroot containing /lib,
/usr/lib, and /usr/include. Put a copy of this target sysroot on your
cross compiler host. Then configure binutils and gcc using
--with-sysroot= pointing at the path to the target sysroot. You only
need to build binutils and gcc, and you need to configure, build, and
install binutils before doing the same for gcc. You can get the
target gcc configure options by using gcc -v on the target, then
adjust the options so that they make sense on the cross compiler build
system, e.g. don't use --prefix=/usr as you should not install the
cross compiler into /usr on the build system.

Jim

Loading...