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

[Lu, Lianhao]

Tian, Kevin wrote on 2010-12-30:
>> From: Tian, Kevin
>> Sent: Tuesday, December 28, 2010 11:25 AM
>> 
>>> 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_inc
>>> lu dedir}/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... :-)
>> 
> 
> I've at least verified this change working in one of my sstate build,
> where c++ include dir could be searched successfully relative to sysroot.
> 
> Lianhao is helping me test SDK multiple sysroot scenario, and I'm
> testing more archs to ensure it not breaking normal build.

The simple helloworld CPP can be built successfully by Kevin's new cross-candian-gcc now. But another complex CPP project Sudoku still have the building problems, complaining about not finding c++ header "#include <algorithm>". The strace output shows that the failure is caused by not finding the algorithm.gch on the target.

> http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=tk/cplusplu s
> 

Best Regards,
Lianhao