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.