Patchwork libc/eglibc: add an option to enable obsolete RPC building

login
register
mail settings
Submitter Florian Fainelli
Date Oct. 17, 2012, 11:43 a.m.
Message ID <3359545.UbcoClgYkd@flexo>
Download mbox | patch
Permalink /patch/192022/
State Changes Requested
Headers show

Comments

Florian Fainelli - Oct. 17, 2012, 11:43 a.m.
# HG changeset patch
# User Florian Fainelli <f.fainelli@gmail.com>
# Date 1349256753 -7200
# Node ID 7f6ddb2b0ca0d89fa5bc98c1deb55d840b505ccd
# Parent  43ace4bb005eef085437e3d4fbaef528ef0ef005
[PATCH] libc/eglibc: add an option to enable obsolete RPC building

Add an option to enable eglibc's feature to build the obsolete RPC
implementation, which is selected by default when eglibc 2.16 is selected.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

exporting patch:
<fdopen>


--
For unsubscribe information see http://sourceware.org/lists.html#faq
Bryan Hundven - Oct. 17, 2012, 12:06 p.m.
On Wed, Oct 17, 2012 at 4:43 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> # HG changeset patch
> # User Florian Fainelli <f.fainelli@gmail.com>
> # Date 1349256753 -7200
> # Node ID 7f6ddb2b0ca0d89fa5bc98c1deb55d840b505ccd
> # Parent  43ace4bb005eef085437e3d4fbaef528ef0ef005
> [PATCH] libc/eglibc: add an option to enable obsolete RPC building
>
> Add an option to enable eglibc's feature to build the obsolete RPC
> implementation, which is selected by default when eglibc 2.16 is selected.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>
> diff --git a/config/libc/eglibc.in b/config/libc/eglibc.in
> --- a/config/libc/eglibc.in
> +++ b/config/libc/eglibc.in
> @@ -197,6 +197,15 @@
>        Optimize eglibc for size using -Os instead of -O2. This will make eglibc
>        smaller but may make it slower.
>
> +config EGLIBC_ENABLE_OBSOLETE_RPC
> +    bool
> +    prompt "Enable obsolete RPC"
> +    default y if LIBC_EGLIBC_V_2_16
> +    help
> +      Enable the building of the pre eglibc 2.14 RPC implementation.
> +      This option may be required if you are not building libtirpc for
> +      your system.
> +
>  config EGLIBC_CUSTOM_CONFIG
>      bool
>      prompt "Use custom configuration file"
> diff --git a/scripts/build/libc/glibc-eglibc.sh-common b/scripts/build/libc/glibc-eglibc.sh-common
> --- a/scripts/build/libc/glibc-eglibc.sh-common
> +++ b/scripts/build/libc/glibc-eglibc.sh-common
> @@ -214,6 +214,9 @@
>              else
>                  OPTIMIZE=-O2
>              fi
> +            if [ "${CT_EGLIBC_ENABLE_OBSOLETE_RPC}" = "y" ]; then
> +                extra_config+=( --enable-obsolete-rpc )
> +            fi
>              ;;
>          glibc)
>              # glibc can't be built without -O2 (reference needed!)
> exporting patch:
> <fdopen>
>
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>

Florian,

Wouldn't this affect glibc-2.16 as well? In that case, it maybe better
to put this in glibc-eglibc.sh-common, so when glibc-2.16 is added to
ct-ng, it will just work (famous last words).

-Bryan

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - Oct. 17, 2012, 12:31 p.m.
Florian, Bryan, All,

On Wednesday 17 October 2012 14:06:43 Bryan Hundven wrote:
> On Wed, Oct 17, 2012 at 4:43 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> > # HG changeset patch
> > # User Florian Fainelli <f.fainelli@gmail.com>
> > # Date 1349256753 -7200
> > # Node ID 7f6ddb2b0ca0d89fa5bc98c1deb55d840b505ccd
> > # Parent  43ace4bb005eef085437e3d4fbaef528ef0ef005
> > [PATCH] libc/eglibc: add an option to enable obsolete RPC building

Florian, OK, looks good :-) I will look at it tonight when back home.
Thank you!

> Wouldn't this affect glibc-2.16 as well? In that case, it maybe better
> to put this in glibc-eglibc.sh-common, so when glibc-2.16 is added to
> ct-ng, it will just work (famous last words).

