On Sat, Sep 19, 2015 at 2:13 PM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > On Sat, Sep 19, 2015 at 6:07 PM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote: >> On Thu, Sep 17, 2015 at 6:45 AM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote: >>> On Thu, Sep 17, 2015 at 4:54 AM, Clément Bœsch <u...@pkh.me> wrote: >>>> On Wed, Sep 16, 2015 at 06:55:39PM -0400, Ganesh Ajjanagadde wrote: >>>>> Glibc 2.20 onwards generates a deprecation warning for usage of >>>>> _BSD_SOURCE and _SVID_SOURCE. >>>>> The solution from man feature_test_macros is to define both >>>>> _DEFAULT_SOURCE and the old macros. >>>>> This change is done in configure while testing for Glibc. Doing it in >>>>> source code >>>>> would require __UCLIBC__ checks, etc since uclibc also defines __GLIBC__ >>>>> and __GLIBC_MINOR__, >>>>> so placing it in configure avoids the repeated checks. >>>>> >>>>> Signed-off-by: Ganesh Ajjanagadde <gajjanaga...@gmail.com> >>>>> --- >>>>> configure | 6 ++++++ >>>>> libavformat/os_support.c | 1 - >>>>> 2 files changed, 6 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/configure b/configure >>>>> index cd6f629..0cd0a6c 100755 >>>>> --- a/configure >>>>> +++ b/configure >>>>> @@ -4520,6 +4520,12 @@ probe_libc(){ >>>>> elif check_${pfx}cpp_condition features.h "defined __GLIBC__"; then >>>>> eval ${pfx}libc_type=glibc >>>>> add_${pfx}cppflags -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 >>>>> + # define _DEFAULT_SOURCE for glibc 2.20 onwards to silence >>>>> deprecation >>>>> + # warnings for _BSD_SOURCE and _SVID_SOURCE. >>>>> + if check_${pfx}cpp_condition features.h "(__GLIBC__ == 2 && >>>>> __GLIBC_MINOR__ >= 20) \ >>>>> + || (__GLIBC__ > 2)"; then >>>>> + add_${pfx}cppflags -D_DEFAULT_SOURCE >>>>> + fi >>>> >>>> Is this adding _DEFAULT_SOURCE to every compiled file while it was scope >>>> to a standalone source file before? >>> >>> Don't know exactly what you mean, but try e.g strings on any of these >>> objects. There is no "DEFAULT_SOURCE", "BSD_SOURCE", or any such thing >>> suggesting they are optimized out. Furthermore, a du on the libav* >>> does not reveal any increase in size. >> >> ping > > I agree with Clément, adding a global define to every single file > while it was contained to a handful of select files before seems less > than ideal.
Like I said, it causes no visible change in the result. One could add it to the specific files. However, think about the future: it is very easy to miss adding this, and warnings may be triggered in the future at any point if a dev uses the BSD, SVID, etc forgetting the DEFAULT. Who knows what glibc would do 3 releases down, when the deprecation becomes an actual error. I think FFmpeg devs should have better things to do in future than agonizing over some ugly glibc thing that is introduced for god knows what reason. In light of that I wanted to create a "fire and forget" solution which is global in character. This achieves this at no performance penalty and practically speaking no symbol problems. We already have a bunch of global things, see e.g the -DZLIB, etc - they are certainly not needed everywhere and your argument would apply to them as well. If this was required in just a single file, I would agree with you. However, it shows up in multiple places (IIRC at least 3). Anyway, if you (or others) still feel that way about it, I will change the patch. > > - Hendrik > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel