On 19/1/18 4:48 am, Joel Sherrill wrote: > > > On Wed, Jan 17, 2018 at 6:39 PM, Chris Johns <chr...@rtems.org > <mailto:chr...@rtems.org>> wrote: > > On 18/1/18 11:01 am, Joel Sherrill wrote: > > On Wed, Jan 17, 2018 at 5:21 PM, Chris Johns <chr...@rtems.org > <mailto:chr...@rtems.org> > > <mailto:chr...@rtems.org <mailto:chr...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