Bryan, the code is already in glibc-eglibc-common, only the option is
specific to eglibc.

We do not have glibc-2.16 yet in ct-ng. When/if someone pushes a patch to
add glibc-2.16, _then_ we can think of a way to move the option to the
common area.

Regards,
Yann E. MORIN.
Florian Fainelli - Oct. 17, 2012, 12:35 p.m.
Hi Yann,

On Wednesday 17 October 2012 14:31:28 Yann E. MORIN wrote:
> Florian, Bryan, All,
> 
> On Wednesday 17 October 2012 14:06:43 Bryan Hundven wrote:
> > On Wed, Oct 17, 2012 at 4:43 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> > > # HG changeset patch
> > > # User Florian Fainelli <f.fainelli@gmail.com>
> > > # Date 1349256753 -7200
> > > # Node ID 7f6ddb2b0ca0d89fa5bc98c1deb55d840b505ccd
> > > # Parent  43ace4bb005eef085437e3d4fbaef528ef0ef005
> > > [PATCH] libc/eglibc: add an option to enable obsolete RPC building
> 
> Florian, OK, looks good :-) I will look at it tonight when back home.
> Thank you!
> 
> > Wouldn't this affect glibc-2.16 as well? In that case, it maybe better
> > to put this in glibc-eglibc.sh-common, so when glibc-2.16 is added to
> > ct-ng, it will just work (famous last words).
> 
> Bryan, the code is already in glibc-eglibc-common, only the option is
> specific to eglibc.
> 
> We do not have glibc-2.16 yet in ct-ng. When/if someone pushes a patch to
> add glibc-2.16, _then_ we can think of a way to move the option to the
> common area.

Bryan's concern looks valid to me, so if you want me to respin with this 
addressed, I really do not mind.
--
Florian

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - Oct. 17, 2012, 1:05 p.m.
Florian, Bryan, All,

On Wednesday 17 October 2012 14:35:21 Florian Fainelli wrote:
> On Wednesday 17 October 2012 14:31:28 Yann E. MORIN wrote:
> > Florian, Bryan, All,
> > 
> > On Wednesday 17 October 2012 14:06:43 Bryan Hundven wrote:
> > > On Wed, Oct 17, 2012 at 4:43 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> > > > # HG changeset patch
> > > > # User Florian Fainelli <f.fainelli@gmail.com>
> > > > # Date 1349256753 -7200
> > > > # Node ID 7f6ddb2b0ca0d89fa5bc98c1deb55d840b505ccd
> > > > # Parent  43ace4bb005eef085437e3d4fbaef528ef0ef005
> > > > [PATCH] libc/eglibc: add an option to enable obsolete RPC building
> > 
> > Florian, OK, looks good :-) I will look at it tonight when back home.
> > Thank you!
> > 
> > > Wouldn't this affect glibc-2.16 as well? In that case, it maybe better
> > > to put this in glibc-eglibc.sh-common, so when glibc-2.16 is added to
> > > ct-ng, it will just work (famous last words).
> > 
> > Bryan, the code is already in glibc-eglibc-common, only the option is
> > specific to eglibc.
> > 
> > We do not have glibc-2.16 yet in ct-ng. When/if someone pushes a patch to
> > add glibc-2.16, _then_ we can think of a way to move the option to the
> > common area.
> 
> Bryan's concern looks valid to me, so if you want me to respin with this 
> addressed, I really do not mind.

In that case, please add:
    config LIBC_GLIBC_HAS_OBSOLETE_SUNRPC
        bool

    config LIBC_GLIBC_ENABLE_OBSOLETE_SUNRPC
        bool
        prompt "Enable obsoloete sunrpc"
        depends on LIBC_GLIBC_HAS_OBSOLETE_SUNRPC

Then (e)glibc versions that have support for obsoloete sunrpc can 'select'
the LIBC_GLIBC_HAS_OBSOLETE_SUNRPC symbol, and the option becomes visible.

While you are at it, could you spin a patch that basically adds:
    config LIBC_GLIBC_MISSES_SUNRPC
        bool

    comment "This version of (e)glibc does *not* have sunrpc"
        depends on LIBC_GLIBC_MISSES_SUNRPC

