Igor Peshansky wrote:
On Sat, 29 Sep 2007, Diego Biurrun wrote:
Igor Peshansky wrote:
On Fri, 28 Sep 2007, Diego Biurrun wrote:
I understand that adding llrint to Cygwin is probably not hard at
all for somebody familiar with Cygwin. However, I am not such a
person and I don't even have a Windows environment around to test
any modifications I might make.
Cygwin uses newlib as-is for most such functionality. So, patching
newlib to include llrint would automatically make Cygwin support it.
Also, newlib builds on Linux just as well as it does on Windows...
OK, that's useful information, thank you. In the unlikely event that I
find some time to dedicate to this I might actually be motivated to have
a go at this.
We are about to make an MPlayer release and unfortunately it will
not compile on Cygwin due to the missing llrint. I would appreciate
to know if this is going to get addressed so that I can put an
appropriate comment in the release notes.
What's wrong with adding llrint to your code (perhaps with a #define,
i.e.,
#define llrint my_llrint
typeof(llrint) my_llrint(...) { ... }
)?
It is ugly and it is a workaround for a problem that should be solved
outside of FFmpeg. Should every project using llrint add that
workaround? No, Cygwin should be fixed.
Fair enough. I agree that it's ugly, but ultimately it's your call --
whether you want your project to compile on Cygwin or whether you want to
require the feature that's missing and accept that Cygwin compilation will
be broken for a while.
llrint is required, so I guess Cygwin compilation will indeed be broken
for a while. We don't add OS-specific workarounds to FFmpeg.
Diego
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
