On (15/12/11 12:16), Richard Purdie wrote: > On Wed, 2011-12-14 at 07:49 -0800, Khem Raj wrote: > > On Wed, Dec 14, 2011 at 2:02 AM, Richard Purdie > > <[email protected]> wrote: > > > Hi Khem, > > > > > > What's puzzling me is that reading through this patch, we already do > > > what this patch is doing? > > > > > > Where is the difference which this patch is fixing? > > > > > > > this does essentially what we were doing earlier but this one is going > > to go upstream > > Yes, that is good and I'm fine with the patch for that reason.
there is additional detail that this patch does which is that in order to make gxx-includes to be sysroot relative --with-cxx-include option to be also specified relative to initials sysroot during configure time e.g. --with-sysroot=SYSROOT --with-gxx-include-dir=SYSROOT/usr/include/c++ since the original behavior of --with-gxx-include-dir is to specify an absolute path that is preserved whereas the patch we have in OE relocates gxx-include-dir regardless.Therefore in order to adopt this patch we have to use the above syntax which was original syntax before the above patch and would make up forward compatible provided this patch makes into gcc upstream. > > > > > > I appreciate that patch adds in the prefix to the --with-gxx-include-dir > > > option but it then removes it again during configure so this should be a > > > null op. Both versions of the patch set the "1" bit in gcc/cppdefault.c. > > > > > > So where is the change this patch makes which fixes things? > > > > changing --with-gxx-include-dir to be within sysroot triggers the > > relocation code. > > But we were already triggering the relocation code? > > I can't see *any* functionality difference between these, they should > both just give the same result as far as I can tell... > same functionality but with a different usage see above > Claiming it fixes things is therefore concerning me. correct it does not fix anything actually that I know was broken before Thinking out loud given that with-gxx-include-dir is absolute in nature it could be the original patch we have, does not work in some weird case since the absolute path we use is still /usr/include/c++ during configure time. although I would expect that the include poisoning warning will report it if that happened -Khem _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
