After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 692134 - Name collision with w32 API headers
Name collision with w32 API headers
Status: RESOLVED FIXED
Product: libsoup
Classification: Core
Component: API
2.41.x
Other Windows
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
: 696354 696509 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-01-20 13:49 UTC by LRN
Modified: 2013-04-19 14:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
win32: Undefine conflicting 'interface' (858 bytes, patch)
2013-03-25 13:44 UTC, Kalev Lember
none Details | Review

Description LRN 2013-01-20 13:49:45 UTC
CC       soup-cache.lo
F:/sbuild.14/src/mingw/libsoup-2.4-2.41.4-1/libsoup-2.41.4/libsoup/soup-cache.c:53:79: error: expected ';', ',' or ')' before 'struct'
F:/sbuild.14/src/mingw/libsoup-2.4-2.41.4-1/libsoup-2.41.4/libsoup/soup-cache.c: In function 'soup_cache_get_type':
F:/sbuild.14/src/mingw/libsoup-2.4-2.41.4-1/libsoup-2.41.4/libsoup/soup-cache.c:129:1: error: 'soup_cache_content_processor_init' undeclared (first use in this function)
F:/sbuild.14/src/mingw/libsoup-2.4-2.41.4-1/libsoup-2.41.4/libsoup/soup-cache.c:129:1: note: each undeclared identifier is reported only once for each function it appears in
F:/sbuild.14/src/mingw/libsoup-2.4-2.41.4-1/libsoup-2.41.4/libsoup/soup-cache.c: At top level:
F:/sbuild.14/src/mingw/libsoup-2.4-2.41.4-1/libsoup-2.41.4/libsoup/soup-cache.c:875:1: warning: 'soup_cache_content_processor_init' defined but not used [-Wunused-function]

Why? Because basetyps.h (one of the core W32 API headers) does this:
# define _COM_interface	struct
# ifndef __OBJC__
#  define interface	_COM_interface
# endif

which turns the prototype into:

static void soup_cache_content_processor_init (SoupContentProcessorInterface *struct, gpointer interface_data);

and gcc freaks out.

How to fix: don't use "interface" as argument name. EVER.
Comment 1 LRN 2013-01-20 15:10:59 UTC
This also affects soup-content-decoder.c , soup-content-processor.c and soup-content-sniffer.c
Comment 2 Dan Winship 2013-01-20 17:26:33 UTC
(In reply to comment #0)
> How to fix: don't use "interface" as argument name. EVER.

The problem with this is that no one who hacks on libsoup ever builds it on Windows, so this *will* get broken again. Case in point, it was fixed once before (http://git.gnome.org/browse/libsoup/commit/?id=916ccf31), and now it's broken again.

I think we want to bring back "#undef interface" or equivalent... It seems like if it was moved to after the ws2tcpip.h include that it might work.

Or alternatively, looking at my basetyps.h (from mingw32-headers-2.0.999-0.15.trunk.20121110.fc18.noarch), I see:

  #if defined(__cplusplus) && !defined(CINTERFACE)

  #ifndef __OBJC__
  #undef interface
  #define interface struct
  #endif

So what happens if you add

  #define CINTERFACE

before the winsock include in libsoup/soup-portability.h?
Comment 3 Dan Winship 2013-03-25 13:07:02 UTC
*** Bug 696354 has been marked as a duplicate of this bug. ***
Comment 4 Dan Winship 2013-03-25 13:07:44 UTC
*** Bug 696509 has been marked as a duplicate of this bug. ***
Comment 5 Kalev Lember 2013-03-25 13:44:27 UTC
Created attachment 239765 [details] [review]
win32: Undefine conflicting 'interface'

This has been fixed in libsoup before, but keeps creeping back in. This
time, instead of renaming the conflicting symbols in libsoup once more,
we'll just undefine it after the win32 header includes.
Comment 6 Dan Winship 2013-04-03 16:35:52 UTC
thanks, fixed in master
Comment 7 Dan Winship 2013-04-03 16:36:46 UTC
wrong bug...
Comment 8 Dan Winship 2013-04-03 16:41:49 UTC
Comment on attachment 239765 [details] [review]
win32: Undefine conflicting 'interface'

>+/* remove conflicting defines from win32 headers */
>+#undef interface

bug 656402 said:

> However, due to a recent
> change in the mingw-w64 toolchain this #undef causes more breakage while
> #include'ing other Win32 headers.

Is that still a problem if we just re-undef interface again?
Comment 9 Kalev Lember 2013-04-03 17:18:12 UTC
I am not an expert here -- but I guess it could cause some trouble because <libsoup/soup-portability.h> is a public header, and apps that include libsoup headers probably don't expect it to #undef stuff.

Maybe something like this would break (untested):

#include <libsoup/soup.h>
#include <winsock2.h>
Comment 10 Erik van Pienbroek 2013-04-03 17:22:35 UTC
If you #undef interface then it will cause breakage when other Win32 API headers are #included after the #undef as can be illustrated with this minimal testcase:

#include <rpc.h>
#undef interface
#include <vmr9.h>

This results in failures like:

In file included from test.c:3:0:
/usr/i686-w64-mingw32/sys-root/mingw/include/vmr9.h:204:5: error: unknown type name 'IDirect3DSurface9'
     IDirect3DSurface9 *lpSurf;
     ^

Therefore I don't think #undef interface is a good solution as I already mentioned back in 2011 in bug 656402
Comment 11 Dan Winship 2013-04-19 14:02:30 UTC
OK, I've reorganized things so that libsoup itself no longer uses
soup-portability.h at all. (The public headers don't include any
networking headers, and the .c files that need them now include
gio/gnetworking.h, which has the "#undef interface" hack.)