[Buildroot] RPC support for modern (e)glibc toolchains

[Buildroot] RPC support for modern (e)glibc toolchains

[Thomas Petazzoni]

Hello,

This e-mail is a request for comments and suggestions on how to handle
RPC support in the future.

At the moment, Buildroot makes the assumption that glibc and eglibc
toolchains provide RPC support, while we are careful to handle non-RPC
uClibc toolchains, since RPC is an optional feature in uClibc.

However, this status has changes since (e)glibc 2.14 (released in May
2011) and its subsequent version 2.15 (released in March 2012). The
RPC support has been completely removed from (e)glibc, and the
developers recommend to use the tirpc library instead. Apparently,
tirpc offers additional benefits over the traditional RPC support that
was part of (e)glibc, such as improved IPv6 support.

Since quite a while, Crosstool-NG allows to produce toolchains with
(e)glibc 2.14/2.15, and since 2012.03, Sourcery CodeBench toolchains
are also using (e)glibc 2.15. None of those toolchains have RPC
support, but Buildroot for the moment assumes that they do since they
are glibc-based.

So I've created a package for libtirpc, which after a few fixes, seems
to work fine. But now, the hard part is how to handle this new package
in terms of dependencies, and this is where I'd like to have your
opinion.

I have essentially two problems:

 *) Should we consider libtirpc just an add-on for (e)glibc, and
    therefore make it visible/available/used only when a (e)glibc
    toolchain lacking RPC support is used, or instead, should we offer
    libtirpc as soon as the toolchain lacks RPC support (which would
    also be the case for uClibc toolchain with no RPC support from the
    C library) ?

 *) Should we make the dependency from packages on libtirpc a
    "select", like all other library dependencies, or a "depends on", to
    mimic what we currently do for RPC support (packages "depends on
    BR2_INET_RPC", and they show a comment if BR2_INET_RPC isn't
    available) ?

 *) How to handle the case of the Crosstool-NG backend? With the
    current Crosstool-NG backend, we have no idea which version of
    (e)glibc is being built, so we have no idea whether RPC support
    will be provided by the toolchain. Should we add a config option
    saying "My toolchain will have RPC support", which we will then
    check after the toolchain build, like we do with external
    toolchains? Other suggestions?

One possible plan is to do something like:

config BR2_TOOLCHAIN_HAS_NATIVE_RPC
       bool

This option is selected by glibc toolchains < 2.14 (external
toolchains) and by internal toolchains that have RPC support enabled.

Then, in the packages, we can do (if we decide to handle it like a
library dependency, i.e transparently for the user):

config BR2_PACKAGE_FOO
       select BR2_PACKAGE_LIBTIRPC if !BR2_TOOLCHAIN_HAS_NATIVE_RPC

and in their .mk file:

ifeq ($(BR2_PACKAGE_LIBTIRPC),y)
FOO_DEPENDENCIES += libtirpc
endif

And we unconditionally enable RPC support in the package (for example,
we tune the Busybox configuration file or other customization).

Other suggestions? Thoughts?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] RPC and Busybox

[Michael J. Hammel]

On Wed, 2012-06-27 at 00:07 +0200, Thomas Petazzoni wrote:
> And we unconditionally enable RPC support in the package (for example,
> we tune the Busybox configuration file or other customization).
> 
> Other suggestions? Thoughts?

I'm not sure which direction is best, but I have a possibly related
issue.  I have a Busybox 1.20.1 configuration that builds correctly
using an external toolchain when built on its own, but when built under
buildroot I get the following:

In file included from util-linux/mount.c:134:0:
/home/mjhammel/src/ximba/bb/src/../bld/buildroot-2012.05.bld/staging//usr/arm-unknown-linux-gnueabi/sysroot/usr/in
clude/rpc/rpc.h:2:28: fatal error: sunrpc/rpc/rpc.h: No such file or
directory
compilation terminated.
make[3]: *** [util-linux/mount.o] Error 1

I'm not sure what to look for here.  I'm using glibc toolchain built
with Crosstool-NG 1.15.1, Busybox 1.20.1, Buildroot 2012.05.  It doesn't
look like there is a sunrpc/rpc/rpc.h in the toolchain.  

