On Sat, 12 Mar 2011 11:28:51 +1100 Lex Trotman elextr@gmail.com wrote:
tagmanager/mio/mio-memory.c uses G_VA_COPY() but on my system this is defined as va_copy() (by glibconfig.h, I think).
When I compile with my usual flags including warnings and -ansi, va_copy is not defined. Any ideas how to solve this?
It seems to be a GLib issue that may be solved in newer versions - I still have glib2-2.14.4-1.fc8. Is anyone else using -ansi?
Hum, that's problematic, right... This problem still happens with GLib 2.28. However, it may be quite hard to fix in the GLib side: they find the proper implementation at configure time, and if none found fallback to manual copy (implementation depends on the target then). The problem is that GLib has been built without -ansi on your system and found a working va_copy, but -ansi disabled it a compile-time...
Ouch nasty, raises the point that maybe we shouldn't be building the application with different compile flags to the major binary libraries, there ciould be other potential problems.
Personally I've never built GLib or GTK and just use my distro packages. But I do need to test that Geany builds with ANSI C for portability. So far there hasn't been a problem. If this really is bad 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 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.
Anyway, I've #undef'd G_VA_COPY from my system glibconfig.h and everything seems OK again, no link errors.
Regards, Nick