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

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

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