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

[Tian, Kevin]

>From: Richard Purdie [mailto:richard.purdie at linuxfoundation.org]
>Sent: Friday, December 24, 2010 10:38 PM
>
>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.

that's why I'm sending this mail to make it clear. :-)

>
>> 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.

yes, so far that default has nothing to do with the sysroot option. I made an experiment
just now. The default path ends up pointing to: 

${STAGING_DIR_NATIVE}/usr/${TARGET_SYS}/include/c++/${BINV}

which is based on ${libdir}. 

So as you said, this doesn't change anything in this point.

BTW is there any other impact of this difference between OE and Poky? I mean installing
to native/sdk sysroot(OE) and to target sysroot (poky)...

>
>> 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.

Yep

>
>> 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 :)
>

That's a good and simple idea! I'll try it, but the test may take time... :-)

Thanks
Kevin