[PATCH] gcc: Reference GNU's FTP site for all GCC parts.

[Chris Johns]

On 18/1/18 11:01 am, Joel Sherrill wrote:
> On Wed, Jan 17, 2018 at 5:21 PM, Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
> 
>     On 18/1/18 9:30 am, Joel Sherrill wrote:
>     > Why can't we change it to here for 4.10?
>     >
>     > http://www.multiprecision.org/downloads/mpc-0.8.1.tar.gz
>     <http://www.multiprecision.org/downloads/mpc-0.8.1.tar.gz>
>     >
> 
>     We could however it leaves us open to the same issue that started us looking at
>     this problem and there is a push to make 4.10 a long term supported release. If
>     the home site changes it breaks the release branch.
> 
>     With RPM tool's was the host's (distros) shared library version being used? I
>     seem to remember the view at the time was host's version was preferred cause
>     distro maintainers always know best. If this is the case which version is being
>     used?
> 
>     I see the alternatives as:
> 
>      1. Investigate the role MPC plays and what effect it has on the generated code.
>      2. Make MPC a special and hope the web site stays the same.
> 
>     No matter what path we take we need to make sure we are happy with the generated
>     code for the RSB tools to make a release. How do we do this?
> 
>      a. Assume it is OK if the tests results match.
>      b. Check the generated code.
> 
>     Checking the generated code requires a build of the 4.10.2 kernel with the RPM
>     tools. If this path is taken I need a tarball of the installed only 4.10.2
>     kernel built with RPM tools for selected archs. I can then check the generated
>     code. I have no ability to install and run the RPM tools.
> 
> 
> I actually wonder how hard it would be to do this. I suspect you need 
> something like CentOS 6 or 7 and compatibility libraries. If that's sufficient
> and possible. 

What about using:

 rtems-4.10-sparc-rtems4.10-newlib-1.18.0-34.el6.noarch.rpm
 rtems-4.10-sparc-rtems4.10-gcc-libstdc++-4.4.7-6.el6.noarch.rpm
 rtems-4.10-sparc-rtems4.10-gcc-libgcc-4.4.7-6.el6.noarch.rpm

from:

 https://ftp.rtems.org/pub/rtems/archive/rpms/linux/4.10/centos/6/i386/

?

We could check some of the code in libgcc and newlib libraries built with the
RPM executables at the time?

> A quick check shows the CentOS 6 RPM for mpc is 0.8-3 so 0.8 with patches.
> That's more suspect to me than a base use of something newer. It doesn't match
> anything any other distribution is going to have. And it used gcc 4.4.x as a host
> compiler. 4.4.7 was the RPM I found on a random mirror.

Yes it is a mess and the more you look the harder it gets to quantify what is
actually being used.

Is the RTEMS MPC RPM installed and if installed is it used?

> (1) is what we have done in the past. But we decided that depending on the
> host for mpc and mpfr was a risk. 

Yes and why the RSB is very specific about how it is built and what is built. It
is just over 6 years since 4.11.2 was released with RPM tools and the RSB puts
us in an excellent position to create a long term supported release.

I have built the 4.10 branch tools on FreeBSD 11.1, Windows 10 64bit, MacOS
(High Sierra) and you and Gedare have built them on Linux and I think this is
pretty neat. The credit for this must go to all of the standardization work in
gcc and parts and various hosts such as FreeBSD, Linux, MacOS and Cygwin.

> 
> I would lean to picking something -- anything-- for mpc and just moving 
> forward.
>  

I tend to agree but we need to do some checking at the RSB level.

Chris