--with-gxx-include-dir and sysroot

* --with-gxx-include-dir and sysroot
@ 2010-12-24  7:34 Tian, Kevin
  2010-12-24 14:37 ` Richard Purdie
  0 siblings, 1 reply; 13+ messages in thread
From: Tian, Kevin @ 2010-12-24  7:34 UTC (permalink / raw)
  To: poky

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.

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_includedir}/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.

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.

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. Or else
above simple workaround is not enough since "with-gxx-include-dir" is set differently
for gcc variances like sdk/cross, and we need differentiate them at right place 
instead of punching global CXXFLAGS.

comments?

Thanks
Kevin

^ permalink raw reply	[flat|nested] 13+ messages in thread