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

[Joel Sherrill]

On Wed, Jan 17, 2018 at 6:39 PM, Chris Johns <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>> 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?
>

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.


>
> > 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.


>
> > (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 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.

>
> >
> > 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.

--joel


>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180118/e4e11980/attachment-0002.html>