Any thoughts on what I should look at here?
-- 
Michael J. Hammel <buildroot@graphics-muse.org>

[Buildroot] RPC and Busybox

[Thomas Petazzoni]

Le Tue, 26 Jun 2012 20:55:00 -0600,
"Michael J. Hammel" <buildroot@graphics-muse.org> a ?crit :

> I'm not sure what to look for here.  I'm using glibc toolchain built
> with Crosstool-NG 1.15.1, Busybox 1.20.1, Buildroot 2012.05.  It
> doesn't look like there is a sunrpc/rpc/rpc.h in the toolchain.  
> 
> Any thoughts on what I should look at here?

Which glibc version are you using? Most likely, you're using glibc 2.14
or 2.15, which don't have RPC support, as was discussed in my e-mail.
For now, there is no solution besides reverting to glibc 2.13, until we
get libtirpc packaged and integrated into Buildroot.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] RPC support for modern (e)glibc toolchains

[Thomas Petazzoni]

Le Wed, 27 Jun 2012 00:07:01 +0200,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> a ?crit :

> However, this status has changes since (e)glibc 2.14 (released in May
> 2011) and its subsequent version 2.15 (released in March 2012). The
> RPC support has been completely removed from (e)glibc, and the
> developers recommend to use the tirpc library instead. Apparently,
> tirpc offers additional benefits over the traditional RPC support that
> was part of (e)glibc, such as improved IPv6 support.
> 
> Since quite a while, Crosstool-NG allows to produce toolchains with
> (e)glibc 2.14/2.15, and since 2012.03, Sourcery CodeBench toolchains
> are also using (e)glibc 2.15. None of those toolchains have RPC
> support, but Buildroot for the moment assumes that they do since they
> are glibc-based.

Just to add a quick bit of information on this: glibc 2.16 should be
released early July, and they did some changes related to the RPC mess.
According to the glibc NEWS file, for version 2.16:

  73 * New configure option --enable-obsolete-rpc makes the deprecated RPC
  74   headers and functions available at compile time as they were before
  75   version 2.14.  This option will be removed at some time in the future
  76   after the TI-RPC library becomes fully sufficient for the needs of
  77   existing applications.

So it means that from now on, we will probably have some glibc
toolchains with RPC support included, and some other glibc toolchains
without RPC support included.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] RPC support for modern (e)glibc toolchains

[Gustavo Zacarias]

On 2012-06-26 19:07, Thomas Petazzoni wrote:

> Hello,

Hi Thomas.

> So I've created a package for libtirpc, which after a few fixes, 
> seems
> to work fine. But now, the hard part is how to handle this new 
> package
> in terms of dependencies, and this is where I'd like to have your
> opinion.

How big is libtirpc in the target? Curiosity :)

> I have essentially two problems:
>
>  *) Should we consider libtirpc just an add-on for (e)glibc, and
>     therefore make it visible/available/used only when a (e)glibc
>     toolchain lacking RPC support is used, or instead, should we 
> offer
>     libtirpc as soon as the toolchain lacks RPC support (which would
>     also be the case for uClibc toolchain with no RPC support from 
> the
>     C library) ?

I'd say while we're working at it we could do it for uClibc as well 
since it provides benefits which (probably) also apply to uClibc's RPC.

>  *) Should we make the dependency from packages on libtirpc a
>     "select", like all other library dependencies, or a "depends on", 
> to
>     mimic what we currently do for RPC support (packages "depends on
>     BR2_INET_RPC", and they show a comment if BR2_INET_RPC isn't
>     available) ?

Probably keep it as a "depends on", in some cases you'll already have 
the toolchain providing RPC.
Maybe even block libtirpc if the origin toolchain has RPC support? Or 
can they be used at the same time? (Not that anyone would want too i 
think...)

>  *) How to handle the case of the Crosstool-NG backend? With the
>     current Crosstool-NG backend, we have no idea which version of
>     (e)glibc is being built, so we have no idea whether RPC support
>     will be provided by the toolchain. Should we add a config option
>     saying "My toolchain will have RPC support", which we will then
>     check after the toolchain build, like we do with external
>     toolchains? Other suggestions?

BR2_TOOLCHAIN_I_WANT_RPC ?
After the toolchain is done we do an RPC check with readelf, if it's 
not there we build libtirpc, otherwise we leave it be.
Regards.

[Buildroot] RPC support for modern (e)glibc toolchains

[Thomas Petazzoni]

Hello,

Le Wed, 27 Jun 2012 08:00:40 -0300,
Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :

> > So I've created a package for libtirpc, which after a few fixes, 
> > seems
> > to work fine. But now, the hard part is how to handle this new 
> > package
> > in terms of dependencies, and this is where I'd like to have your
> > opinion.
> 
> How big is libtirpc in the target? Curiosity :)

127 KB when compiled against glibc, 99 KB when compiled against uClibc.
Not sure why there's a size difference here, maybe it's related to
other things (different compiler version, etc.). But roughly, we're
talking about 100 KB stripped.

> > I have essentially two problems:
> >
> >  *) Should we consider libtirpc just an add-on for (e)glibc, and
> >     therefore make it visible/available/used only when a (e)glibc
> >     toolchain lacking RPC support is used, or instead, should we 
> > offer
> >     libtirpc as soon as the toolchain lacks RPC support (which would
> >     also be the case for uClibc toolchain with no RPC support from 
> > the
> >     C library) ?
> 
> I'd say while we're working at it we could do it for uClibc as well 
> since it provides benefits which (probably) also apply to uClibc's
> RPC.

Ok, so we want to allow cases like "uClibc without RPC + libtirpc". I
also agree that it's a good idea.

> >  *) Should we make the dependency from packages on libtirpc a
> >     "select", like all other library dependencies, or a "depends
> > on", to
> >     mimic what we currently do for RPC support (packages "depends on
> >     BR2_INET_RPC", and they show a comment if BR2_INET_RPC isn't
> >     available) ?
> 
> Probably keep it as a "depends on", in some cases you'll already have 
> the toolchain providing RPC.
> Maybe even block libtirpc if the origin toolchain has RPC support? Or 
> can they be used at the same time? (Not that anyone would want too i 
> think...)

Yes, as I was mentionning in my initial e-mail, I was thinking of
having something like:

config BR2_RPC_AVAILABLE
	bool

config BR2_TOOLCHAIN_HAS_NATIVE_RPC
	select BR2_RPC_AVAILABLE
	bool


Toolchains having native RPC support (i.e uClibc with RPC support, or
glibc < 2.14) would select BR2_TOOLCHAIN_HAS_NATIVE_RPC Then, the
libtirpc package would:

config BR2_PACKAGE_LIBTIRPC
	bool "libtirpc"
	depends on !BR2_TOOLCHAIN_HAS_NATIVE_RPC
	select BR2_RPC_AVAILABLE
	select

But now, the question is for packages that need RPC support. We have
two choices. First, like today, the user has to manually enable RPC
support in the toolchain *OR* manually enable libtirpc.

config BR2_PACKAGE_FOO
	depends on BR2_RPC_AVAILABLE

comment "foo needs RPC support, either in toolchain or through libtirpc"
	depends on !BR2_RPC_AVAILABLE

Or, we can automatically select libtirpc if needed:

config BR2_PACKAGE_FOO
	select BR2_PACKAGE_LIBTIRPC if !BR2_TOOLCHAIN_HAS_NATIVE_RPC

and no comment is needed, because if the toolchain has no RPC support,
it would automatically be handled by libtirpc.

Which one do you prefer?

> >  *) How to handle the case of the Crosstool-NG backend? With the
> >     current Crosstool-NG backend, we have no idea which version of
> >     (e)glibc is being built, so we have no idea whether RPC support
> >     will be provided by the toolchain. Should we add a config option
> >     saying "My toolchain will have RPC support", which we will then
> >     check after the toolchain build, like we do with external
> >     toolchains? Other suggestions?
> 
> BR2_TOOLCHAIN_I_WANT_RPC ?
> After the toolchain is done we do an RPC check with readelf, if it's 
> not there we build libtirpc, otherwise we leave it be.

