Alright, let's get this solved and pushed, with or without maintainer's assistance. vf_ilpack.c has a bunch of 64-bit-specific assembly, for example: #ifdef ARCH_X86_64 "mov %6, %%"REG_BP" \n\t" #else "movl 4(%%"REG_d"), %%"REG_BP" \n\t" "movl (%%"REG_d"), %%"REG_d" \n\t" #endif
so one possibility is that ARCH_X86_64 isn't being set (i.e., the non-64bit code is being used). Someone with a 10.6/x86_64 sandbox should debug that issue. And all the assembly is controlled by: #ifdef HAVE_MMX so even if the asm itself can't be fixed, it can probably be disabled simply by forcing that token to be undefined. Not sure if there's a ./configure flag to override the detection/setting of it. dan On Mon, 23 Aug 2010 07:30:47 -0700, PNM wrote: The maintainer has known about this issue for months. I don't know what the holdup is. Perhaps he has an update? > > Payam > > _____________ > Rock journalism is people who can't write interviewing people who can't talk for people who can't read. --Frank Zappa > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Fink-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fink-users > > -- Daniel Macks [email protected] ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Fink-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-users
