On Mon, 20 Apr 2015, Pavel Kopyl wrote:
> Hi all,
>
>
> To build a GCC-4.9.2 ARM cross-compiler for my setting I need to configure it
> with "--with-sysroot=/ --with-gxx-include-dir=/usr/include/c++/4.9.2".
> But I found that gcc driver removes the leading slash from resulting paths:
>
> `gcc -print-prog-name=cc1plus` -v
> ...
> ignoring nonexistent directory "usr/include/c++/4.9.2" <- HERE
> ignoring nonexistent directory
> "usr/include/c++/4.9.2/armv7l-tizen-linux-gnueabi" <- AND HERE
> ignoring nonexistent directory "usr/include/c++/4.9.2/backward" <- AND HERE
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/lib/gcc/armv7l-tizen-linux-gnueabi/4.9.2/include
> /usr/local/include
> /usr/lib/gcc/armv7l-tizen-linux-gnueabi/4.9.2/include-fixed
> /usr/include
>
> It's also reproducible on trunk.
>
> Attached patch fixes this bug.
You don't explain the rationale for this patch, in terms of the logical
semantics of the various variables involved, and why, in terms of those
logical semantics, this patch is the correct approach for fixing the
observed problems.
As I read the code, it's not the driver that removes the leading slash.
Rather, it's the code in configure.ac:
gcc_gxx_include_dir_add_sysroot=0
if test "${with_sysroot+set}" = set; then
gcc_gxx_without_sysroot=`expr "${gcc_gxx_include_dir}" :
"${with_sysroot}"'\(.*\)'`
if test "${gcc_gxx_without_sysroot}"; then
gcc_gxx_include_dir="${gcc_gxx_without_sysroot}"
gcc_gxx_include_dir_add_sysroot=1
fi
fi
What I'd say is that this code is mishandling the case of a --with-sysroot
path that ends with '/' (or, I suppose, '\', on hosts where that's a
directory separator). That is, it's producing a gcc_gxx_include_dir
setting with no leading '/'. I think it would be more appropriate for
this configure.ac code to remove (sysroot minus trailing directory
separator), so that the gcc_gxx_include_dir setting after this code still
has a leading directory separator whether or not the --with-sysroot
setting ended with such a separator. Given such a configure.ac change, I
wouldn't then expect changes elsewhere in the compiler to be needed. But
if that doesn't work to fix the bug, I think you need to elaborate further
on the semantics of the various variables involved (in configure.ac and in
the compiler).
--
Joseph S. Myers
jos...@codesourcery.com
