Hi, On 8 May 2015 at 00:07, Joseph Myers <jos...@codesourcery.com> wrote: > 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).
There is this old patch submitted by Matthias on that same issue, if its logic is the right one for you Joseph I can rebase/validate it Joseph. https://gcc.gnu.org/ml/gcc-patches/2012-02/msg00320.html Cheers, Yvan > -- > Joseph S. Myers > jos...@codesourcery.com