Hardly doable: we need to know at menuconfig time if we need libtirpc
in order to keep the .config selection consistent. If you don't, things
like "make source" or "make external-deps" will not work any more (they
will not know that libtirpc is needed).

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] RPC support for modern (e)glibc toolchains

[Gustavo Zacarias]

On 06/27/12 09:53, Thomas Petazzoni wrote:

>>>  *) Should we make the dependency from packages on libtirpc a
>>>     "select", like all other library dependencies, or a "depends
>>> on", to
>>>     mimic what we currently do for RPC support (packages "depends on
>>>     BR2_INET_RPC", and they show a comment if BR2_INET_RPC isn't
>>>     available) ?
>>
>> Probably keep it as a "depends on", in some cases you'll already have 
>> the toolchain providing RPC.
>> Maybe even block libtirpc if the origin toolchain has RPC support? Or 
>> can they be used at the same time? (Not that anyone would want too i 
>> think...)
> 
> Yes, as I was mentionning in my initial e-mail, I was thinking of
> having something like:
> 
> config BR2_RPC_AVAILABLE
> 	bool
> 
> config BR2_TOOLCHAIN_HAS_NATIVE_RPC
> 	select BR2_RPC_AVAILABLE
> 	bool
> 
> 
> Toolchains having native RPC support (i.e uClibc with RPC support, or
> glibc < 2.14) would select BR2_TOOLCHAIN_HAS_NATIVE_RPC Then, the
> libtirpc package would:
> 
> config BR2_PACKAGE_LIBTIRPC
> 	bool "libtirpc"
> 	depends on !BR2_TOOLCHAIN_HAS_NATIVE_RPC
> 	select BR2_RPC_AVAILABLE
> 	select
> 
> But now, the question is for packages that need RPC support. We have
> two choices. First, like today, the user has to manually enable RPC
> support in the toolchain *OR* manually enable libtirpc.
> 
> config BR2_PACKAGE_FOO
> 	depends on BR2_RPC_AVAILABLE
> 
> comment "foo needs RPC support, either in toolchain or through libtirpc"
> 	depends on !BR2_RPC_AVAILABLE
> 
> Or, we can automatically select libtirpc if needed:
> 
> config BR2_PACKAGE_FOO
> 	select BR2_PACKAGE_LIBTIRPC if !BR2_TOOLCHAIN_HAS_NATIVE_RPC
> 
> and no comment is needed, because if the toolchain has no RPC support,
> it would automatically be handled by libtirpc.
> 
> Which one do you prefer?

I prefer the last option, otherwise users will have RPC options all
around instead of one place (toolchain vs. packages).

>>>  *) How to handle the case of the Crosstool-NG backend? With the
>>>     current Crosstool-NG backend, we have no idea which version of
>>>     (e)glibc is being built, so we have no idea whether RPC support
>>>     will be provided by the toolchain. Should we add a config option
>>>     saying "My toolchain will have RPC support", which we will then
>>>     check after the toolchain build, like we do with external
>>>     toolchains? Other suggestions?
>>
>> BR2_TOOLCHAIN_I_WANT_RPC ?
>> After the toolchain is done we do an RPC check with readelf, if it's 
>> not there we build libtirpc, otherwise we leave it be.
> 
> Hardly doable: we need to know at menuconfig time if we need libtirpc
> in order to keep the .config selection consistent. If you don't, things
> like "make source" or "make external-deps" will not work any more (they
> will not know that libtirpc is needed).

True.
From what i've seen it seems libtirpc can be built/used with a
rpc-enabled libc.
We just need a few package tweaks around.
nfs-utils has a configure option to use it (--enable-tirpc) so it's easy.
portmap has not, though rpcbind (new package) should be used with
libtirpc, so portmap is libc-rpc or rpcbind if libtirpc but not both.
Others remain to be seen.
Regards.

[Buildroot] RPC support for modern (e)glibc toolchains

