[FFmpeg-devel] libossupport status

[Michael Niedermayer]

On Sat, Dec 22, 2007 at 12:20:51PM +0100, Luca Abeni wrote:
> Hi all,
> 
> int the last weeks, I've been silent about libossupport, but I continued
> to work on it. Here is a report about the current status of things.
> 
> First of all, the requirements:
> 1) Eliminate all the OS-dependent code from libav* (this can be achieved
> in small steps)
> 2) For standard (POSIX?) systems, no dependency on libossupport should
> be created
> 3) libav* code should use standard (POSIX?) functions, and the
> implementation of such functions for non-standard systems should be
> provided by libossupport
> 4) It seems that most of the developeres do not want libossupport in
> ffmpeg, but want it as an external library.
> 
> Did I understand the requirements correctly? 

Yes, though i think its ok if
libossupport exists besides libavformat,libavcodec there just should be
no dependencies. I dont think its needed to be completely external in the
sense of "not in ffmpeg svn".
OTOH if mans/diego want it in a seperate repo on mphq they can create one,
that is if one exists we can surely put loss there. If not i wont wait for
root at mphq to create one ...
But having loss in the ffmpeg repo has the advantage of a shared configure
script which would be nice ...


> Am I forgetting anything?
> 
> 
> Based on the requirements listed above, I developed the attached
> patch... It builds ok on Linux x86 (32), and passes some tests. I also
> checked the compilation log, and no new warnings are introduced.
> 
> Obviously, the patch breaks the compilation on almost all the non-Linux
> platforms. On such platforms, libossupport is needed. I developed the
> attached prototype by copying some code from libavformat, and it allows
> to cross-compile mingw binaries from Linux (I suppose native mingw
> builds are ok too, but I cannot test - no windows machines here).
> The attached libossupport is just a prototype for testing, and it has a
> lot of limitations:
> 1) The build system is just a joke. It allows to cross-compile from
> Linux, but you will probably have to edit config.mak by hands
> 2) I created some empty header files, and put all the code in
> netinet/in.h... This probably has to be split in the different headers
> 3) Only mingw is currently supported
> 
> (Note that as I previously said I am not interested in maintaining an
> external OS support library... So, not expect me to work too much on the
> external libossupport)
> 
> How I compile:
> 1) cd /tmp; tar xvzf loss-3.tgz; cd libossupport; make
> 2) download ffmpeg from svn, and apply remove_ossupport-2.diff
> 3) ./configure --cross-compile --cross-prefix=i586-mingw32msvc- --enable-memalign-hack --target-os=mingw32 --extra-cflags="-I /tmp/libossupport" --extra-ldflags="-L /tmp/libossupport" --extra-libs="-lws2_32 -lossupport"
> (As you can see, compiling for non-Linux platforms can become a
> nightmare - maybe we can add a --with-libossupport switch to configure?)
> 
> Anyway, the resulting binaries seem to work ok (tested with wine), and
> network works too (I did some streaming tests).
> 
> 
> As usual, comments and feedback are more than welcome.


> void usleep(unsigned long t)
> {
>     Sleep(t / 1000);
> }
>
> off_t lseek(int f, off_t p, int w)
> {
>     return _lseeki64(f, p, w);
> }

these have to be under some #ifdef


> #if !defined(HAVE_INET_ATON)

#ifndef


> #ifdef CONFIG_FFSERVER

no FF* belongs to loss


And of course, configure must check if functions are missing before they are
activated ...


> #if defined(__BEOS__) || defined(__INNOTEK_LIBC__)
> typedef int socklen_t;

All such code must be replaced by proper configure checks. There should be no
checks specific to some sofware but rather generic checks, here it would be
a check for socklen_t.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071222/4f0c1ace/attachment.pgp>