Then (e)glibc (both 2.14 and 2.15, IIRC) versions that do not have sunrpc at
all can select the LIBC_GLIBC_MISSES_SUNRPC symbol, and the warning becomes
visible.

Regards,
Yann E. MORIN.
Bryan Hundven - Oct. 17, 2012, 1:07 p.m.
On Wed, Oct 17, 2012 at 6:05 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Florian, Bryan, All,
>
> On Wednesday 17 October 2012 14:35:21 Florian Fainelli wrote:
>> On Wednesday 17 October 2012 14:31:28 Yann E. MORIN wrote:
>> > Florian, Bryan, All,
>> >
>> > On Wednesday 17 October 2012 14:06:43 Bryan Hundven wrote:
>> > > On Wed, Oct 17, 2012 at 4:43 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> > > > # HG changeset patch
>> > > > # User Florian Fainelli <f.fainelli@gmail.com>
>> > > > # Date 1349256753 -7200
>> > > > # Node ID 7f6ddb2b0ca0d89fa5bc98c1deb55d840b505ccd
>> > > > # Parent  43ace4bb005eef085437e3d4fbaef528ef0ef005
>> > > > [PATCH] libc/eglibc: add an option to enable obsolete RPC building
>> >
>> > Florian, OK, looks good :-) I will look at it tonight when back home.
>> > Thank you!
>> >
>> > > Wouldn't this affect glibc-2.16 as well? In that case, it maybe better
>> > > to put this in glibc-eglibc.sh-common, so when glibc-2.16 is added to
>> > > ct-ng, it will just work (famous last words).
>> >
>> > Bryan, the code is already in glibc-eglibc-common, only the option is
>> > specific to eglibc.
>> >
>> > We do not have glibc-2.16 yet in ct-ng. When/if someone pushes a patch to
>> > add glibc-2.16, _then_ we can think of a way to move the option to the
>> > common area.
>>
>> Bryan's concern looks valid to me, so if you want me to respin with this
>> addressed, I really do not mind.
>
> In that case, please add:
>     config LIBC_GLIBC_HAS_OBSOLETE_SUNRPC
>         bool
>
>     config LIBC_GLIBC_ENABLE_OBSOLETE_SUNRPC
>         bool
>         prompt "Enable obsoloete sunrpc"
>         depends on LIBC_GLIBC_HAS_OBSOLETE_SUNRPC
>
> Then (e)glibc versions that have support for obsoloete sunrpc can 'select'
> the LIBC_GLIBC_HAS_OBSOLETE_SUNRPC symbol, and the option becomes visible.
>
> While you are at it, could you spin a patch that basically adds:
>     config LIBC_GLIBC_MISSES_SUNRPC
>         bool
>
>     comment "This version of (e)glibc does *not* have sunrpc"
>         depends on LIBC_GLIBC_MISSES_SUNRPC
>
> Then (e)glibc (both 2.14 and 2.15, IIRC) versions that do not have sunrpc at
> all can select the LIBC_GLIBC_MISSES_SUNRPC symbol, and the warning becomes
> visible.

It should just be 2.15 and 2.16+

> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
> | --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
> | http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
> '------------------------------'-------'------------------'--------------------'