[Thomas Petazzoni]

Hello,

Le Thu, 28 Jun 2012 08:51:27 -0300,
Gustavo Zacarias <gustavo@zacarias.com.ar> a ?crit :

> > Yes, as I was mentionning in my initial e-mail, I was thinking of
> > having something like:
> > 
> > config BR2_RPC_AVAILABLE
> > 	bool
> > 
> > config BR2_TOOLCHAIN_HAS_NATIVE_RPC
> > 	select BR2_RPC_AVAILABLE
> > 	bool
> > 
> > 
> > Toolchains having native RPC support (i.e uClibc with RPC support, or
> > glibc < 2.14) would select BR2_TOOLCHAIN_HAS_NATIVE_RPC Then, the
> > libtirpc package would:
> > 
> > config BR2_PACKAGE_LIBTIRPC
> > 	bool "libtirpc"
> > 	depends on !BR2_TOOLCHAIN_HAS_NATIVE_RPC
> > 	select BR2_RPC_AVAILABLE
> > 	select
> > 
> > But now, the question is for packages that need RPC support. We have
> > two choices. First, like today, the user has to manually enable RPC
> > support in the toolchain *OR* manually enable libtirpc.
> > 
> > config BR2_PACKAGE_FOO
> > 	depends on BR2_RPC_AVAILABLE
> > 
> > comment "foo needs RPC support, either in toolchain or through libtirpc"
> > 	depends on !BR2_RPC_AVAILABLE
> > 
> > Or, we can automatically select libtirpc if needed:
> > 
> > config BR2_PACKAGE_FOO
> > 	select BR2_PACKAGE_LIBTIRPC if !BR2_TOOLCHAIN_HAS_NATIVE_RPC
> > 
> > and no comment is needed, because if the toolchain has no RPC support,
> > it would automatically be handled by libtirpc.
> > 
> > Which one do you prefer?
> 
> I prefer the last option, otherwise users will have RPC options all
> around instead of one place (toolchain vs. packages).

Hm? Not sure to understand what you mean here.

Regardless of whether my option (1) or my option (2) is chosen, the
number of options will be the same. It is just that:

 With option (1), if the toolchain does not have native RPC support,
 then all packages that need RPC support will immediately be visible,
 and will automatically select the libtirpc package. So it's fully
 transparent for users.

 With option (2), if the toolchain does not have native RPC support,
 then all packages that need RPC support will be hidden, and the user
 will have to enable the libtirpc package to see them.

So really, even with option (1) there is no such thing as "RPC options
all around instead of one place".

Note: by this, I am not implying that I have a preference for option
(1), I am just explaining a bit more, because it seems we're not
seeing the same thing :)

> >> BR2_TOOLCHAIN_I_WANT_RPC ?
> >> After the toolchain is done we do an RPC check with readelf, if it's 
> >> not there we build libtirpc, otherwise we leave it be.
> > 
> > Hardly doable: we need to know at menuconfig time if we need libtirpc
> > in order to keep the .config selection consistent. If you don't, things
> > like "make source" or "make external-deps" will not work any more (they
> > will not know that libtirpc is needed).
> 
> True.
> From what i've seen it seems libtirpc can be built/used with a
> rpc-enabled libc.
> We just need a few package tweaks around.
> nfs-utils has a configure option to use it (--enable-tirpc) so it's easy.
> portmap has not, though rpcbind (new package) should be used with
> libtirpc, so portmap is libc-rpc or rpcbind if libtirpc but not both.

Do we want to support that? I guess what you meant is that regardless
of whether the toolchain has RPC support we can always enable
libtirpc, so that in the ct-ng backend case we don't have to worry
about this?

Ultimately, this is what will probably happen: RPC support will no
longer be seen as a toolchain capability, but just as a normal library.
But we're not there yet.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] RPC support for modern (e)glibc toolchains

[Gustavo Zacarias]

On 06/28/12 08:57, Thomas Petazzoni wrote:

