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? > 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel