[CentOS-devel] CentOS 7 (1503) i686 Beta Architecture
Vladimir Stackov
amigo.elite at gmail.com
Sat Jun 6 13:09:12 UTC 2015
Ok, what should I do if I'm ready to maintain packages for public non-sse2
rebuild? How to get this rebuild covered by CentOS SIG?
As far as I know I'm prohibited to use "CentOS" in public rebuild name
until it was explicitly allowed by CentOS project.
06.06.2015 12:44 пользователь "Johnny Hughes" <johnny at centos.org> написал:
> On 06/06/2015 02:43 AM, Toni Spets wrote:
> >
> >
> > On Sat, Jun 6, 2015 at 12:09 AM, Johnny Hughes <johnny at centos.org
> > <mailto:johnny at centos.org>> wrote:
> >
> > On 06/05/2015 03:41 PM, Trevor Hemsley wrote:
> > > Is it really worth the effort? The last Pentium III was released
> in 2002
> > > and you couldn't buy them after 2003 so we're talking about
> machines
> > > that are 12 or more years old. The fastest one you could ever buy
> is
> > > outperformed by a factor of more than 2 times by each core on my
> dual
> > > core 2010 vintage Intel Atom D510.
> > >
> >
> > I don't mind the effort of compiling so much as the potential for
> > massive confusion with 2 packages named the same thing but compiled
> with
> > different gcc optimizations, as we would still have to provide the
> other
> > packages i686 packages in x86_64 arch for multilib.
> >
> >
> > Why its there a need to provide two different builds? Couldn't the
> > multilib packages be rebuilt not to require SSE2? Is the performance
> > penalty bad enough to not even consider it?
>
> The reason the items in CentOS 7 x86_64 (in this case, we are taking
> about the i686 multilib pacakges) need to be built with an unmodified
> gcc is that the whole goal of CentOS Linux is to build packages from
> RHEL sources that are as close to possible to actual Red Hat packages
> minus branding.
>
> If we change the way gcc produces those i686 packages that we put into
> our main CentOS 7 x86_64 arch then that is a huge difference. I am
> quite sure our users do not want us modifying CentOS Linux 7 production
> packages in this manner.
>
> If has nothing to do with performance, it has to do with producing
> CentOS Linux 7 x86_64 that deviates from the way the upstream packages
> are produced.
>
>
> >
> >
> >
> > But, I do agree that trying to run this on 12 year old machines is is
> > not going to be easy. CentOS-7 does not perform well without at
> least
> > 1.5GB - 2GB of RAM as well. (The installer does not even work well
> with
> > less than 1 GB RAM)
> >
> >
> > The installer does run with 512MB of RAM and it can be run around 384MB
> > of RAM as well without any modifications except lowering the requirement
> > by hand. The use cases would be headless environments like servers where
> > you can better utilize the memory like you do in virtualized
> > environments. I do have 512MB CentOS 7 64-bit VMs that perform just fine
> > for what they are tasked for.
> >
> >
> >
> > If enough people really want it, I guess it could be done as part of
> the
> > AltArch Special Interest Group .. but my initial take is not positive
> > because of the confusion potential.
> >
> >
> > > On 05/06/15 21:22, Toni Spets wrote:
> > >> This would be rather unfortunate as that would also leave out all
> > >> 32-bit only AMD processors (Athlon XP & co) as well according to
> > >> Wikipedia where it's said Athlon 64 was the first one to add SSE2
> and
> > >> it can already run the 64-bit CentOS anyway.
> > >>
> > >> I'm hoping there is more people that could +1 having support for
> > >> pre-SSE2 CPUs so it would be seriously considered even though it
> might
> > >> need massive rebuild of the multilib packages. EPEL doesn't have
> > >> multilib yet (right?) so they can still adapt to whatever is
> going to
> > >> be done. The packages would run on upstream as well anyway.
> > >>
> > >> Taking into account the actual computing power of CPUs, I don't
> think
> > >> it's unreasonable to run CentOS 7 on Pentium III or Athlon XP.
> > >>
> > >> Thanks for considering.
> > >>
> > >> On Fri, Jun 5, 2015 at 9:44 PM, Johnny Hughes <johnny at centos.org
> <mailto:johnny at centos.org>
> > >> <mailto:johnny at centos.org <mailto:johnny at centos.org>>> wrote:
> > >>
> > >> On 06/05/2015 05:46 AM, Vladimir Stackov wrote:
> > >> > Greetings,
> > >> >
> > >> > currently we are maintaining own CentOS 7 i686 rebuild and I
> > >> would like
> > >> > to kindly ask you to replace following macros from gcc.spec:
> > >> >
> > >> > %if 0%{?rhel} >= 7
> > >> > %ifarch %{ix86}
> > >> > --with-arch=x86-64 \
> > >> > %endif
> > >> > %ifarch x86_64
> > >> > --with-arch_32=x86-64 \
> > >> > %endif
> > >> >
> > >> > with that:
> > >> >
> > >> > %if 0%{?rhel} >= 7
> > >> > %ifarch %{ix86}
> > >> > --with-arch=i686 \
> > >> > %endif
> > >> > %ifarch x86_64
> > >> > --with-arch_32=i686 \
> > >> > %endif
> > >> >
> > >> > x86-64 causes gcc to use extended instruction set for
> produced
> > >> code and
> > >> > it's impossible to run CentOS 7 i686 on older systems
> > without SSE2
> > >> > instruction because of SIGILL.
> > >> > This affects Pentium 3, old VIA CPUs, old Xeons and some
> > others.
> > >> >
> > >> > Is that possible?
> > >> > Thanks!
> > >> >
> > >>
> > >> <snip>
> > >>
> > >> I don't think we can do this as I also use the RPMs produced
> > for the
> > >> multilib portion of CentOS-7 x86_64 and we want our RPMs to
> > be like
> > >> those from upstream for that purpose.
> > >>
> > >> Thanks,
> > >> Johnny Hughes
> > >>
> > >>
> >
> >
> >
> > _______________________________________________
> > CentOS-devel mailing list
> > CentOS-devel at centos.org <mailto:CentOS-devel at centos.org>
> > http://lists.centos.org/mailman/listinfo/centos-devel
> >
> >
> >
> >
> > --
> > Toni Spets
> >
> >
> > _______________________________________________
> > CentOS-devel mailing list
> > CentOS-devel at centos.org
> > http://lists.centos.org/mailman/listinfo/centos-devel
> >
>
>
>
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> http://lists.centos.org/mailman/listinfo/centos-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20150606/d7e19cdb/attachment.html>
More information about the CentOS-devel
mailing list