On Wed, Jan 17, 2018 at 6:39 PM, Chris Johns <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>> 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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
