Hi, 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?
Regards, Nick
Le 11/03/2011 19:57, Nick Treleaven a écrit :
Hi, 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...
The only way I see we could fix this is to change the implementation of mio_printf() to use g_strdup_printf() internally, so no need for G_VA_COPY(). However, this would be a "slower" implementation (though, mio_printf() is only barely used in the tagmanager).
OTOH, the current code would work perfectly well on a C89-only system, since GLib wouldn't have found a working va_copy() implementation, so... not sure what is the right fix, and if there is one needed.
What do you think is the best?
Cheers, Colomban
On 12 March 2011 06:30, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 11/03/2011 19:57, Nick Treleaven a écrit :
Hi, 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.
Cheers Lex
The only way I see we could fix this is to change the implementation of mio_printf() to use g_strdup_printf() internally, so no need for G_VA_COPY(). However, this would be a "slower" implementation (though, mio_printf() is only barely used in the tagmanager).
OTOH, the current code would work perfectly well on a C89-only system, since GLib wouldn't have found a working va_copy() implementation, so... not sure what is the right fix, and if there is one needed.
What do you think is the best?
Cheers, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 12/03/2011 01:28, Lex Trotman a écrit :
On 12 March 2011 06:30, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 11/03/2011 19:57, Nick Treleaven a écrit :
Hi, 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.
I guess this kind of problem only apply when using a compiler flag that changes the subset of functionality supported by the compiler (e.g. -std=*).
Even things like -Werror=implicit-function-declaration (again :D) wouldn't be a problem IMO: either the library headers pass fine with it or the library has serious problems that better get fixed.
Cheers, Colomban
On 12 March 2011 11:48, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 12/03/2011 01:28, Lex Trotman a écrit :
On 12 March 2011 06:30, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 11/03/2011 19:57, Nick Treleaven a écrit :
Hi, 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.
I guess this kind of problem only apply when using a compiler flag that changes the subset of functionality supported by the compiler (e.g. -std=*).
Yep, or maybe like one of our other discussions, anything that specifies an ABI, or maybe a machine specification. If the library was made with 686 and Geany with 486 or the other way around I'm not sure what potential problems could occur.
For example my GTK is built with -pthread and -D_REENTRANT, so there is the potential for the -D_REENTRANT to change GTK headers if its not correctly applied to Geany and all plugin builds. No specification of which machine though. Hopefully such things are handled by autofools and waf.
Even things like -Werror=implicit-function-declaration (again :D) wouldn't be a problem IMO: either the library headers pass fine with it or the library has serious problems that better get fixed.
Agree. But of course if you need the library what do you do??
Cheers Lex
Cheers, Colomban
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
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 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
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
On Sat, 12 Mar 2011 15:46:59 +0100 Colomban Wendling lists.ban@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
Le 14/03/2011 14:05, Nick Treleaven a écrit :
On Sat, 12 Mar 2011 15:46:59 +0100 Colomban Wendling lists.ban@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.
In gutils.h, it says that (as in your snippet) that glibconfig might already contain a definition that expands to va_copy() or __va_copy(), the implementations in gutils.h being fallback implementations if none of the above are found. IMHO it's probably better to use the system implementation -- but maybe custom implementation as in gutils.h are as good, don't know.
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.
Yeah, that's be at least interesting to see the GLib's developers POV on this.
Cheers, Colomban