> Hm? Not sure to understand what you mean here.
> 
> Regardless of whether my option (1) or my option (2) is chosen, the
> number of options will be the same. It is just that:
> 
>  With option (1), if the toolchain does not have native RPC support,
>  then all packages that need RPC support will immediately be visible,
>  and will automatically select the libtirpc package. So it's fully
>  transparent for users.
> 
>  With option (2), if the toolchain does not have native RPC support,
>  then all packages that need RPC support will be hidden, and the user
>  will have to enable the libtirpc package to see them.
> 
> So really, even with option (1) there is no such thing as "RPC options
> all around instead of one place".
> 
> Note: by this, I am not implying that I have a preference for option
> (1), I am just explaining a bit more, because it seems we're not
> seeing the same thing :)

Or i'm still pretty much tired this week still recovering from a severe
cold :)
The first option gives the alternate choice in packages (selecting
libtirpc) hence why i'm not a big fan.
I'd rather keep the solution in the toolchain options for now since
libtirpc is the only available option AFAIK when (e)glibc lacks RPC so
no need to handle it at the moment.

> Do we want to support that? I guess what you meant is that regardless
> of whether the toolchain has RPC support we can always enable
> libtirpc, so that in the ct-ng backend case we don't have to worry
> about this?
> 
> Ultimately, this is what will probably happen: RPC support will no
> longer be seen as a toolchain capability, but just as a normal library.
> But we're not there yet.

Yes that's the idea, but maybe in the future as you say.
AFAIK the "big" benefit of libtirpc for nfs-utils is enabling NFSv4+
support, which needs rpcbind (new) and libnfsidmap (new).
Other than some NAS project i'd say "any RPC" is enough.
Regards.

[Buildroot] RPC support for modern (e)glibc toolchains

[Arnout Vandecappelle]

On 06/27/12 14:53, Thomas Petazzoni wrote:
> Hello,
>
> Le Wed, 27 Jun 2012 08:00:40 -0300,
> Gustavo Zacarias<gustavo@zacarias.com.ar>  a ?crit :
>
[snip]
>>>   *) Should we make the dependency from packages on libtirpc a
>>>      "select", like all other library dependencies, or a "depends on", to
>>>      mimic what we currently do for RPC support (packages "depends on
>>>      BR2_INET_RPC", and they show a comment if BR2_INET_RPC isn't
>>>      available) ?
>>
>> Probably keep it as a "depends on", in some cases you'll already have
>> the toolchain providing RPC.
>> Maybe even block libtirpc if the origin toolchain has RPC support? Or
>> can they be used at the same time? (Not that anyone would want too i
>> think...)
>
> Yes, as I was mentionning in my initial e-mail, I was thinking of
> having something like:
>
> config BR2_RPC_AVAILABLE
> 	bool
>
> config BR2_TOOLCHAIN_HAS_NATIVE_RPC
> 	select BR2_RPC_AVAILABLE
> 	bool
>
>
> Toolchains having native RPC support (i.e uClibc with RPC support, or
> glibc<  2.14) would select BR2_TOOLCHAIN_HAS_NATIVE_RPC Then, the
> libtirpc package would:
>
> config BR2_PACKAGE_LIBTIRPC
> 	bool "libtirpc"
> 	depends on !BR2_TOOLCHAIN_HAS_NATIVE_RPC
> 	select BR2_RPC_AVAILABLE
> 	select

  This seems overly complex to me.

>
> But now, the question is for packages that need RPC support. We have
> two choices. First, like today, the user has to manually enable RPC
> support in the toolchain *OR* manually enable libtirpc.
>
> config BR2_PACKAGE_FOO
> 	depends on BR2_RPC_AVAILABLE
>
> comment "foo needs RPC support, either in toolchain or through libtirpc"
> 	depends on !BR2_RPC_AVAILABLE
>
> Or, we can automatically select libtirpc if needed:
>
> config BR2_PACKAGE_FOO
> 	select BR2_PACKAGE_LIBTIRPC if !BR2_TOOLCHAIN_HAS_NATIVE_RPC
>
> and no comment is needed, because if the toolchain has no RPC support,
> it would automatically be handled by libtirpc.

  This one is much simpler: just one additional symbol, and it's all
