Re: llrint implementation in Cygwin
Hi, Tim Prince tprince at computer.org writes: Diego Biurrun wrote: Hi! I have noticed that Cygwin does not implement llrint. However, llrint is part of C99 and not having it available makes some applications (for example MPlayer and FFmpeg) fail to compile. Are there any plans to implement llrint (in the near future)? Perhaps if you would submit a patch to newlib, something may happen. It's not difficult to back-port stand-alone from recent gcc if you don't want to wait for cygwin to include a gcc upgrade, about which there have been plenty of threads here. You could include it in a mathinline.h of your choice. http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01970.html http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01973.html shows that it has been available for 2.5 years. I found another way: leverage the llrint() implementation in MinGW. a) We need first to download the mingw-runtime Cygwin package. b) Then we create a small library: ar x /usr/lib/mingw/libmingwex.a llrint.o ar cq /usr/local/lib/libllrint.a llrint.o c) And finally, we use that library in FFmpeg configure line: --extra-ldflags='-L /usr/local/lib' --extra-libs='-l llrint' It might not be the most elegant solution, but it is strightforward, and it works. Regards, Victor -- 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/
Re: llrint implementation in Cygwin
Victor Paesa wrote: I found another way: leverage the llrint() implementation in MinGW. a) We need first to download the mingw-runtime Cygwin package. b) Then we create a small library: ar x /usr/lib/mingw/libmingwex.a llrint.o ar cq /usr/local/lib/libllrint.a llrint.o c) And finally, we use that library in FFmpeg configure line: --extra-ldflags='-L /usr/local/lib' --extra-libs='-l llrint' It might not be the most elegant solution, but it is strightforward, and it works. This is a very, very bad idea. MinGW uses a completely different and incompatible C runtime (MSVCRT) and so any MinGW object that calls into the runtime (e.g. malloc(), open(), printf(), etc) will crash and burn hard when linked to the Cygwin runtime. It is simple blind luck that llrint() is apparently a self-contained function that has no calls to any C runtime support functions, but this is not a practical technique in general. If you want to re-use the MinGW implementation, do it by compiling the source with Cygwin's gcc, not by extracting an object from a library. Brian -- 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/
RE: llrint implementation in Cygwin
On 29 October 2007 12:28, Brian Dessent wrote: This is a very, very bad idea. MinGW uses a completely different and incompatible C runtime (MSVCRT) and so any MinGW object that calls into the runtime (e.g. malloc(), open(), printf(), etc) will crash and burn hard when linked to the Cygwin runtime. It is simple blind luck that llrint() is apparently a self-contained function that has no calls to any C runtime support functions, but this is not a practical technique in general. I don't think it was being advocated in general, but I think it's reasonable to assume that a pure const function like llrint isn't going to do anything wacky. cheers, DaveK -- Can't think of a witty .sigline today -- 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/
Re: llrint implementation in Cygwin
Dave Korn wrote: I don't think it was being advocated in general, but I think it's reasonable to assume that a pure const function like llrint isn't going to do anything wacky. Yes, I realize it was probably not a worry in this particular case, but I didn't want somebody stumbling on the archives at a later date and getting the bright idea that you could just go around extracting random objects from a MinGW library for use in a Cygwin link. Brian -- 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/
Re: llrint implementation in Cygwin
Hi,
Brian Dessent writes:
Dave Korn wrote:
I don't think it was being advocated in general, but I think it's reasonable
to assume that a pure const function like llrint isn't going to do anything
wacky.
Yes, I realize it was probably not a worry in this particular case, but
I didn't want somebody stumbling on the archives at a later date and
getting the bright idea that you could just go around extracting random
objects from a MinGW library for use in a Cygwin link.
I completely agree, most of the time it is a very bad idea to mix MinGW objects
with Cygwin's ones, that is why I extracted the llrint.o instead of linking
to libmingwex.a
And indeed llrint.o works only because it is self-contained.
I checked that at the code:
$ cat /usr/src/cygwin-1.5.24-2/winsup/mingw/mingwex/math/llrint.c
#include math.h
long long llrint (double x)
{
long long retval;
__asm__ __volatile__\
(fistpll %0 : =m (retval) : t (x) : st);
\
return retval;
}
Regards,
Victor
--
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/
Re: llrint implementation in Cygwin
Hi, Brian Dessent writes: Victor Paesa wrote: I downloaded the gcc-3.4.4 Cygwin source package, and I found that (apparently) gcc 3.4.4 already had llrint built-in: [skipped nice detailed explanation on how builtins work] Thanks! [...] So even if it did have a __builtin_llrint, you would not be able to use it any non-trivial manner. [ Also note that you did not invoke gcc with optimization above, which I'm pretty sure means it won't even consider using optimized builtins. ] I tried with gcc 4.4.2. If I understood correctly the Changelog, this one implements llrint(). It compiled out of the box, but indeed I wasn't able to use the __builtin_llrint (tried -O2, -O3, -ffast-math, -finline-functions to no avail). Could that be fixed by adding/removing flags to the configure line used to build gcc 3.4.4 in Cygwin? No what needs to be done is add llrint to newlib. A builtin is not a suitable replacement. Since the builtin way is a dead end, I wonder how is the future Cygwin gcc suposed to bring llrint(). Will it use the mathinline.h approach or will it patch newlib? (since the thread is a bit overheated: please understand it as a technical question, no trolling intended). Thanks in advance for your answer, Victor P.S. Sorry if Gmane is breaking the thread, I tried [EMAIL PROTECTED] but it didn't worked. -- 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/
RE: llrint implementation in Cygwin
On 28 October 2007 09:35, Victor Paesa wrote: P.S. Sorry if Gmane is breaking the thread, I tried cygwin-get.556 but it didn't worked. You're getting the number wrong, it should be somewhere in the 137000 range. Take a look at the message for the Original-X-From: and Return-path: headers. cheers, DaveK -- Can't think of a witty .sigline today -- 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/
Re: llrint implementation in Cygwin
Hi,
Tim Prince tprince at computer.org writes:
Diego Biurrun wrote:
Hi!
I have noticed that Cygwin does not implement llrint. However, llrint
is part of C99 and not having it available makes some applications (for
example MPlayer and FFmpeg) fail to compile.
Are there any plans to implement llrint (in the near future)?
Perhaps if you would submit a patch to newlib, something may happen.
It's not difficult to back-port stand-alone from recent gcc if you don't
want to wait for cygwin to include a gcc upgrade, about which there have
been plenty of threads here. You could include it in a mathinline.h
of your choice.
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01970.html
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01973.html
shows that it has been available for 2.5 years.
I downloaded the gcc-3.4.4 Cygwin source package, and I found that (apparently)
gcc 3.4.4 already had llrint built-in:
$ fgrep -ri llrint gcc-3.4.4
gcc-3.4.4/gcc/builtins.c: CASE_MATHFN (BUILT_IN_LLRINT)
gcc-3.4.4/gcc/builtins.def:DEF_C99_BUILTIN(BUILT_IN_LLRINT, llrint,
BT_FN_LONGLONG_DOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
[more lines matched]
Then I tried to compile a test:
$ cat llrint_test.c
#include math.h
int main(int argc, char **argv)
{
long long ll;
ll = __builtin_llrint(2.34);
}
But the compilation failed:
$ gcc llrint_test.c
/cygdrive/c/DOCUME~1/Inma/LOCALS~1/Temp/ccyDtvBd.o:llrint_test.c:(.text+0x34):
undefined reference to `_llrint'
collect2: ld returned 1 exit status
Are built-ins disabled in gcc-3.4.4 for Cygwin?
Could that be fixed by adding/removing flags to the configure line used
to build gcc 3.4.4 in Cygwin?
Thanks in advance for your answers,
Victor Paesa
--
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/
Re: llrint implementation in Cygwin
Victor Paesa wrote:
I downloaded the gcc-3.4.4 Cygwin source package, and I found that
(apparently)
gcc 3.4.4 already had llrint built-in:
A builtin in gcc has a specific meaning, and it does not mean that the
compiler provides a full implementation of that function. What it means
is that the compiler knows how to optimize certain special cases of that
function, such as it knows it can replace strlen(foo) with 3 because
it can see that foo has length 3 at compile time. But the key here is
that for all builtins that have the same name as standard C functions,
the compiler assumes that there is a corresponding library
implementation of the function that can always be called as a fallback
if the limited builtin cannot suffice or if there is no chance of any
optimization possible.
[ There are many other types of builtins besides those that
mirror/parallel the standard C library functions. Some implement
magic things like __builtin_expect, __builtin_apply_args, or
__builtin_return_address; some expose processor features directly like
__sync_lock_test_and_set, etc. ]
$ fgrep -ri llrint gcc-3.4.4
gcc-3.4.4/gcc/builtins.c: CASE_MATHFN (BUILT_IN_LLRINT)
gcc-3.4.4/gcc/builtins.def:DEF_C99_BUILTIN(BUILT_IN_LLRINT, llrint,
BT_FN_LONGLONG_DOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
What you see here is the machinery to support llrint as a builtin, but
it's not actually implemented anywhere. Note that in
builtins.c:expand_builtin(), there is no case statement to handle
BUILT_IN_LLRINT{,F,L} and so the switch falls through to the bottom of
the function which contains:
/* The switch statement above can drop through to cause the function
to be called normally. */
return expand_call (exp, target, ignore);
This simply means that it punts and calls the library version of the
function, which is exactly what you see below -- except that
Cygwin/newlib does not provide a library version of this function.
$ cat llrint_test.c
#include math.h
int main(int argc, char **argv)
{
long long ll;
ll = __builtin_llrint(2.34);
}
But the compilation failed:
$ gcc llrint_test.c
/cygdrive/c/DOCUME~1/Inma/LOCALS~1/Temp/ccyDtvBd.o:llrint_test.c:(.text+0x34):
undefined reference to `_llrint'
collect2: ld returned 1 exit status
Are built-ins disabled in gcc-3.4.4 for Cygwin?
No, they're not disabled, it's just that there's no implementation of
__builtin_llrint in this version of gcc, though there is plumbing for
it. But even if there were a builtin, it would not be a full
replacement for llrint, because again builtins are meant to mirror the
library implementations in situations where the compiler has a clear
chance of optimizing something away (such as when you call it with a
constant), not replace the library version as a general purpose
implementation. So even if it did have a __builtin_llrint, you would
not be able to use it any non-trivial manner.
[ Also note that you did not invoke gcc with optimization above, which
I'm pretty sure means it won't even consider using optimized builtins. ]
Could that be fixed by adding/removing flags to the configure line used
to build gcc 3.4.4 in Cygwin?
No what needs to be done is add llrint to newlib. A builtin is not a
suitable replacement.
Brian
--
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/
Re: llrint implementation in Cygwin
Charles Wilson wrote:
Diego Biurrun wrote:
Next time you call shenanigans, get your facts straight first please.
I never claimed that we do not *have* OS-specific workarounds, I said
we do not *add* them.
That's a vey fine distinction and was not at all clear from the
foregoing conversation.
Maybe I was not terribly clear nor explicit. That does not preclude you
from stating your points a little more, umm, defensively, does it?
The libavcodec directory has entirely separate
subdirs for different processors -- platform specificity is BUILT IN
to the ffmpeg source tree.
Nonsense. These are assembler optimizations for speed-critical
functions (and the reason why you can watch movies without GHz CPUs).
These are, by their very nature, processor-specific, but they are not
workarounds. Nothing could be further from the truth.
It's an example of special purpose (blocks of) code, where a given block
is compiled only under particular circumstances -- e.g. for a specific
target cpu -- in pursuit of a particular goal. In this case: speed.
Control flow (whether a particular file or block of code is actually
compiled for a given target) is determined by...for lack of a better
term, makefile magic.
No, I'm not letting you off the hook here, you are still talking nonsense.
That file ALSO contains a
half-dozen implementations of read_time depending on which
microprocessor architecture is in use.
What does this have to do with a workaround? read_time is internally
used in some benchmarking macros, it is not an OS function.
It's an exampleof special purpose (blocks of) code, where a given block
is compiled only under particular circumstances -- e.g. for a specific
target cpu -- in pursuit of a particular goal. In this case: high res
benchmarking. Control flow (whether a particular file or block of code
is actually compiled for a given target) is determined by...using the
earlier nomenclature, ifdef magic.
.. and nonsense again ..
What are you going to claim next? That something like
if ( condition )
block of code
else
block of alternative code
is an example of special purpose (blocks of) code where given block is
run only under particular circumstances in pursuit of a particular goal
using control flow magic?
Oh, and lookee here, in the same file:
#ifndef HAVE_LRINTF
/* XXX: add ISOC specific test to avoid specific BSD testing. */
/* better than nothing implementation. */
/* btw, rintf() is existing on fbsd too -- alex */
static av_always_inline long int lrintf(float x)
{
return (int)(rint(x));
}
#endif /* HAVE_LRINTF */
Good catch, this is cruft from ages ago. I will look into nuking this
very soon.
So, I find an example of EXACTLY the sort of feature-dependent
workaround under discussion, and your response is no, that's not a
valid example...and if it is, we'll get rid of it?
You have an interesting way of twisting words. I say good catch and
you translate this to no, that's not a valid example.
It's doubly interesting that I admit you are right and you turn this
around into me being in denial while at the same time you are in denial
about the points where I proved you wrong.
Look, the point is: there are many platforms out there that do not
support the entire panoply of C99 functions. Or even all POSIX (1b? 1c?
1e? 2?) functions.
Yes. And if every program out there tries to be portable to those
platforms by adding workarounds to their codebase we will soon have
terabytes of cruft and bugs all over the place.
Then again, if just one of them goes to the length of patching upstream
instead of hacking their code, all those programs will suddenly work on
that platform.
Short term pain, long term gain, it boils down to nothing more than that...
If the FFMpeg team cares about portability, the
correct answer is not to climb upon a high horse, declaim we do not
[use|add] platform-specific workarounds and deliberately release code
that is /not/ portable to the disdained platform -- and then blame that
platform for not updating their runtime library according to /your/
project's release schedule. Well, cygwin will just have to be broken
You are (again) putting words into my mouth and twisting what I said.
I never
- expressed disdain for Cygwin nor
- blamed Cygwin for not updating their runtime library nor
- forced our release schedule on anybody.
I merely enquired whether
- an implementation of llrint was in the works and
- when it would hit mainstream Cygwin.
This was done so that I could add an appropriate comment into the
release notes about the status of Cygwin support. Heck, if the answer
had been something along the lines of We'll have it next month or
similar, we might even have delayed *our* release to accomodate this.
Now if somebody inquires about the status of Cygwin compilation I can
advise them to either (in order of preference)
- patch newlib or
- upgrade their gcc somehow or
- wait for
Re: llrint implementation in Cygwin
Diego Biurrun wrote: [...] So all in all you have refuted some points I never made, while bungling some of the research used to substantiate your claims. What is the point you are trying to prove here? To be a bit more precise and constructive: We have had workarounds of all sorts in the codebase but have been working hard to eliminate them, especially over the last year or so. To achieve this we have put an embargo on new workarounds, whatever gets freshly added has to be minimally intrusive and strictly based on feature checks, not on OS checks, version checks and similar things. best regards 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/
Re: llrint implementation in Cygwin
Igor Peshansky wrote:
On Fri, 28 Sep 2007, Diego Biurrun wrote:
Tim Prince wrote:
Diego Biurrun wrote:
I have noticed that Cygwin does not implement llrint. However,
llrint is part of C99 and not having it available makes some
applications (for example MPlayer and FFmpeg) fail to compile.
Are there any plans to implement llrint (in the near future)?
Perhaps if you would submit a patch to newlib, something may happen.
Telling me what newlib is would greatly help in this regard :-)
Newlib is the library that Cygwin uses for some standard functions (math
and otherwise).
(The only way to interpret this question is what is the connection
between newlib and Cygwin, as a quick Google would have pointed you to
the newlib webpage).
Yes, I was not precise. I was unsure about the relationship between
Cygwin and newlib.
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.
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.
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/
Re: llrint implementation in Cygwin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Diego Biurrun on 9/29/2007 1:14 PM:
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.
What part of portable programming don't you get? On platforms where
something is lacking, a portable program will use replacement functions to
make up for the platform limitations (autoconf is particularly helpful in
determining whether a platform has limitations so the replacement is not
used on platforms with more features, and gnulib is a good supply of a lot
of replacement functions).
And what part of open source programming don't you get? If it bugs you,
write and submit a patch, so that cygwin WILL have llrint. Cygwin won't
have it until someone takes the time to write it.
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG/qkZ84KuGfSFAYARAuigAKCphfivrZirq6b8iJRaz13E/1XtIwCfQjti
8a7jKJGuYocaMLl3iSfDluA=
=dk7b
-END PGP SIGNATURE-
--
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/
Re: llrint implementation in Cygwin
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...
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.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!)
|,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert
--
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/
Re: llrint implementation in Cygwin
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/
Re: llrint implementation in Cygwin
On Sat, Sep 29, 2007 at 10:20:23PM +0200, Diego Biurrun wrote: llrint is required, so I guess Cygwin compilation will indeed be broken for a while. We don't add OS-specific workarounds to FFmpeg. So what other kinds of workarounds do you add? cgf -- 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/
Re: llrint implementation in Cygwin
Christopher Faylor wrote: On Sat, Sep 29, 2007 at 10:20:23PM +0200, Diego Biurrun wrote: llrint is required, so I guess Cygwin compilation will indeed be broken for a while. We don't add OS-specific workarounds to FFmpeg. So what other kinds of workarounds do you add? Workarounds for broken variants of the many multimedia formats we support for example. 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/
Re: llrint implementation in Cygwin
Diego Biurrun wrote:
llrint is required, so I guess Cygwin compilation will indeed be broken
for a while. We don't add OS-specific workarounds to FFmpeg.
I call shenanigans. The libavcodec directory has entirely separate
subdirs for different processors -- platform specificity is BUILT IN to
the ffmpeg source tree. Second, common.h contains compiler-specific
workarounds:
#ifndef av_always_inline
#if defined(__GNUC__) (__GNUC__ 3 || __GNUC__ == 3
__GNUC_MINOR__ 0)
#define av_always_inline __attribute__((always_inline)) inline
#else
#define av_always_inline inline
#endif
#endif
to account for gcc-specific behavior. That file ALSO contains a
half-dozen implementations of read_time depending on which
microprocessor architecture is in use.
internal.h has this:
// Use rip-relative addressing if compiling PIC code on x86-64.
#if defined(__MINGW32__) || defined(__CYGWIN__) || \
defined(__OS2__) || (defined (__OpenBSD__) !defined(__ELF__))
#if defined(ARCH_X86_64) defined(PIC)
#define MANGLE(a) _ #a(%%rip)
#else
#define MANGLE(a) _ #a
#endif
#else
#if defined(ARCH_X86_64) defined(PIC)
#define MANGLE(a) #a(%%rip)
#elif defined(__APPLE__)
#define MANGLE(a) _ #a
#else
#define MANGLE(a) #a
#endif
#endif
which looks pretty darn OS-specific to me. (__CYGWIN__? __MINGW32__?
__OS2__?)
Oh, and lookee here, in the same file:
#ifndef HAVE_LRINTF
/* XXX: add ISOC specific test to avoid specific BSD testing. */
/* better than nothing implementation. */
/* btw, rintf() is existing on fbsd too -- alex */
static av_always_inline long int lrintf(float x)
{
return (int)(rint(x));
}
#endif /* HAVE_LRINTF */
a replacement function lrintf() that is activated only when a configure
test determines that lrintf doesn't exist and therefore neglects to
define HAVE_LRINTF
So, we have:
architecture-specific workarounds
compiler-specific workarounds
OS-specific workarounds
AND capability-specific (!HAVE_FOO) workarounds
All god's chillins gots workaround code. We don't add OS-specific
workarounds, indeed...
--
Chuck
--
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/
Re: llrint implementation in Cygwin
On Fri, 28 Sep 2007, Diego Biurrun wrote:
Tim Prince wrote:
Diego Biurrun wrote:
I have noticed that Cygwin does not implement llrint. However,
llrint is part of C99 and not having it available makes some
applications (for example MPlayer and FFmpeg) fail to compile.
Are there any plans to implement llrint (in the near future)?
Perhaps if you would submit a patch to newlib, something may happen.
Telling me what newlib is would greatly help in this regard :-)
Newlib is the library that Cygwin uses for some standard functions (math
and otherwise).
(The only way to interpret this question is what is the connection
between newlib and Cygwin, as a quick Google would have pointed you to
the newlib webpage).
It's not difficult to back-port stand-alone from recent gcc if you
don't want to wait for cygwin to include a gcc upgrade, about which
there have been plenty of threads here.
Do I understand correctly that Cygwin will provide llrint with the next
gcc upgrade?
Yes, but it won't happen for a while.
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.
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(...) { ... }
)?
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!)
|,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert
--
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/
Re: llrint implementation in Cygwin
Diego Biurrun wrote: Perhaps if you would submit a patch to newlib, something may happen. Telling me what newlib is would greatly help in this regard :-) The first Google result for 'newlib' is: http://sourceware.org/newlib/ -- 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/
Re: llrint implementation in Cygwin
Tim Prince wrote: Diego Biurrun wrote: I have noticed that Cygwin does not implement llrint. However, llrint is part of C99 and not having it available makes some applications (for example MPlayer and FFmpeg) fail to compile. Are there any plans to implement llrint (in the near future)? Perhaps if you would submit a patch to newlib, something may happen. Telling me what newlib is would greatly help in this regard :-) It's not difficult to back-port stand-alone from recent gcc if you don't want to wait for cygwin to include a gcc upgrade, about which there have been plenty of threads here. Do I understand correctly that Cygwin will provide llrint with the next gcc upgrade? 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. 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. TIA 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/
Re: llrint implementation in Cygwin
Diego Biurrun wrote: Hi! I have noticed that Cygwin does not implement llrint. However, llrint is part of C99 and not having it available makes some applications (for example MPlayer and FFmpeg) fail to compile. Are there any plans to implement llrint (in the near future)? Perhaps if you would submit a patch to newlib, something may happen. It's not difficult to back-port stand-alone from recent gcc if you don't want to wait for cygwin to include a gcc upgrade, about which there have been plenty of threads here. You could include it in a mathinline.h of your choice. http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01970.html http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01973.html shows that it has been available for 2.5 years. The x87 code quoted there appears to be SSE3. -- 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/
Re: llrint implementation in Cygwin
Tim Prince wrote: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01970.html http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01973.html shows that it has been available for 2.5 years. The x87 code quoted there appears to be SSE3. I apologize and retract the SSE3 remark. It should work on any cygwin platform. -- 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/
