[Geany-devel] G_VA_COPY problem

Colomban Wendling lists.ban at xxxxx
Sat Mar 12 14:46:59 UTC 2011


Le 12/03/2011 13:45, Nick Treleaven a écrit :
> On Sat, 12 Mar 2011 11:28:51 +1100
> Lex Trotman <elextr at 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 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.

Cheers,
Colomban



More information about the Devel mailing list