On Sat, 12 Mar 2011 15:46:59 +0100 Colomban Wendling <lists....@herbesfolles.org> wrote:
> > practice, fair enough. But the way I see it, GLib could have left this > > until compile time with gutils.h: > > > > /* Define G_VA_COPY() to do the right thing for copying va_list > > variables. > > * glibconfig.h may have already defined G_VA_COPY as va_copy or > > __va_copy. */ > > #if !defined (G_VA_COPY) > > ... > I'm not sure it is really possible to check whether va_copy(), > __va_copy() (or whatever) works correctly at compile-time, since it's > not necessarily a macro. I wasn't clear. The code I quoted already is in gutils.h. That's why removing the definition from glibconfig.h works - it is possible to do this at compile time, check the file. > > I'm not convinced there is an ABI problem with -ansi here because C99 > > may be ABI compatible with ANSI C. The -ansi switch just tells the > > compiler not to allow using va_copy, it does exist in the glibc library. > Agree, the only problem here is that GLib did some checks when it was > configured and the function no longer exists in your build, but it won't > be an ABI problem. > > > Anyway, I've #undef'd G_VA_COPY from my system glibconfig.h and > > everything seems OK again, no link errors. > If you prefer I can easily add a #if NO_G_VA_COPY in the code (that > would switch to a g_strdup_vprintf()-based implementation) so somebody > wanting to build with ANSI only need to define it -- and we might could > event do this automatically at configure time. I'm not sure. I probably should raise this with the GLib team. Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel