On Tue, Oct 17, 2017 at 11:36:03PM -0300, James Almer wrote: > On 10/17/2017 10:22 PM, Diego Biurrun wrote: > > A private fallback roundf() implementation is not worth the trouble > > for a fringe feature like libxvid encoding. > > Removing libxvid support from every MSVC <= 2012 build (and maybe also > other compilers) to save six lines in an internal header seems a bit > unjustified...
Thanks for reminding me which version of MSVC is the sensible one. :) MS is now distributing them free of charge, so is there any good reason not to just use a sensible version? The roundf fallback was added in 2007, probably for some BSD flavor or some similar fringe thing. The BSDs eventually improved and started fixing their libcs' POSIX capabilities instead of (literally) patching all applications. I doubt any platform we still care about lacks roundf. Mind you, I care little about this patch and will just drop it. At some point I think we should just get rid of all this fallback cruft and just require a POSIX-compatible system. > And i don't know if you're aware that the scene of xvid rips is > (inexplicably) still alive. But what do they use for encoding? I expect it would be the libxvid encoder itself. > > --- a/configure > > +++ b/configure > > @@ -2388,7 +2388,7 @@ libx262_encoder_deps="libx262" > > libx264_encoder_deps="libx264" > > libx265_encoder_deps="libx265" > > libxavs_encoder_deps="libxavs" > > -libxvid_encoder_deps="libxvid mkstemp" > > +libxvid_encoder_deps="libxvid mkstemp roundf" > > Wouldn't this keep libxvid enabled (thus libavcodec linking to it)? Not since I overhauled the link dependency handling :-))) Diego _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
