On Wed, 2010-01-20 at 12:58 -0700, Kevin DeKorte wrote: > Ok moving --prefix from common_options to mplayer_options did help some. > But I am running into some more issues. > > make -j 4 doesn't appear to work right, make -j 1 is a workaround It should work and AFAIK does for everyone else. What kind of issues did you see? Does building work if you create a normal build instead of trying to force a 32 bit build on a 64 bit machine? > libass does not seem to pick up values from the common_options. I'm Yes it doesn't use the same file. And it probably shouldn't, I think there are few configure options that would be accepted by all of MPlayer, FFmpeg and libass... > trying to build a 32bit mplayer on a 64bit machine (mainly so I can use > the additional codecs) and so I have placed this in my common_options Somewhat offtopic, do you really find the support for some extra binary codecs more important than the speed loss? And the trouble to have 32-bit versions of all OS dependency libraries available? > I have attached a python version of libass-config, but since I have not I guess you copied that from mplayer-config; some of the things left make little sense for libass, but I guess they don't break anything when testing. > figured out what options to use to build it in 32bit mode I'm still > kinda stuck. libass does not seem to like the --cc and --as options. libass configure is autoconf-based so I'd expect it to accept typical autoconf arguments, though I don't know if it's supposed to support any form of cross-compiling. Setting the CC environment variable should at least work to select the compiler used. I'm not particularly familiar with the libass build system myself. > Hope this is clear as to what I am trying to do. I'm not sure whether the build repo should try to support this kind of special builds or not. At least more complicated hacks are probably better scripted using the mplayer repo directly. If you have problems building a 32-bit libass at least building in a 32-bit chroot should work.