-Bryan

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Bryan Hundven - Oct. 17, 2012, 1:25 p.m.
On Wed, Oct 17, 2012 at 6:07 AM, Bryan Hundven <bryanhundven@gmail.com> wrote:
> On Wed, Oct 17, 2012 at 6:05 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>> Florian, Bryan, All,
>>
>> On Wednesday 17 October 2012 14:35:21 Florian Fainelli wrote:
>>> On Wednesday 17 October 2012 14:31:28 Yann E. MORIN wrote:
>>> > Florian, Bryan, All,
>>> >
>>> > On Wednesday 17 October 2012 14:06:43 Bryan Hundven wrote:
>>> > > On Wed, Oct 17, 2012 at 4:43 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>> > > > # HG changeset patch
>>> > > > # User Florian Fainelli <f.fainelli@gmail.com>
>>> > > > # Date 1349256753 -7200
>>> > > > # Node ID 7f6ddb2b0ca0d89fa5bc98c1deb55d840b505ccd
>>> > > > # Parent  43ace4bb005eef085437e3d4fbaef528ef0ef005
>>> > > > [PATCH] libc/eglibc: add an option to enable obsolete RPC building
>>> >
>>> > Florian, OK, looks good :-) I will look at it tonight when back home.
>>> > Thank you!
>>> >
>>> > > Wouldn't this affect glibc-2.16 as well? In that case, it maybe better
>>> > > to put this in glibc-eglibc.sh-common, so when glibc-2.16 is added to
>>> > > ct-ng, it will just work (famous last words).
>>> >
>>> > Bryan, the code is already in glibc-eglibc-common, only the option is
>>> > specific to eglibc.
>>> >
>>> > We do not have glibc-2.16 yet in ct-ng. When/if someone pushes a patch to
>>> > add glibc-2.16, _then_ we can think of a way to move the option to the
>>> > common area.
>>>
>>> Bryan's concern looks valid to me, so if you want me to respin with this
>>> addressed, I really do not mind.
>>
>> In that case, please add:
>>     config LIBC_GLIBC_HAS_OBSOLETE_SUNRPC
>>         bool
>>
>>     config LIBC_GLIBC_ENABLE_OBSOLETE_SUNRPC
>>         bool
>>         prompt "Enable obsoloete sunrpc"
>>         depends on LIBC_GLIBC_HAS_OBSOLETE_SUNRPC
>>
>> Then (e)glibc versions that have support for obsoloete sunrpc can 'select'
>> the LIBC_GLIBC_HAS_OBSOLETE_SUNRPC symbol, and the option becomes visible.
>>
>> While you are at it, could you spin a patch that basically adds:
>>     config LIBC_GLIBC_MISSES_SUNRPC
>>         bool
>>
>>     comment "This version of (e)glibc does *not* have sunrpc"
>>         depends on LIBC_GLIBC_MISSES_SUNRPC
>>
>> Then (e)glibc (both 2.14 and 2.15, IIRC) versions that do not have sunrpc at
>> all can select the LIBC_GLIBC_MISSES_SUNRPC symbol, and the warning becomes
>> visible.
>
> It should just be 2.15 and 2.16+

I digress, 2.14+

>> Regards,
>> Yann E. MORIN.
>>
>> --
>> .-----------------.--------------------.------------------.--------------------.
>> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
>> | +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
>> | --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
>> | http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
>> '------------------------------'-------'------------------'--------------------'
>
> -Bryan

-Bryan

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Benoît Thébaudeau - Oct. 17, 2012, 1:28 p.m.
Hi Bryan, all,

On Wednesday, October 17, 2012 3:07:44 PM, Bryan Hundven wrote:
> On Wed, Oct 17, 2012 at 6:05 AM, Yann E. MORIN
> <yann.morin.1998@free.fr> wrote:
> > Florian, Bryan, All,
> >
> > On Wednesday 17 October 2012 14:35:21 Florian Fainelli wrote:
> >> On Wednesday 17 October 2012 14:31:28 Yann E. MORIN wrote:
> >> > Florian, Bryan, All,
> >> >
> >> > On Wednesday 17 October 2012 14:06:43 Bryan Hundven wrote:
> >> > > On Wed, Oct 17, 2012 at 4:43 AM, Florian Fainelli
> >> > > <f.fainelli@gmail.com> wrote:
> >> > > > # HG changeset patch
> >> > > > # User Florian Fainelli <f.fainelli@gmail.com>
> >> > > > # Date 1349256753 -7200
> >> > > > # Node ID 7f6ddb2b0ca0d89fa5bc98c1deb55d840b505ccd
> >> > > > # Parent  43ace4bb005eef085437e3d4fbaef528ef0ef005
> >> > > > [PATCH] libc/eglibc: add an option to enable obsolete RPC
> >> > > > building
> >> >
> >> > Florian, OK, looks good :-) I will look at it tonight when back
> >> > home.
> >> > Thank you!
> >> >
> >> > > Wouldn't this affect glibc-2.16 as well? In that case, it
> >> > > maybe better
> >> > > to put this in glibc-eglibc.sh-common, so when glibc-2.16 is
> >> > > added to
> >> > > ct-ng, it will just work (famous last words).
> >> >
> >> > Bryan, the code is already in glibc-eglibc-common, only the
> >> > option is
> >> > specific to eglibc.
> >> >
> >> > We do not have glibc-2.16 yet in ct-ng. When/if someone pushes a
> >> > patch to
> >> > add glibc-2.16, _then_ we can think of a way to move the option
> >> > to the
> >> > common area.
> >>
> >> Bryan's concern looks valid to me, so if you want me to respin
> >> with this
> >> addressed, I really do not mind.
> >
> > In that case, please add:
> >     config LIBC_GLIBC_HAS_OBSOLETE_SUNRPC
> >         bool
> >
> >     config LIBC_GLIBC_ENABLE_OBSOLETE_SUNRPC
> >         bool
> >         prompt "Enable obsoloete sunrpc"
> >         depends on LIBC_GLIBC_HAS_OBSOLETE_SUNRPC
> >
> > Then (e)glibc versions that have support for obsoloete sunrpc can
> > 'select'
> > the LIBC_GLIBC_HAS_OBSOLETE_SUNRPC symbol, and the option becomes
> > visible.
> >
> > While you are at it, could you spin a patch that basically adds:
> >     config LIBC_GLIBC_MISSES_SUNRPC
> >         bool
> >
> >     comment "This version of (e)glibc does *not* have sunrpc"
> >         depends on LIBC_GLIBC_MISSES_SUNRPC
> >
> > Then (e)glibc (both 2.14 and 2.15, IIRC) versions that do not have
> > sunrpc at
> > all can select the LIBC_GLIBC_MISSES_SUNRPC symbol, and the warning
> > becomes
> > visible.
> 
> It should just be 2.15 and 2.16+

