On 13 March 2011 01:46, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 12/03/2011 13:45, Nick Treleaven a écrit :
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
Same here, what I meant by binary packages was from the distro, so we don't control the compile flags. Although not with GTK, my 64 bit machine still gets occasional issues with headers that assume things are 32 bits, but since they give compile warnings I've never got to an ABI problem.
Probably you should do the ansi test on a platform where everything is ansi, but I'm afraid I can't suggest one :-( In the interim hacking your glib header just for the test is one solution if you are careful.
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 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'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.
If configure can work out the right thing, and use that to choose the implementation, thats really the most portable solution.
Cheers Lex
Cheers, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel