The workaround for GNOME 2.23.1 might simply be to release with gtkmm 2.12.x, since it won't bring the giomm headers in during the compilation. But that's still an issue for the future.

I guess we need to rename and deprecated the enum value in glibmm, with an #ifdefined to avoid the clash. But I'd prefer not to do that in the middle of a stable series.

Can you just #undef HOST_NOT_FOUND in gnome-system-monitor to fix its build?

(In reply to comment #2)
> I guess we need to rename and deprecated the enum value in glibmm, with an
> #ifdefined to avoid the clash. But I'd prefer not to do that in the middle of a
> stable series.

Agree with you.

> Can you just #undef HOST_NOT_FOUND in gnome-system-monitor to fix its build?

Yes, this fixes the build. I'll open a gnome-system-monitor bug to have this workaround for now in trunk. I doubt I'll get a new tarball in time for 2.23.1, so I might release with a stable gtkmm if needed. Hopefully, this will be fixed one way or another for 2.23.2.

I added HOST_WAS_NOT_FOUND in glibmm svn trunk (will be glibmm 2.18):

2008-07-25  Murray Cumming  <murrayc@murrayc.com>

	* gio/src/gio_enums.defs: Hacked in a replacement 
	enum for Gio::Error::HOST_NOT_FOUND as 
	Gio::Error::HOST_WAS_NOT_FOUND, to avoid a clash with 
	a netdb.h define.
	Bug #529496.
	* configure.in:
	* tests/Makefile.am:
	* tests/giomm_ioerror/Makefile.am:
	* tests/giomm_ioerror/main.cc: Added a test to make sure 
	that our hacked-in enum value stays hacked in.

However, I have not yet deprecated HOST_NOT_FOUND, because we currently don't document these enums at all. Which is bad: See bug 544694.

I don't think we can just remove HOST_NOT_FOUND before deprecating it for at least one version.

> I don't think we can just remove HOST_NOT_FOUND before deprecating it for at
> least one version.
> 

I see, but you cannot compile the following code:

#include <netdb.h>
#include <giomm/file.h>

int
main()
{
  Gio::File::create_for_path("");
  return 0;
}

compilation command:

g++ `pkg-config --cflags --libs giomm-2.4` test.cc -o test

error message:

/usr/include/giomm-2.4/giomm/error.h:72: error: expected identifier before numeric constant
/usr/include/giomm-2.4/giomm/error.h:72: error: expected `}' before numeric constant
/usr/include/giomm-2.4/giomm/error.h:72: error: expected unqualified-id before numeric constant
/usr/include/giomm-2.4/giomm/error.h:77: error: expected `)' before ‘error_code’
/usr/include/giomm-2.4/giomm/error.h:78: error: expected `)' before ‘*’ token
/usr/include/giomm-2.4/giomm/error.h:79: error: ‘Code’ does not name a type
/usr/include/giomm-2.4/giomm/error.h:82: error: expected unqualified-id before ‘private’
/usr/include/giomm-2.4/giomm/error.h:85: error: ‘friend’ used outside of class
/usr/include/giomm-2.4/giomm/error.h:96: error: expected declaration before ‘}’ token

Please consider, that an application which uses the stable version (2.18.x) of glibmm cannot be compiled.

Created attachment 119416 [details] [review]
possible solution of problem mentioned in comment 5

Yes, maybe that would be helpful, though the undef in the application code, mentioned above, would also solve that problem. Jonathon, what do you think?

If we want this, then I think it can go in the stable glibmm as a build fix.

well, I don't personally think that it's a good idea to apply that patch as-is since that makes us responsible for keeping the value of netdb.h's HOST_NOT_FOUND value up-to-date if they ever change it from 1 to some other value...

I suppose we could work around that by doing something like:

#ifdef	_NETDB_H
#define NETDB_HOST_NOT_FOUND HOST_NOT_FOUND
#undef HOST_NOT_FOUND
#endif

...
 
#ifdef	_NETDB_H
#define HOST_NOT_FOUND NETDB_HOST_NOT_FOUND
#undef NETDB_HOST_NOT_FOUND
#endif


This would allow the simple example above to compile since it doesn't actually use the HOST_NOT_FOUND enum value.  But any code that does attempt to use this value would still be broken.  The user would need to explicitly #undef that value.  Perhaps we could provide a gentle reminder to the user if they include a header that already defines HOST_NOT_FOUND like:

#ifdef HOST_NOT_FOUND
#warning HOST_NOT_FOUND is already defined by another header, your code may not work unless you #undef HOST_NOT_FOUND
#endif

That also makes me think that in Szilárd's patch above, we probably don't want to be keying off of the netdb.h header include guards in case those change for some reason.  We should probably use:

#ifdef HOST_NOT_FOUND

instead of 

#ifdef	_NETDB_H

Thoughts?

Yes, of course. I was not reading the patch in enough detail.

The patch was only an idea, not a absolutely correct, well designed solution. Unfortunately I didn't mention it well enough (sorry). The problems which are mentioned by Jonathon are known for me.

2008-10-04  Jonathon Jongsma  <jonathon@quotidian.org>

	* gio/src/error.hg: add a workaround for the HOST_NOT_FOUND symbol
	conflicts, as suggested by Szilárd Pfeiffer in Bug #529496
	* tests/giomm_ioerror/main.cc: add a test for this