hidden from the user except in the case of an unknown external
toolchain or a crosstool-NG toolchain.


  However, given that this will only appear in BR-2012.08 at the earliest,
and that the native RPC is on the way out anyway, maybe we can keep it
even simpler and remove the BR2_TOOLCHAIN_HAS_NATIVE_RPC option
completely.  Just replace all 'depends on BR2_INET_RPC' with
'select BR2_PACKAGE_LIBTIRPC'.  The only users who are aversely affected
by that are people using a pre-2.14 glibc toolchain, because now they'll
get 100K of redundant library.  But I guess glibc users don't care much
about a mere 100K of rootfs size.

  Of course, this would require testing that all the RPC users actually
work with tirpc.  Or is it sufficient that we build-test it and assume
upstream will take care of making it work?

  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] RPC support for modern (e)glibc toolchains

[Thomas Petazzoni]

Le Sat, 30 Jun 2012 14:24:51 +0200,
Arnout Vandecappelle <arnout@mind.be> a ?crit :

>   However, given that this will only appear in BR-2012.08 at the earliest,
> and that the native RPC is on the way out anyway, maybe we can keep it
> even simpler and remove the BR2_TOOLCHAIN_HAS_NATIVE_RPC option
> completely.  Just replace all 'depends on BR2_INET_RPC' with
> 'select BR2_PACKAGE_LIBTIRPC'.  The only users who are aversely affected
> by that are people using a pre-2.14 glibc toolchain, because now they'll
> get 100K of redundant library.  But I guess glibc users don't care much
> about a mere 100K of rootfs size.

Replacing "depends on BR2_INET_RPC" by "select BR2_PACKAGE_LIBTIRPC"
means that uClibc users will be forced to use libtirpc, while they
probably wanted to keep using the internal uClibc RPC code. I don't
think it's a good idea to do this.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] RPC support for modern (e)glibc toolchains

[Arnout Vandecappelle]

On 07/03/12 21:48, Thomas Petazzoni wrote:
> Le Sat, 30 Jun 2012 14:24:51 +0200,
> Arnout Vandecappelle<arnout@mind.be>  a ?crit :
>
>>    However, given that this will only appear in BR-2012.08 at the earliest,
>> and that the native RPC is on the way out anyway, maybe we can keep it
>> even simpler and remove the BR2_TOOLCHAIN_HAS_NATIVE_RPC option
>> completely.  Just replace all 'depends on BR2_INET_RPC' with
>> 'select BR2_PACKAGE_LIBTIRPC'.  The only users who are aversely affected
>> by that are people using a pre-2.14 glibc toolchain, because now they'll
>> get 100K of redundant library.  But I guess glibc users don't care much
>> about a mere 100K of rootfs size.
>
> Replacing "depends on BR2_INET_RPC" by "select BR2_PACKAGE_LIBTIRPC"
> means that uClibc users will be forced to use libtirpc, while they
> probably wanted to keep using the internal uClibc RPC code. I don't
> think it's a good idea to do this.

  My bad, I didn't know uClibc had native RPC code.

  Then I would go for option (2) from your original mail.  Or the following
variation:

config BR2_RPC
	bool
	select BR2_PACKAGE_LIBTIRPC if !BR2_TOOLCHAIN_HAS_NATIVE_RPC

config BR2_TOOLCHAIN_HAS_NATIVE_RPC
	bool

config BR2_PACKAGE_FOO
	select BR2_RPC

  We probably also want an rpc target for the .mk files:

FOO_DEPENDENCIES += rpc

# (in some toolchain .mk file)
.PHONY: rpc

# (in libtirpc .mk file)
ifeq ($(BR2_PACKAGE_LIBTIRPC),y)
rpc: libtirpc
endif

  Actually, I'm not 100% sure if this scheme is a good idea because it adds
the phony rpc target to TARGETS.


  Oh and I would also not exclude libtirpc if the toolchain has native RPC,
unless there really is a conflict.  I can imagine that it makes sense to
want the extra features of libtirpc even with a 2.13 glibc.


  Regards,
  Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F