[Mplayer-cvslog] CVS: main configure,1.915,1.916

[Sascha Sommer]

On Monday 27 September 2004 05:49, Attila Kinali wrote:
> On Sun, Sep 26, 2004 at 04:49:36PM +0200, Sascha Sommer CVS wrote:
> > +short asci_name[] = {
> > (('M'<<8)|'P'),(('l'<<8)|'a'),(('y'<<8)|'e'),(('r'<<8)|0)};
>
> This test will fail if short is not 16bit on the target architecture.
> What about using an int and "MPla" ? It's quite safe to assume, that
> an int is at least 32byte (16bit systems wont be able to run MPlayer
> anyways). Note that assuming that int is always 32bit is also not safe,
> ie using two ints with "MPla" + "yer " would fail on a 64bit target
> architecture.
> If int is not long enough, ie "MPla" can apear in compiled code too,
> we should use a long long, after it has been tested to be 64bit.

See the mail form Richard.

> BTW: there are a lot of checks that depend on the architecture you
> run them on, did you check them whether they are safe for cross
> compiling ?
>

For crosscompiling for mingw there are currently at least 2 more problems, 
where the configure script would execute cross-compiled code
The MP_WORDSIZE define maybe we could solve it like this

#include <stdio.h>
#include <sys/types.h>
char ascii_name[] = { 'W','O','R','D','S','I','Z','E',
(sizeof(size_t)>>1)+48,0};
int main(){
  char* s = ascii_name;
  return 0;
} 

_wordsize=`strings prog | grep WORDSIZE | cut -d E -f 2`
_wordsize=`expr $_wordsize \* 16 `

and the faad version check. Maybe a general macro for extracting strings
from executables would be better.

Of course the cpu optimizations have to be set manually or you need to compile 
MPlayer with runtime-cpudetection. Thinking about cross compiling for linux
there are probably a lot more problems, like the framebuffer support, 
realtime-clock and others. 

Sascha