The problem with line #46 might be a compiler bug. The following small test
program fails on the above compilers:
typedef enum {
  GNOME_VFS_FILE_INFO_DEFAULT = 0
} GnomeVFSFileInfoOptions;

enum FileInfoOptions
{
  FILE_INFO_DEFAULT = 0
};

extern "C" {
  void file_info (GnomeVFSFileInfoOptions options);
}

void
func (FileInfoOptions options) {
  file_info (static_cast<GnomeVFSFileInfoOptions>(options));
}

> "uri.cc", line 248: Error: Overloading ambiguity between
> "Glib::unwrap<Gnome::Vfs::Uri>(const Glib::RefPtr<const Gnome::Vfs::Uri>&)" and
> "Glib::unwrap<const Gnome::Vfs::Uri>(const Glib::RefPtr<const Gnome::Vfs::Uri>&)".

We experienced this already in gtkmm. Using __CONVERT_CONST_REFPTR_TO_P_SUN
instead of the normal conversion should help. For instance:
http://cvs.gnome.org/viewcvs/gtkmm/tools/m4/convert_gtk.m4?view=markup

>The problem with line #46 might be a compiler bug

Yes, probably, but you should be able to work around it by using a C-style cast.
Just add a comment in the patch saying why we are doing it, please.

Did this help?

The C-style cast works. We've already tested a patch for Studio 8 from Sun.
Haven't looked into __CONVERT_CONST_REFPTR_TO_P_SUN yet. Will try to soon.

If you could try that, it would be nice to make the change in cvs and close this bug.

Ok, will try to get to it soon. Sun should have official patches soon as well.

Some updates on these two bugs (static_cast and Glib::unwrap ambiguities):

o static_cast needs to be removed at quite a lot of other places, too. I didn't
  check if these were all enum related casts.

o The overload ambiguity bug in the Sun compiler has been filed as

  4886310 Overloading ambiguity error with usage of template function with const vector

  Unfortunately I don't have access to the bug description and activity, but it
  is supposedly fixed in the latest compiler patches. Still a workaround is
  needed for the other broken compilers as well.

o The workaround is to explicitly instantiate the function template with the
  proper argument. There seems to be another bug in the game requiring full 
  Namespace resolution. For example:

 bool Uri::equal(const Glib::RefPtr<const Uri>& uri) const
 {
-  return gnome_vfs_uri_equal(const_cast<GnomeVFSURI*>(gobj()), Glib::unwrap(uri));
+  return gnome_vfs_uri_equal(const_cast<GnomeVFSURI*>(gobj()), Glib::unwrap<Gnome::Vfs::Uri>(uri));
 }

  Perhaps some m4 conversion tricks would be able to get the template parameter
  as an argument to Glib::unwrap.

o glibmm has similar Glib::unwrap (indirect) issues, e.g. some header files need
  to explicitely instanciate the proper template, too, to assist the compiler in
  its choice.

When I get it to build on the remaining platforms, I can post a patch here, but it would be against the gtkmmproc generated files.

Created attachment 78780 [details] [review]
new unwrap_const and TypeTraits_const interfaces for broken compilers

In order to fix this bug (or work around it) I had to patch glibmm (I'm using glibmm-2.6.1). The problems are that

a) Not all broken implementations are caught by the tests for 
   GLIBMM_HAVE_DISAMBIGUOUS_CONST_TEMPLATE_SPECIALIZATIONS
b) the __CONVERT_CONST_REFPTR_TO_P_SUN method works by casting away the
   const,but that is only possible if the qualifer is at the top level type
   specification, e.g. const Uri* can be const_cast to Uri*, but RefPtr<const
   Foo> not anymore.

The tests for a) test whether the compiler can disambiguate const qualifiers in templated classes. That is needed for the TypeTraits class. But the Glib::unwrap function can still be broken, for example the DEC compiler copes well with templated classes, but not with templated functions. The tests need to probe for functions, too, or assuming that there are no implementations that have working functions, but broken classes, only test for templated functions.

In order to disambiguate Glib::unwrap for the broken compilers I resorted to renaming the function to Glib::unwrap_const for the ambiguous specialisations with const qualifiers. The compilers with proper disambiguation support have both the *_const and the normal specialization. Similar for TypeTraits.

Created attachment 78781 [details] [review]
fixes for compilers not able to disambiguate const template parms; static_cast removal for same broken compilers

After applying the previous pacth to glibmm gnomevfsmm can use the *_const interfaces. The next patch includes the following:

o changes to tools/m4/convert_gnome_vfsmm.m4 to include const_casts and
  unwrap_const. The gmmproc generated bits are not included to keep patch noise
  low.
o quite a lot of static_cast to simple C style cast changes (see comment #3)
  needed for Sun's compiler.
o explicit parameters for defining ListHandleUris including TypeTraits_const.

Using both patches allow glibmm & gnomvfsmm to build on both solaris and osf. irix fails out on a rather unfixable double-definition compiler bug.

Many thanks.

> The tests for a) test whether the compiler can disambiguate const qualifiers in
> templated classes. That is needed for the TypeTraits class. But the
> Glib::unwrap function can still be broken, for example the DEC compiler copes
> well with templated classes, but not with templated functions. The tests need
> to probe for functions, too, or assuming that there are no implementations that
> have working functions, but broken classes, only test for templated functions

I'd like to see a test for this, so we can avoid adding code that isn't necessary on other compilers. I don't see any changes to the test in these two patches.

Also, maybe I'm missing it in your text above, but I don't see why we can't just specify the template specialization (e.g. Glib::unwrap<const TheClass*>(thecppinstance)), as suggested in comment #2:
http://bugzilla.gnome.org/show_bug.cgi?id=321990#c2

(In reply to comment #11)
> > The tests for a) test whether the compiler can disambiguate const qualifiers in
> > templated classes. That is needed for the TypeTraits class. But the
> > Glib::unwrap function can still be broken, for example the DEC compiler copes
> > well with templated classes, but not with templated functions. The tests need
> > to probe for functions, too, or assuming that there are no implementations that
> > have working functions, but broken classes, only test for templated functions
> 
> I'd like to see a test for this, so we can avoid adding code that isn't
> necessary on other compilers. I don't see any changes to the test in these two
> patches.

No, there is no test in the patches sent, this was just a comment. I don't think you can avoid any code by a smarter test, the comment just says that the tests are giving false positives for DEC.

(In reply to comment #12)
> Also, maybe I'm missing it in your text above, but I don't see why we can't
> just specify the template specialization (e.g. Glib::unwrap<const
> TheClass*>(thecppinstance)), as suggested in comment #2:
> http://bugzilla.gnome.org/show_bug.cgi?id=321990#c2

See comment #9 part b)

gnome-vfsmm development has been stalled and it has been unmaintained for a few
years now.
Maintainers don't have future development plan so i am closing bugs as WONTFIX.
Please feel free to reopen the bugs in future if anyone takes the responsibility for active development.