On Sat, Aug 06, 2011 at 01:09:50AM +0000, Stuart Henderson wrote: > 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? > Altivec will work fine on all but the few G3 and 603/604 machines that may still be running, altivec is supported on G5 and G4 machines.
$ sysctl machdep.altivec machdep.altivec=1 will tell if the machine is capible of running altivec code. If code such as llvm is written to always use altivec, without a compile time option, not much we can do. If they have a compile time switch it may be appropriate to build to flavors of the port. If the code could be modified to do a runtime check would be great. > > > 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. > Unless we were to choose to make two flavors of the port (not certain if this is desireable or not). Dale Rahn [email protected]
