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

[Tian, Kevin]

>From: Tian, Kevin
>Sent: Friday, December 31, 2010 5:44 PM
>
>>From: Khem Raj [mailto:raj.khem at gmail.com]
>>Sent: Friday, December 31, 2010 5:26 PM
>>
>>On Fri, Dec 31, 2010 at 12:52 AM, Tian, Kevin <kevin.tian at intel.com> wrote:
>>>>From: Tian, Kevin
>>>>Sent: Thursday, December 30, 2010 7:23 PM
>>>>>From: Lu, Lianhao
>>>>>Sent: Thursday, December 30, 2010 5:43 PM
>>>>>>>>
>>>>>>>> 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
>>>>>>
>>>>>
>>>>
>>>>where is that algorithm.gch supposed to stay? I searched my standard c++ include
>>>>dir (usr/include/c++) with below finding:
>>>>
>>>>usr/include/c++/ext/algorithm
>>>>usr/include/c++/algorithm
>>>>
>>>>is above "algorithm" the one you mentioned as "algorithm.gch"?
>>>>
>>>
>>> This turns out related to collect2. Actually the compilation already reached the last step,
>>> where all generated .o are linked together as one executable. This step collect2 is
>invoked
>>> implicitly to handle constructor functions. Not sure the reason yet, I saw that collect2
>>> wants to recompile workset.o for whatever reasons. Unfortunately this recompilation
>is
>>> invoked w/o "--sysroot" option, and thus no c++ header files could be located.
>>>
>>> I'm still investigating why this recompilation is triggered, and how collect2 constructs
>>> the build flags implicitly...
>>
>>the project is using precompiled headers and the build system
>>of the package should regenerate them if they are not found. Its
>>nothing that gcc can do about. You can either fix the build system
>>of package in question or stop generating precompiled headers.
>
>what do you mean by "precompiled headers"? I think the missing <iostream> or
><algorithm> here is the standard header. Actually same workset.cpp has been
>compiled successfully before the link stage. The question is how collect2 misses
>the --sysroot option when triggering the recompilation...
>

well, it looks that the compile options come from workset.rpo, which I need figure out
how it's generated. If it's the project's own build logic to generate that file by missing
sysroot option, then as you said this problem is specific to this project. If the .rpo is
some standard temp files generated by g++, then it'd be related to gcc imo...

Thanks
Kevin