[FFmpeg-devel] [PATCH] WinCE does not support _lseeki64

Martin Storsjö martin
Mon Jul 13 22:23:49 CEST 2009


On Mon, 13 Jul 2009, M?ns Rullg?rd wrote:

> > The remaining issues (in my case) are the following:
> > - libavcodec/arm/asm.S has a few elf-specific arm attributes 
> >   (.eabi_attribute, .type). I solved these by just commenting them out 
> >   (see one of the attached patches), a proper solution would probably be 
> >   to check for the binary format in configure and enable them 
> >   conditionally. But I don't have any real clue about arm assembly... I 
> >   can give more details or test out solution proposals if somebody's 
> >   interested in fixing it.
> 
> These should be easy to fix.  Does ".type foo, STT_FUNCTION" work?  If
> not, we can simply disable this too.  It's not essential, but useful
> for debugging.

No, STT_FUNCTION doesn't work either. FWIW, the error messages look like 
this:

libavcodec/arm/dsputil_arm_s.S: Assembler messages:
libavcodec/arm/dsputil_arm_s.S:106: Warning: .type pseudo-op used outside 
of .def/.endef ignored.
libavcodec/arm/dsputil_arm_s.S:106: Error: junk at end of line, first 
unrecognized character is `p'

(For both the initial version and for the STT_FUNCTION version.)

> > - ffmpeg.c needs a whole bunch of ugly hacks, attached here just for 
> >   reference. signal.h (and the whole concept of signals) are missing, 
> >   GetProcessTimes is declared but not present in the link libraries, 
> >   conio.h is available but doesn't contain anything. And perror, strerror, 
> >   errno and isatty are unavailable.
> 
> None of these are essential.  We just need to test for them, and
> disable whatever isn't available.

I'll see if I get the time to have a stab at it some day, to sort out what 
tests are needed. It isn't any important part of my use case. Part of it 
should be solved just by fixing the mingw32ce headers, too (not 
advertising things that isn't actually present in the libraries).

// Martin



More information about the ffmpeg-devel mailing list