[FFmpeg-devel] [RFC] remove lrintf fallback implementation

Diego Biurrun diego
Tue Oct 23 00:17:22 CEST 2007

On Mon, Oct 22, 2007 at 11:40:57PM +0200, V?ctor Paesa wrote:
> > However, I think this is the wrong approach.  If you are going to
> > implement llrint(), do it in Cygwin, not in FFmpeg.  It is the right
> > place to fix the issue instead of working around it and will give you
> > better karma by helping many other projects, not just FFmpeg.
> >
> > See this thread I started on the Cygwin mailing list (and ignore the
> > flamage):
> >
> > http://thread.gmane.org/gmane.os.cygwin/92561
> >
> > All you have to do is add llrint() to newlib, Cygwin will pick it up
> > from there.  Alternatively you can wait for the next gcc upgrade in
> > Cygwin, which will reportedly carry along llrint().
> >
> > All in all I am against this patch.  We should be removing
> > platform-specific workarounds, not adding more of them.  If you cannot
> > wait for this to get fixed by the gcc upgrade, address the problem in
> > the right place, i.e. patch Cygwin, not FFmpeg.
> I have downloaded newlib source and they favour .S files to inline
> assembly so waiting for the next gcc looks a viable alternative (it will
> take more or less the same time than me learning how to prepare a patch).
> To make things a bit more difficult: my patch is based on LGPL'ed code,
> and Cygwin only uses newlib code having PD or BSD licenses.
> See http://cygwin.com/ml/cygwin-developers/2007-10/msg00037.html

Thanks for taking the time to actually try to do the right thing (TM).

Now your code may be based on LGPL code, but I'm sure that whoever wrote
it will not object to put it in the public domain or under a relaxed
MIT/X11-style license.  We are talking about a very small code snippet
and if relicensing helps fix some FFmpeg issue there will surely be no
opposition to relicensing.


More information about the ffmpeg-devel mailing list