On 2011-08-04, Donovan Watteau <[email protected]> wrote: > And I thought the official packages were built on a G5 and that it > would've been faster (and easier) to build a package that I could > have tested to see if it really fixes the crash.
In general the package build machines don't use uncommitted diffs. > Then I guess the bug is elsewhere... which is weird, because I think > clang has been tested on powerpc Actually, this is probably unlikely..it's difficult enough to get good port test reports on x86 arch, build problems on less common arch usually get picked up reasonably quickly, but it can take quite some time before runtime problems are noticed. > and that it can compile the > trivial examples I've posted earlier without crashing, right? > Could anyone with an Altivec-capable macppc test that? Works on a 7447A mac mini. > Hmm... then I think I'm starting to understand something: > See clang-2.9/lib/Lex/Makefile: > ifeq ($(ARCH),PowerPC) > CXX.Flags += -maltivec > endif > > So: the packages are built on an Altivec-capable macppc box, this > makefile makes the mistake of always enabling -maltivec, hence > __ALTIVEC__ is defined in Lexer.cpp, and I get this crash on my > non-Altivec-capable box. Am I right? :) Yes this looks like the problem. Why would they assume all ppc's support altivec? > So, the patch for SEE2 would be correct as well, wouldn't it? I don't understand this. > (As for building this myself: I've already tried it, but B&W G3 have > an old issue of timeouts... under certain circumstances, I get > "bm0: device timeout", and if I unpack a big tarball, I get wd0 > timeouts as well. Looking at the archives, it seems to be an old > bug for B&W G3; I don't have this kind of problems when > running Slackintosh. This makes building big packages under > OpenBSD almost impossible, I'm afraid.) I can't help here but that's clearly not a problem with the port build.
