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

[Chris Johns]

On 19/1/18 4:48 am, Joel Sherrill wrote:
> 
> 
> On Wed, Jan 17, 2018 at 6:39 PM, Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
> 
>     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>
>     > <mailto: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>
>     >     <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/
>     <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?
> 
> 
> We could but I think you missed my point that the MPC used was the one
> installed on the host -- we didn't package an MPC.
>  

Yes I did miss this.

> 
> 
>     > 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?
> 
> 
> There was no RTEMS MPC RPM. So if you built on RHEL 6 you got a different
> host MPC than if on FreeBSD. 
>  

Yes I did not know this.

> 
> 
>     > (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.
> 
> 
> This is a good thing and why I think we might has well just suck up the
> side-effects and pick a version for the RSB to use. It was an unknown variable
> for the tools built for the RPM. If you remember, there was a complex
> environment which mimicked each host to cross build. There would end
> up potentially being a different MPC version on each host and version.
> For sure, RHEL 5, 6, and 7 have different versions.
> 
> I say we just have to pick one and move on. 
>  

I selected 1.0.3 because it is used on RTEMS 5 so we will have the same version
on 4.10, 4.11 and 5.

> 
> 
>     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.
> 
> 
> +1 I also built on FreeBSD. 

Nice.

> 
> 
>     >
>     > 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.
> 
> 
> Yep. We can either pick what was used on RHEL 6 which is likely the
> most used host for the RPMs or just move to the 1.x which is on the GNU
> ftp site.
> 
> I lean to using the one on the GNU ftp site just so we have a permanent
> host to fetch from.
> 
> This is unfortunately just a side-effect of the more rigorous RSB. 
> 
> To quote Rush: If you choose not to decide, you still have made a choice.
> 
> Benevolent dictator says use the one from GNU ftp. :)
> 
> Justification: permanent URL. Nothing stronger. 
> 

I will push the 4.11 patches I posted once an 4.11/rtems-all completes.

Chris