Yann is right:
 - 2.13 contains end enables RPC by default,
 - 2.14 and 2.15 do not contain RPC at all,
 - 2.16 contains RPC but enables it only with --enable-obsolete-rpc.

Best regards,
Benoît

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Bryan Hundven - Oct. 17, 2012, 1:31 p.m.
On Wed, Oct 17, 2012 at 6:28 AM, Benoît Thébaudeau
<benoit.thebaudeau@advansee.com> wrote:
> Hi Bryan, all,
>
> On Wednesday, October 17, 2012 3:07:44 PM, Bryan Hundven wrote:
>> On Wed, Oct 17, 2012 at 6:05 AM, Yann E. MORIN
>> <yann.morin.1998@free.fr> wrote:
>> > Florian, Bryan, All,
>> >
>> > On Wednesday 17 October 2012 14:35:21 Florian Fainelli wrote:
>> >> On Wednesday 17 October 2012 14:31:28 Yann E. MORIN wrote:
>> >> > Florian, Bryan, All,
>> >> >
>> >> > On Wednesday 17 October 2012 14:06:43 Bryan Hundven wrote:
>> >> > > On Wed, Oct 17, 2012 at 4:43 AM, Florian Fainelli
>> >> > > <f.fainelli@gmail.com> wrote:
>> >> > > > # HG changeset patch
>> >> > > > # User Florian Fainelli <f.fainelli@gmail.com>
>> >> > > > # Date 1349256753 -7200
>> >> > > > # Node ID 7f6ddb2b0ca0d89fa5bc98c1deb55d840b505ccd
>> >> > > > # Parent  43ace4bb005eef085437e3d4fbaef528ef0ef005
>> >> > > > [PATCH] libc/eglibc: add an option to enable obsolete RPC
>> >> > > > building
>> >> >
>> >> > Florian, OK, looks good :-) I will look at it tonight when back
>> >> > home.
>> >> > Thank you!
>> >> >
>> >> > > Wouldn't this affect glibc-2.16 as well? In that case, it
>> >> > > maybe better
>> >> > > to put this in glibc-eglibc.sh-common, so when glibc-2.16 is
>> >> > > added to
>> >> > > ct-ng, it will just work (famous last words).
>> >> >
>> >> > Bryan, the code is already in glibc-eglibc-common, only the
>> >> > option is
>> >> > specific to eglibc.
>> >> >
>> >> > We do not have glibc-2.16 yet in ct-ng. When/if someone pushes a
>> >> > patch to
>> >> > add glibc-2.16, _then_ we can think of a way to move the option
>> >> > to the
>> >> > common area.
>> >>
>> >> Bryan's concern looks valid to me, so if you want me to respin
>> >> with this
>> >> addressed, I really do not mind.
>> >
>> > In that case, please add:
>> >     config LIBC_GLIBC_HAS_OBSOLETE_SUNRPC
>> >         bool
>> >
>> >     config LIBC_GLIBC_ENABLE_OBSOLETE_SUNRPC
>> >         bool
>> >         prompt "Enable obsoloete sunrpc"
>> >         depends on LIBC_GLIBC_HAS_OBSOLETE_SUNRPC
>> >
>> > Then (e)glibc versions that have support for obsoloete sunrpc can
>> > 'select'
>> > the LIBC_GLIBC_HAS_OBSOLETE_SUNRPC symbol, and the option becomes
>> > visible.
>> >
>> > While you are at it, could you spin a patch that basically adds:
>> >     config LIBC_GLIBC_MISSES_SUNRPC
>> >         bool
>> >
>> >     comment "This version of (e)glibc does *not* have sunrpc"
>> >         depends on LIBC_GLIBC_MISSES_SUNRPC
>> >
>> > Then (e)glibc (both 2.14 and 2.15, IIRC) versions that do not have
>> > sunrpc at
>> > all can select the LIBC_GLIBC_MISSES_SUNRPC symbol, and the warning
>> > becomes
>> > visible.
>>
>> It should just be 2.15 and 2.16+
>
> Yann is right:
>  - 2.13 contains end enables RPC by default,
>  - 2.14 and 2.15 do not contain RPC at all,
>  - 2.16 contains RPC but enables it only with --enable-obsolete-rpc.
>
> Best regards,
> Benoît

