Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows

2016-05-10 Thread Brett Neumeier 
On Mon, May 9, 2016 at 4:10 PM, Andrew Pinski  wrote:
> This sounds like a good use of --with-build-sysroot instead of just
> --with-sysroot.
> I use the following for the candian cross:
> --with-sysroot=/ --with-build-sysroot=${SYSROOT}

Hi Andrew! Thanks for your comment.

I thought that --with-build-sysroot is only for cross-compiler builds?
I have to admit I'm not very clear on the way that all the
cross-compiler options are intended to be used, but I am pretty sure
that it's not relevant for my case.

I have a cross-compiler that *seems* perfectly functional, for which I specify:

--build = host
--host = host
--target = target
--with-sysroot = the sysroot dir
--with-build-sysroot = the sysroot dir

Then I'm using that compiler to build a target-native compiler
installed into the sysroot directory, for which I'm specifying:

--build = host
--host = target
--target = target
--with-local-prefix = the sysroot dir

Do you think things will work better for the target-native compiler if
I use a sysroot option for it as well?

Aside from the C++ header path lookup thing that GCC 6.1 introduced, I
haven't had any problems with the target-native compiler. (I'm able to
build at least tcl, expect, dejagnu, and perl with it already.)

-- 
Brett Neumeier (bneume...@gmail.com)

Re: Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows

2016-05-09 Thread lh mouse 
I have a vision. It is gcc/gcc/incpath.c that the problem is in.
I had been looking through that file for a few days but eventually gave up.

It is worth mentioning that adding an '-iprefix /this/need/not/exist' vanishes 
the problem.
This might have something to do with the following line in incpath.c (it should 
be line #132 on gcc-6-branch at the moment):
```
  if (iprefix && (len = cpp_GCC_INCLUDE_DIR_len) != 0)
```
Still I have no idea about how relocated paths are pulled in.

I am looking forward to a patch for the relocation problem.

--   
Best regards,
lh_mouse
2016-05-10

-
发件人：Brett Neumeier <bneume...@gmail.com>
发送日期：2016-05-10 04:31
收件人：lh_mouse
抄送：Jonathan Wakely,gcc
主题：Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows

On Tue, May 3, 2016 at 10:01 AM, lh_mouse <lh_mo...@126.com> wrote:
> Should I file a bug report then?
> We need some Linux testers, though not many people on Linux relocate 
> compilers.

For what it's worth -- I encountered the same problem on a GNU/Linux
system. In my specific situation, I'm cross-compiling GCC using an
AMD64-to-mips64el cross-toolchain, and installing the resulting GCC in
a sysroot directory. When I try to use that GCC on a target device
where (of course) the sysroot directory becomes "/", the hard-coded
"/path/to/sysroot" from the host system is still used to find the C++
headers, resulting in the same ".../include/c++/6.1.1/cstdlib:75:25:
fatal error: stdlib.h: No such file or directory" error message you
got.

Changing #include_next to #include in cstdlib and cmath fixed my
problem -- so, thank you very much for this discussion! It helped at
least one other person.

Please let me know if there's any other testing I can do to help.

Cheers,

Brett

Re: Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows

2016-05-09 Thread lh mouse 
We use neither --with-sysroot nor --with-build-sysroot.
The reason is that, the hard-coded path in GCC repository - that is, the 
/mingw/ one - does not actually exist.

In order to build GCC for mingw targets, we take either solution:
0) Make a symlink (or rather, a copy, since Windows does not support symlinks) 
as /mingw/, as mentioned in 
https://sourceforge.net/p/mingw-w64/wiki2/Native%20Win64%20compiler/
1) Replace the non-existent path with an existent one, as done in 
https://github.com/lhmouse/MINGW-packages/blob/master/mingw-w64-gcc-git/PKGBUILD#L112

--   
Best regards,
lh_mouse
2016-05-10

-
发件人：Andrew Pinski <pins...@gmail.com>
发送日期：2016-05-10 05:10
收件人：Brett Neumeier
抄送：lh_mouse,Jonathan Wakely,gcc
主题：Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows

On Mon, May 9, 2016 at 1:31 PM, Brett Neumeier <bneume...@gmail.com> wrote:
> On Tue, May 3, 2016 at 10:01 AM, lh_mouse <lh_mo...@126.com> wrote:
>> Should I file a bug report then?
>> We need some Linux testers, though not many people on Linux relocate 
>> compilers.
>
> For what it's worth -- I encountered the same problem on a GNU/Linux
> system. In my specific situation, I'm cross-compiling GCC using an
> AMD64-to-mips64el cross-toolchain, and installing the resulting GCC in
> a sysroot directory. When I try to use that GCC on a target device
> where (of course) the sysroot directory becomes "/", the hard-coded
> "/path/to/sysroot" from the host system is still used to find the C++
> headers, resulting in the same ".../include/c++/6.1.1/cstdlib:75:25:
> fatal error: stdlib.h: No such file or directory" error message you
> got.
>
> Changing #include_next to #include in cstdlib and cmath fixed my
> problem -- so, thank you very much for this discussion! It helped at
> least one other person.
>
> Please let me know if there's any other testing I can do to help.


This sounds like a good use of --with-build-sysroot instead of just
--with-sysroot.
I use the following for the candian cross:
--with-sysroot=/ --with-build-sysroot=${SYSROOT}

Thanks,
Andrew

>
> Cheers,
>
> Brett

Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows

2016-05-09 Thread Andrew Pinski 
On Mon, May 9, 2016 at 1:31 PM, Brett Neumeier  wrote:
> On Tue, May 3, 2016 at 10:01 AM, lh_mouse  wrote:
>> Should I file a bug report then?
>> We need some Linux testers, though not many people on Linux relocate 
>> compilers.
>
> For what it's worth -- I encountered the same problem on a GNU/Linux
> system. In my specific situation, I'm cross-compiling GCC using an
> AMD64-to-mips64el cross-toolchain, and installing the resulting GCC in
> a sysroot directory. When I try to use that GCC on a target device
> where (of course) the sysroot directory becomes "/", the hard-coded
> "/path/to/sysroot" from the host system is still used to find the C++
> headers, resulting in the same ".../include/c++/6.1.1/cstdlib:75:25:
> fatal error: stdlib.h: No such file or directory" error message you
> got.
>
> Changing #include_next to #include in cstdlib and cmath fixed my
> problem -- so, thank you very much for this discussion! It helped at
> least one other person.
>
> Please let me know if there's any other testing I can do to help.


This sounds like a good use of --with-build-sysroot instead of just
--with-sysroot.
I use the following for the candian cross:
--with-sysroot=/ --with-build-sysroot=${SYSROOT}

Thanks,
Andrew

>
> Cheers,
>
> Brett

Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows

2016-05-09 Thread Brett Neumeier 
On Tue, May 3, 2016 at 10:01 AM, lh_mouse  wrote:
> Should I file a bug report then?
> We need some Linux testers, though not many people on Linux relocate 
> compilers.

For what it's worth -- I encountered the same problem on a GNU/Linux
system. In my specific situation, I'm cross-compiling GCC using an
AMD64-to-mips64el cross-toolchain, and installing the resulting GCC in
a sysroot directory. When I try to use that GCC on a target device
where (of course) the sysroot directory becomes "/", the hard-coded
"/path/to/sysroot" from the host system is still used to find the C++
headers, resulting in the same ".../include/c++/6.1.1/cstdlib:75:25:
fatal error: stdlib.h: No such file or directory" error message you
got.

Changing #include_next to #include in cstdlib and cmath fixed my
problem -- so, thank you very much for this discussion! It helped at
least one other person.

Please let me know if there's any other testing I can do to help.

Cheers,

Brett

Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows

2016-05-03 Thread lh_mouse 
Should I file a bug report then?
We need some Linux testers, though not many people on Linux relocate compilers.

--   
Best regards,
lh_mouse
2016-05-03

-
发件人：Jonathan Wakely <jwakely@gmail.com>
发送日期：2016-05-03 17:00
收件人：lh_mouse
抄送：gcc
主题：Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows

On 2 May 2016 at 11:41, lh_mouse wrote:
> However, I am not exactly clear about whether it is these headers (cstdlib 
> and cmath currently, there might be more) that are the problem.

No, it's only those two.

> In my point of view, it is the inversion of C and C++ header paths that is 
> the problem.

Agree. I don't know why that happens though.

Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows

2016-05-03 Thread Jonathan Wakely 
On 2 May 2016 at 11:41, lh_mouse wrote:
> However, I am not exactly clear about whether it is these headers (cstdlib 
> and cmath currently, there might be more) that are the problem.

No, it's only those two.

> In my point of view, it is the inversion of C and C++ header paths that is 
> the problem.

Agree. I don't know why that happens though.

Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows

