<tim> hrm, it seems related to glibc having been compiled with _FORTIFY_SOURCE=2 or something
<tim> you could try modifying gst/printf/gst-printf.h to #undef HAVE_SNPRINTF then it might take a different code path
<ds> hrm, ok
<tim> not sure I understand the complaint yet
<ds> that does work around the problem
<tim> not sure if there's anything else we can do
<ds> I can't see how any libc function is called with %n
<tim> vasnprintf.c line 662
<tim> aiui it will do "%whatever%n", arg, &len  to determine the length
<tim> if HAVE_SNPRINTF is not defined, it will do a home-grown method to determine the max length

Well, let's do this then. I don't think there's much else we can do:

 commit 91c42b938001bfd68acb6af951603cebc1bea75b
 Author: Tim-Philipp Müller <tim@centricular.net>
 Date:   Sun Apr 14 11:23:10 2013 +0100

    printf: use sprintf() to work around glibc complaining about %n in a writable format string
    
    Don't use snprintf(), but use sprintf instead and do our own
    length calculations, because glibc may complain about us passing
    %n in a format string if the string is in writable memory, and
    here the format string is always in writable memory since we
    construct it on the fly. This happens if glibc has been compiled
    with _FORTIFY_SOURCE=2, which seems to be the case on some
    distros/systems). On the upside, we now use the sprintf code path
    on all systems which should be better from a maintenance point
    of view.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=697970