Bug#712956: marked as done (0ad: seems to use CPU features not available everywhere)

[Kurt Roeckx]

On Sat, Sep 07, 2013 at 01:53:26AM -0700, Vincent Cheng wrote:
> On Sat, Sep 7, 2013 at 1:46 AM, Kurt Roeckx <kurt at roeckx.be> wrote:
> > On Sat, Sep 07, 2013 at 01:21:59AM -0700, Vincent Cheng wrote:
> >> On Sat, Sep 7, 2013 at 1:02 AM, Kurt Roeckx <kurt at roeckx.be> wrote:
> >> > reopen 712956
> >> > thanks
> >> >
> >> >>  nvidia-texture-tools (2.0.8-1+dfsg-4) unstable; urgency=low
> >> >>  .
> >> >>    [ Fabio Pedretti ]
> >> >>    * Add armel and armhf build support (Closes: #721972)
> >> >>    * Remove -march=athlon64 from CXXFLAGS (Closes: #713966, #712956)
> >> >
> >> > This is clealy the wrong bug you're closing.  It's assigned to
> >> > 0ad.
> >> >
> >> > 0.0.14-2 is still using -msse -march=i686 on i386
> >>
> >> See explanation by upstream here [1]. If compiling with -march=i686 is
> >> strictly not allowed on Debian i386, I can just simply stop building
> >> 0ad for i386, although I'm not sure if that's necessary at all; the
> >> package has been sitting in the archive for over a year and I still
> >> haven't gotten any complaints about 0ad not running on any Debian
> >> user's i386 machine.
> >
> > I don't know if having i686 is acceptable or not.  But I currently
> > see no good reason for it.  [1] is my own comment.  The only reply
> > to that is that they still use the legacy functions, and no reply
> > as to why they need to keep using it and can't move to the new
> > ones.
> 
> Err, sorry, should have linked to comment #7 instead in that ticket. [1]
> 
> "
> We wouldn't run on an actual 486 due to use of several newer CPU
> instructions, one of which is the CAS in ia32.cpp. If indeed we have
> to compile with -march=i486, which sounds like a last resort, the CAS
> could be replaced with GCC-specific assembly, and we'd have a decent
> hope of compiling successfully.
> "

CAS being a compare and swap?  Which is the atomic function they want
to use?

> To me that sounds reasonable enough as to why we should be building
> 0ad with -march=i686.

Anyway, I have no idea if g++ supports those new atomic functions
without -march=i686, but I at least hope so.

> >> > It wasn't using -march=athlon64 on amd64 before either as far as I
> >> > know but had problem running on at least one of the buildds.
> >>
> >> The original issue was that nvidia-texture-tools was compiled with
> >> -march=athlon64, which caused one of the amd64 buildds to complain
> >> about an "Illegal instruction" when trying to run 0ad's test suite
> >> when building 0ad. There's a relevant issue filed against upstream
> >> nvidia-texture-tools about this as well. [2]
> >
> > So that was #713966 and that was fixed in 0ad with the 0.0.14-2
> > uploaded?
> 
> Yes, should be fixed now, but again, since I don't have any hardware
> where I can reproduce this locally, I suppose the only way to prove
> that this is fixed is to have 0ad 0.0.14-2 be rebuilt on barber.

I've triggerd that it gets build on barber, you should have a log
about that in half an hour I guess.


Kurt