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, bu
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
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
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) A
Hi,
Tim Prince 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 an
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.
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
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
Hi,
Tim Prince 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 an
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 convers
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.
> The libavc
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 c
Charles Wilson wrote:
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.
Next time you call shenanigans, get your facts straight first please. I
never claimed that w
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 t
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 broke
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
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
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 Wind
-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 f
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.
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.
>
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/#unsubscrib
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)?
Per
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 a
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)?
>
Perh
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)?
best regards
Diego
--
Unsubscribe i
26 matches
Mail list logo
