[poky] --with-gxx-include-dir and sysroot

[Richard Purdie]

On Fri, 2010-12-24 at 15:34 +0800, Tian, Kevin wrote:
> I got a confusion about the relationship between "--with-gxx-include-dir" and sysroot, 
> and consequently would like to discuss one issue it causes.
> 
> GCC installation manual is not very clear about how c++ header files are searched when
> there's no "--with-gxx-include-dir" but with "--sysroot":
> 
> --with-gxx-include-dir=dirname
>     Specify the installation directory for G++ header files. The default depends on 
> other configuration options, and differs between cross and native configurations.
> 
> My assumption is that ${sysroot}/usr/include/c++ will be searched which is why sysroot
> option is there.

This is a bad assumption I'm afraid. I had to go and take a look at the
code to determine this though.

> However currently Poky always specifies "--with-gxx-include-dir" explicitly:
> 
> gcc-configure-cross.inc:                     
>  --with-gxx-include-dir=${STAGING_DIR_TARGET}/${target_includedir}/c++ \
> --with-sysroot=${STAGING_DIR_TARGET} \
> 
> gcc-configure-runtime.inc:    
> --with-gxx-include-dir=${includedir}/c++/ \
> --with-sysroot=${STAGING_DIR_TARGET} \
> 
> gcc-configure-sdk.inc:                      
> --with-gxx-include-dir=${SDKPATH}/sysroots/${TARGET_SYS}${target_includedir}/c++ \
> --with-sysroot=${SDKPATH}/sysroots/${TARGET_SYS} \
> 
> gcc-configure-target.inc:    
> --with-gxx-include-dir=${includedir}/c++/"
> 
> for cross/sdk, there's no difference from not using option if my assumption is correct.
> The only meaningful one is perhaps runtime. 
> 
> I checked OE side, they don't have gcc-runtime (why???), and only add the option for
> the target gcc (--with-gxx-include-dir=${includedir}/c++/{BINV}) which makes sense
> since using BINV is different from normal convention.

Whilst OE doesn't use this, if you read the configure code for this
option you'll see that it gets set to a default anyway so not specifying
it doesn't change much. In poky we dropped the BINV part of the path
which I believe is part of the default.

> So my question is whether it's necessary to explicitly set this option in Poky, upon which
> we can then talk about the issue I'm seeing and the solution.

Looking at the code I don't think it will actually make any difference
whether we set it or not.

> The major problem with hardcoded "with-gxx-include-dir" is that it makes the toolchain
> problematic when using in a separate build environment, because that hard code path
> may be missing in the new environment. It's not relocatable.
> 
> Previous SDK multi-sysroot support is one example.
> 
> So does sstate, when you need to build some new C++ packages in the 2nd build dir
> while using toolchain built from another dir. I observed this when reusing a set of
> sstate packages of a minimal image, and then started building a sato image and then
> encountered libproxy error due to failing to find cstdio.
> 
> Machine specific sysroot also has this problem, because we end up to use the toolchain
> built for the 1st machine to build recipes for the 2nd machine. It will be generally
> worked around because both sysroots exist and can be both accessed, but it's still
> a potential issue.
> 
> The workaround in my sstate case is a bit ugly. I have to use "-I" in CXXFLAGS in
> bitbake.conf:
> 
> -I${STAGING_DIR_TARGET}/${target_includedir}/c++ 
> -I${STAGING_DIR_TARGET}/${target_includedir}/c++/backward 
> -I${STAGING_DIR_TARGET}/${target_includedir}/c++/${TARGET_SYS}
> 
> If "with-gxx-include-dir" can be removed, we don't need do anything here. 

I really don't think its this simple.

Looking at the gcc code, I propose we patch cppdefault.c so instead of

GPLUSPLUS_INCLUDE_DIR "G++", 1, 1, 0, 0

is says

GPLUSPLUS_INCLUDE_DIR "G++", 1, 1, 1, 0

and then we only ever specify:

--with-gxx-include-dir=${includedir}/c++/ to build the compiler.

Since we set always set --sysroot for the compiler correctly, this
should then fix all the problems in a clean and simple way.

Why? Changing the 0 -> 1 above will cause c++ to add the sysroot to
GPLUSPLUS_INCLUDE_DIR and in turn this means it should start to behave
sanely.

I don't like patching gcc like this but in this case I believe the
standard settings are just plain wrong and with that simple change,
things will just work as they should...

Of course I've not tested this so I'd appreciate feedback but I think it
will solve the problem in the simplest way :)

Cheers,

Richard