Disable building libgcc with -O0

Link error happens for valgrind when linking unoptimized libgcc.
Libgcc requires symbol _Unwind_Resume defined in libgcc_eh which
in turn requires pulling in entire glibc.  We can't make valgrind
link with glibc due to its design.  So don't build libgcc without
optimizations, so that calls to _Unwind_Resume get eliminated.

Signed-off-by: Lei Liu <lei.liu2@windriver.com>
---
 meta/recipes-devtools/gcc/gcc-cross.inc | 9 +++++++++
 1 file changed, 9 insertions(+)

--
1.8.2.1

Please fix up the comment to follow the guildlines on this patch and 
your other one.

http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

Sau!


On 11/10/2013 08:30 PM, Lei Liu wrote:
> Link error happens for valgrind when linking unoptimized libgcc.
> Libgcc requires symbol _Unwind_Resume defined in libgcc_eh which
> in turn requires pulling in entire glibc.  We can't make valgrind
> link with glibc due to its design.  So don't build libgcc without
> optimizations, so that calls to _Unwind_Resume get eliminated.
>
> Signed-off-by: Lei Liu <lei.liu2@windriver.com>
> ---
>   meta/recipes-devtools/gcc/gcc-cross.inc | 9 +++++++++
>   1 file changed, 9 insertions(+)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-cross.inc b/meta/recipes-devtools/gcc/gcc-cross.inc
> index 25a3142..cf03c08 100644
> --- a/meta/recipes-devtools/gcc/gcc-cross.inc
> +++ b/meta/recipes-devtools/gcc/gcc-cross.inc
> @@ -25,6 +25,15 @@ EXTRA_OECONF_PATHS = " \
>
>   ARCH_FLAGS_FOR_TARGET += "-isystem${STAGING_DIR_TARGET}${target_includedir}"
>
> +def get_optimization(d):
> +    selected_optimization = d.getVar("SELECTED_OPTIMIZATION", True)
> +    if base_contains("SELECTED_OPTIMIZATION", "-O0", "x", "", d) == "x":
> +        bb.note("libgcc can't be built with -O0, -O2 will be used instead.")
> +        return selected_optimization.replace("-O0", "-O2")
> +    return selected_optimization
> +
> +SELECTED_OPTIMIZATION := "${@get_optimization(d)}"
> +
>   do_configure_prepend () {
>   	sed -i 's/BUILD_INFO=info/BUILD_INFO=/' ${S}/gcc/configure
>   }
> --
> 1.8.2.1
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

On Mon, 2013-11-11 at 12:30 +0800, Lei Liu wrote:
> +def get_optimization(d):
> +    selected_optimization = d.getVar("SELECTED_OPTIMIZATION", True)
> +    if base_contains("SELECTED_OPTIMIZATION", "-O0", "x", "", d) == "x":
> +        bb.note("libgcc can't be built with -O0, -O2 will be used instead.")
> +        return selected_optimization.replace("-O0", "-O2")
> +    return selected_optimization
> +
> +SELECTED_OPTIMIZATION := "${@get_optimization(d)}"

Do we really need a Python function for this?  It seems like a rather
heavyweight mechanism to detect what is basically just a distro
misconfiguration.

How about just patching the appropriate bit of libgcc to include:

#if __OPTIMIZE__ == 0
#error libgcc can't be built with -O0, please fix your distro to use at least -O1
#endif

or some such?  Even this seems slightly dubious, since it will prevent
you from building an unoptimised libgcc even if you have no intention of
running valgrind with it, but at least this doesn't add extra overhead
within bitbake.

p.

On 2013?11?13? 07:58, Phil Blundell wrote:
> On Mon, 2013-11-11 at 12:30 +0800, Lei Liu wrote:
>> +def get_optimization(d):
>> +    selected_optimization = d.getVar("SELECTED_OPTIMIZATION", True)
>> +    if base_contains("SELECTED_OPTIMIZATION", "-O0", "x", "", d) == "x":
>> +        bb.note("libgcc can't be built with -O0, -O2 will be used instead.")
>> +        return selected_optimization.replace("-O0", "-O2")
>> +    return selected_optimization
>> +
>> +SELECTED_OPTIMIZATION := "${@get_optimization(d)}"
> Do we really need a Python function for this?  It seems like a rather
> heavyweight mechanism to detect what is basically just a distro
> misconfiguration.

The python function is copied from eglibc recipe which does similar
job to force build the package with optimization enabled.  I think
it's not just a distro misconfiguration.  Sometimes it would be
convenient for user to select a global -O0 optimization level (to
create a more debug-friendly rootfs) for most packages, while
automatically switching to -O2 for those which can't be built without
optimizations.

>
> How about just patching the appropriate bit of libgcc to include:
>
> #if __OPTIMIZE__ == 0
> #error libgcc can't be built with -O0, please fix your distro to use at least -O1
> #endif

I think it would be more helpful if we can switch to -O1 or -O2 in
such case, instead of throwing out an error.

Lei

>
> or some such?  Even this seems slightly dubious, since it will prevent
> you from building an unoptimised libgcc even if you have no intention of
> running valgrind with it, but at least this doesn't add extra overhead
> within bitbake.
>
> p.
>
>

On Wed, Nov 13, 2013 at 11:02:36AM +0800, Lei Liu wrote:
> On 2013?11?13? 07:58, Phil Blundell wrote:
> > On Mon, 2013-11-11 at 12:30 +0800, Lei Liu wrote:
> >> +def get_optimization(d):
> >> +    selected_optimization = d.getVar("SELECTED_OPTIMIZATION", True)
> >> +    if base_contains("SELECTED_OPTIMIZATION", "-O0", "x", "", d) == "x":
> >> +        bb.note("libgcc can't be built with -O0, -O2 will be used instead.")
> >> +        return selected_optimization.replace("-O0", "-O2")
> >> +    return selected_optimization
> >> +
> >> +SELECTED_OPTIMIZATION := "${@get_optimization(d)}"
> > Do we really need a Python function for this?  It seems like a rather
> > heavyweight mechanism to detect what is basically just a distro
> > misconfiguration.
> 
> The python function is copied from eglibc recipe which does similar
> job to force build the package with optimization enabled.  I think
> it's not just a distro misconfiguration.  Sometimes it would be
> convenient for user to select a global -O0 optimization level (to
> create a more debug-friendly rootfs) for most packages, while
> automatically switching to -O2 for those which can't be built without
> optimizations.

Sometimes, perhaps, but automatically switching seems to violate the 
principle of least surprise.  If I've set CFLAGS to "-O0" in my distro 
configuration then that's what I would expect the recipes to be using.  
I would not expect random recipes to start second-guessing me and 
selecting different CFLAGS.

If I wanted to build libgcc with -O but everything else with -O0 then 
that's easy enough to achieve:

SELECTED_OPTIMIZATION = "-O0"
SELECTED_OPTIMIZATION_libgcc = "-O"

or whatever.

p.