2016-05-02 Thread lh_mouse 
I made some investigation yesterday and here is the result:
```

Diff'ing gcc/libstdc++-v3/include/c_global/cstdlib from gcc-5-branch and 
gcc-6-branch gives the following result:
(git diff gcc-5-branch gcc-6-branch -- libstdc++-v3/include/c_global/cstdlib)
```
@@ -69,7 +69,11 @@ namespace std
 
 #else
 
-#include 
+// Need to ensure this finds the C library's  not a libstdc++
+// wrapper that might already be installed later in the include search path.
+#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
+#include_next 
+#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS
 
 // Get rid of those macros defined in  in lieu of real functions.
 #undef abort
```
Replacing #include_next with #include fixes the problem.

However, I am not exactly clear about whether it is these headers (cstdlib and 
cmath currently, there might be more) that are the problem.
In my point of view, it is the inversion of C and C++ header paths that is the 
problem.



--   
Best regards,
lh_mouse
2016-05-02

GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows

2016-05-02 Thread lh_mouse 
This is a cross-post from gcc-help as there haven't been any replies on 
gcc-help since two days ago. Hope someone could help.
```

I have built GCC from gcc-6-branch in MSYS2 with mingw-w64 CRT on Windows today.
Now I have a relocation problem:

Assuming mingw-w64 headers are located in the follow directory,which is, the 
native_system_header_dir:
> C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/include
I have built GCC and it has that hard-coded path.
When I compile something using g++ -v, the headers are searched in the 
following paths:
```
ignoring nonexistent directory "/mingw32/include"
ignoring duplicate directory "C:/MinGW/MSYS2/mingw32/i686-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 C:/MinGW/MSYS2/mingw32/include/c++/6.1.1
 C:/MinGW/MSYS2/mingw32/include/c++/6.1.1/i686-w64-mingw32
 C:/MinGW/MSYS2/mingw32/include/c++/6.1.1/backward
 C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/include
 C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/../../../../include
 C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/include-fixed
 
C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/../../../../i686-w64-mingw32/include
End of search list.
```
The C++ headers are searched before any mingw-w64 headers, which is just fine.

However, if I move gcc to another directory, let's say, 
C:/this_is_a_new_directory/mingw32/,
then re-compile the same program with g++ -v, the headers are searched in the 
following paths:
```
ignoring duplicate directory 
"C:/this_is_a_new_directory/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.1.1/include"
ignoring nonexistent directory "C:/MinGW/MSYS2/mingw32/include"
ignoring nonexistent directory "/mingw32/include"
ignoring duplicate directory 
"C:/this_is_a_new_directory/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.1.1/include-fixed"
ignoring duplicate directory 
"C:/this_is_a_new_directory/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.1.1/../../../../i686-w64-mingw32/include"
ignoring nonexistent directory "C:/MinGW/MSYS2/mingw32/i686-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 
C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/include
 
C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/../../../../include
 
C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/include-fixed
 
C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/../../../../i686-w64-mingw32/include
 C:/this_is_a_new_directory/mingw32/lib/gcc/../../include/c++/6.1.1
 
C:/this_is_a_new_directory/mingw32/lib/gcc/../../include/c++/6.1.1/i686-w64-mingw32
 C:/this_is_a_new_directory/mingw32/lib/gcc/../../include/c++/6.1.1/backward
End of search list.
```
This time the C++ headers are searched after mingw-w64 headers, which causes 
the following error:
```
In file included from 
C:/MinGW/mingw32/include/c++/6.1.1/ext/string_conversions.h:41:0,
 from 
C:/MinGW/mingw32/include/c++/6.1.1/bits/basic_string.h:5402,
 from C:/MinGW/mingw32/include/c++/6.1.1/string:52,
 from 
C:/MinGW/mingw32/include/c++/6.1.1/bits/locale_classes.h:40,
 from C:/MinGW/mingw32/include/c++/6.1.1/bits/ios_base.h:41,
 from C:/MinGW/mingw32/include/c++/6.1.1/ios:42,
 from C:/MinGW/mingw32/include/c++/6.1.1/ostream:38,
 from C:/MinGW/mingw32/include/c++/6.1.1/iostream:39,
 from test.cpp:1:
C:/MinGW/mingw32/include/c++/6.1.1/cstdlib:75:25: fatal error: stdlib.h: No 
such file or directory
 #include_next 
 ^
compilation terminated.
```

Do you know how to solve this problem (modifications to gcc source code are 
expected)?
Thanks in advance.



--
Best regards,
lh_mouse
2016-05-02