Message ID | 3359545.UbcoClgYkd@flexo |
---|---|
State | Changes Requested |
Headers | show |
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
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.
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
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.
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
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
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
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
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
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.
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!)
# 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