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

[Tian, Kevin]

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

Thanks
Kevin