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

[Tian, Kevin]

The Sudoku problem ends up to be a gcc bug. Sudoku uses templates and "-frepo"
to enabled automatic template generation. Collect2 may trigger some recompilations
based on template usages at link time. The compile flags of collect2 comes from
COLLECT_GCC_OPTIONS, which contain most flags passed from gcc switches. However
"--sysroot" doesn't fall into saved switches which are simply ignored. It's also not
solved in the trunk yet.

I've filed a gcc bug for it:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47256

Thanks
Kevin

>From: Tian, Kevin
>Sent: Friday, December 31, 2010 5:50 PM
>
>>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