Exactly,

Sorry for my error.

-Bryan

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Mike Frysinger - Oct. 17, 2012, 7:06 p.m.
On Wednesday 17 October 2012 09:28:07 Benoît Thébaudeau wrote:
>  - 2.14 and 2.15 do not contain RPC at all,

that's not true.  glibc has never dropped the runtime symbols (so old apps 
continue to work fine).  it did however drop the symbols which allow you to 
link new applications against the rpc code.
-mike
Yann E. MORIN - Oct. 17, 2012, 7:20 p.m.
Mike, All,

On Wednesday 17 October 2012 Mike Frysinger wrote:
> On Wednesday 17 October 2012 09:28:07 Benoît Thébaudeau wrote:
> >  - 2.14 and 2.15 do not contain RPC at all,
> 
> that's not true.  glibc has never dropped the runtime symbols (so old apps 
> continue to work fine).  it did however drop the symbols which allow you to 
> link new applications against the rpc code.

You are right. But for the sake of a cross-compilation toolchain that will
build and link user code to libs from the toolchain, the end effect for the
user of the toolchain is exactly as if RPC was not available in the tolchain
at all. We're taking a shortcut by saying "no RPC at all", but it fits quite
OK in the context of crosstool-NG.

Of course, pre-build applications will still be able to run, as the lib
with the rpc symbols is still available and installed.

Regards,
Yann E. MORIN.

Patch

diff --git a/config/libc/eglibc.in b/config/libc/eglibc.in
--- a/config/libc/eglibc.in
+++ b/config/libc/eglibc.in
@@ -197,6 +197,15 @@ 
       Optimize eglibc for size using -Os instead of -O2. This will make eglibc
       smaller but may make it slower.
 
+config EGLIBC_ENABLE_OBSOLETE_RPC
+    bool
+    prompt "Enable obsolete RPC"
+    default y if LIBC_EGLIBC_V_2_16
+    help
+      Enable the building of the pre eglibc 2.14 RPC implementation.
+      This option may be required if you are not building libtirpc for
+      your system.
+
 config EGLIBC_CUSTOM_CONFIG
     bool
     prompt "Use custom configuration file"
diff --git a/scripts/build/libc/glibc-eglibc.sh-common b/scripts/build/libc/glibc-eglibc.sh-common
--- a/scripts/build/libc/glibc-eglibc.sh-common
+++ b/scripts/build/libc/glibc-eglibc.sh-common
@@ -214,6 +214,9 @@ 
             else
                 OPTIMIZE=-O2
             fi
+            if [ "${CT_EGLIBC_ENABLE_OBSOLETE_RPC}" = "y" ]; then
+                extra_config+=( --enable-obsolete-rpc )
+            fi
             ;;
         glibc)
             # glibc can't be built without -O2 (reference needed!)