| Message ID | 7a2800c2cb33d674a82e1396354225549458a708.1338732273.git.thomas.petazzoni@free-electrons.com |
|---|---|
| State | Changes Requested |
| Headers | show |
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Thomas> The 2012.03 version of the x86 toolchain uses glibc 2.15, which
Thomas> doesn't provide RPC functions. This breaks most packages for now,
Thomas> until we package TI-RPC properly.
Seems like cut'n'paste from patch 9.
"Most packages" is probably somewhat exaggerated - We have very few
packages depending on BR2_INET_RPC:
git grep -l BR2_INET_RPC package/**/Config.in
package/lmbench/Config.in
package/netkitbase/Config.in
package/netkittelnet/Config.in
package/nfs-utils/Config.in
package/portmap/Config.in
Or have you found other packages where we're missing the BR2_INET_RPC
annotation?
Le Mon, 04 Jun 2012 09:48:38 +0200, Peter Korsgaard <jacmet@uclibc.org> a écrit : > >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > > Thomas> The 2012.03 version of the x86 toolchain uses glibc 2.15, which > Thomas> doesn't provide RPC functions. This breaks most packages for now, > Thomas> until we package TI-RPC properly. > > Seems like cut'n'paste from patch 9. Yes :) > "Most packages" is probably somewhat exaggerated - We have very few > packages depending on BR2_INET_RPC: > > git grep -l BR2_INET_RPC package/**/Config.in > package/lmbench/Config.in > package/netkitbase/Config.in > package/netkittelnet/Config.in > package/nfs-utils/Config.in > package/portmap/Config.in > > Or have you found other packages where we're missing the BR2_INET_RPC > annotation? There are some packages that do not depend on BR2_INET_RPC, but that enable stuff when BR2_INET_RPC is enable. Take for example package/busybox :-) For the moment, the external toolchain code assumes that if the external toolchain uses (e)glibc, then it has RPC support, so it always enables BR2_INET_RPC. Obviously, this is what is broken, but I'd prefer to add proper support for TI-RPC to not leave users using modern toolchains with absolutely no solution for RPC support. For now, if you choose one of those toolchains, even Busybox does not build (complains that rpc.h doesn't exist), which explains why I preferred to not make those toolchains the default ones, until I find the time to work on TI-RPC integration. Regards, Thomas
diff --git a/toolchain/toolchain-external/Config.in b/toolchain/toolchain-external/Config.in index f632deb..c8c1f14 100644 --- a/toolchain/toolchain-external/Config.in +++ b/toolchain/toolchain-external/Config.in @@ -5,6 +5,10 @@ choice # Don't use the latest Sourcery CodeBench on x86 by default, # because it uses glibc 2.15, which lacks RPC functions. default BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_X86_201109 if BR2_i386 || BR2_x86_64 + # Don't use the latest Sourcery CodeBench on SuperH by + # default, because it uses glibc 2.15, which lacks RPC + # functions. + default BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_SH201103 if BR2_sh4a || BR2_sh4aeb config BR2_TOOLCHAIN_EXTERNAL_LINARO_2012_05 bool "Linaro 2012.05"
The 2012.03 version of the x86 toolchain uses glibc 2.15, which doesn't provide RPC functions. This breaks most packages for now, until we package TI-RPC properly. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- toolchain/toolchain-external/Config.in | 4 ++++ 1 file changed, 4 insertions(+)