On 23 Aug 2010, at 18:33, Daniel Macks wrote:
> 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.
As a quick check,
running it with in addition
--target=%m-apple-darwin`uname -r|cut -f1 -d.`
and deleting for safety
--enable-runtime-cpudetection
(which seems useless, in fink/unstable,
and a potential source of trouble)
the build still fails on asm stuff :
> cc -I../libavcodec -I../libavformat -Wdisabled-optimization -Wno-
> pointer-sign -Wdeclaration-after-statement -I. -I.. -I../libavutil -
> Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -march=nocona
> -mtune=nocona -pipe -ffast-math -fomit-frame-pointer -
> D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -
> DHAVE_CONFIG_H -I/sw64/include -I/sw64/include/lame -I/sw64/lib/
> fontconfig2/include -I/usr/X11/include -I/sw64/include/freetype2 -I/
> sw64/include -I/sw64/include -I/sw64/include -I/sw64/include/
> dvdnav -c -o vf_fspp.o vf_fspp.c
> In file included from vf_fspp.c:46:
> ../libavcodec/dsputil.h: In function 'copy_block2':
> ../libavcodec/dsputil.h:675: warning: implicit declaration of
> function 'AV_WN16'
> ../libavcodec/dsputil.h:675: warning: implicit declaration of
> function 'AV_RN16'
> ../libavcodec/dsputil.h: In function 'copy_block4':
> ../libavcodec/dsputil.h:686: warning: implicit declaration of
> function 'AV_WN32'
> ../libavcodec/dsputil.h:686: warning: implicit declaration of
> function 'AV_RN32'
> {standard input}:830:32-bit absolute addressing is not supported for
> x86-64
[vf_fspp.c contains a lot of asm]
but what seems more worrysome, is that I see a bunch of
cast from pointer to integer of different size
or
initialization from incompatible pointer type
warnings before...
If it is to work on the build, it might be safer to start from the
most recent
version (rc3 : 2010 vs 2007 for rc2..)
JF
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Fink-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fink-users
