[Geany-devel] G_VA_COPY problem

[Lex Trotman]

On 13 March 2011 01:46, Colomban Wendling <lists.ban at 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 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

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 at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>