On Sun, 14 Apr 2019, Diego Biurrun wrote:
On Sat, Apr 13, 2019 at 12:58:40AM +0300, Martin Storsjö wrote:
On Fri, 12 Apr 2019, Luca Barbato wrote:
> On 11/04/2019 15:35, Martin Storsjö wrote:
> > On Wed, 10 Apr 2019, Luca Barbato wrote:
> > > On 10/04/2019 10:48, Martin Storsjö wrote:
> > > > Mingw headers have got header inline implementations of localtime_r
> > > > and gmtime_r, but only visible if certain posix thread safe functions
> > > > have been requested.
> > > >
> > > > This is a preparatory step for improving the detection of those
> > > > functions.
> > > > ---
> > > > An alternative fix is also provided in a different patch series,
> > > > by adjusting libavutil/time_internal.h.
> > >
> > > Seems fine to me.
> >
> > Which ones do you mean - this series of 2 patches, the other one, or both?
> >
>
> This series seems fine to me.
Ok. FWIW, the change in mingw-w64 that broke it was reverted (there was a
similar issue within gcc as well), but I guess this change probably is good
to make anyway.
I generally don't think that adding workarounds for foreign bugs is a
sustainable strategy,
Well, the idea of prefixing local system function fallbacks/replacements
isn't so much of a "workaround" as a sensible idea in general IMO. This is
a pattern that already is used e.g. for ff_getaddrinfo, ff_poll etc.
That is, regardless of what the reason for using a fallback is (the real
function does not exist, the real function is declared in headers but
missing in libs, the real function exists but we want to avoid it because
it's buggy, etc), the pattern of
#include
static inline ff_systemfunc() {
...
}
#define systemfunc ff_systemfunc
should always be safe. So I think that should be a generally beneficial
change in any case as well.
but I clearly prefer the configure change.
Well, the check_func_headers change obviously is for the better, yes.
Adding the _POSIX_C_SOURCE define when building for mingw most probably
also is sensible, but the fact that we add it manually to most OSes, while
we don't add it automatically for all, makes it a little less clear cut.
Also, s/Try adding/Add/ in the log message, you're not just trying to add
those flags :-)
Right, it wasn't a check_cflags but straightforward add_cflags. Yeah, I'll
change that.
// Martin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
