On Sat, Sep 07, 2013 at 01:53:26AM -0700, Vincent Cheng wrote: > On Sat, Sep 7, 2013 at 1:46 AM, Kurt Roeckx <k...@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 <k...@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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
