RE: [gtkmm] Building under Solaris



> From: James Overly [mailto:joverly head cfa harvard edu] 
> Sorry to bother you again.

No problem. Keep asking.

> But after trying several things 
> including downloading the from the CVS repositary so I could 
> build with 
> --enable-maintainer-mode (from running autogen.sh) I guess 
> I'm still not sure what I need to do. 
> 
> I saw the fixes in tools/m4/convert_*.m4 for the Forte compiler.

Yes. I thought that you might need some similar fixes in there. But please
see my suggestions below, after the compile errors.

I would also like you to try gtkmm 2.0.2, because this is the last version
that I know to work with the SUN compiler. Please tell me if you see the
same compile error.

You have a newer version of the compiler, and it is possible that it has new
problems. gtkmm 1.3.26 had some extra workarounds that were needed before
the SUN compiler was fixed. You might try that version as well, to give us
some information.

> If you could give me another hint I would be very greatful. It 
> seems the the mail archives don't have some of the necessary 
> posts anymore as the only serious mention is from June 2003. 
> (the arcive only goes back to June 2002)

These bugzilla queries (searches for "SUN") might also be interesting:
http://makeashorterlink.com/?R11A227D6
http://makeashorterlink.com/?P22A317D6

> > Yes, I recent versions of gtkmm 2.2 do not seem to build with the 
> > Forte compliler, but I don't believe that it would be difficult to 
> > fix. This is what I said last time somebody mentioned it: 
> > http://marc.theaimsgroup.com/?l=gtkmm&m=105698812406958&w=2
> > 
> > In this case, it just looks like you need to specify a particualr 
> > tempate instantiation. You might find similar stuff in the 
> .m4 files, 
> > with "SUN" comments, or you should find lots in the mailing list 
> > archives.

> > > I am having a problem building with the Solaris compilers
> > > I have read the README.sun file and I am still having problems.
> > > 
> > > The patch level of the compiler is newer then required:
> > > 
> > > CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-11 2002/10/31
> > > 
> > > the errors are like:
> > > -I/proj/port_ots/CXCDS_ROOT_SOLARIS8/ots/gtk2/lib/glib-2.0/inc
> > > lude -mt -I/proj/ 
> > > port_ots/CXCDS_ROOT_SOLARIS8/ots/gtk2/include/glib-2.0 
> > > -I/proj/port_ots/CXCDS_RO 
> > > OT_SOLARIS8/ots/gtk2/lib/glib-2.0/include 
> > > -I/proj/port_ots/CXCDS_ROOT_SOLARIS8/o
> > > ts/gtk2/include -g -c context.cc  -KPIC -DPIC -o 
> > > .libs/context.o "../../glib/glibmm/arrayhandle.h", line 184: 
> > > Error: Ambiguous partial specializa tion for 
> > > Glib::Container_Helpers::TypeTraits<Glib::RefPtr<Pango::FontFa
> > > ce>>, Gli b::Container_Helpers::TypeTraits and
> > > Glib::Container_Helpers::TypeTraits.
> > > "../../glib/glibmm/arrayhandle.h", line 184: Error: Ambiguous
> > > partial specializa tion for 
> > > Glib::Container_Helpers::TypeTraits<Glib::RefPtr<Pango::FontFa
> > > mily>>, G lib::Container_Helpers::TypeTraits and
> > > Glib::Container_Helpers::TypeTraits.
> > > "../../glib/glibmm/arrayhandle.h", line 184: Error: Ambiguous
> > > partial specializa tion for 
> > > Glib::Container_Helpers::TypeTraits<Glib::RefPtr<Pango::FontFa
> > > mily>>, G lib::Container_Helpers::TypeTraits and
> > > Glib::Container_Helpers::TypeTraits.
> > > "../../glib/glibmm/arrayhandle.h", line 184: Error: Ambiguous
> > > partial specializa tion for 
> > > Glib::Container_Helpers::TypeTraits<Glib::RefPtr<Pango::FontFa
> > > mily>>, G lib::Container_Helpers::TypeTraits and
> > > Glib::Container_Helpers::TypeTraits.
> > > "../../glib/glibmm/arrayhandle.h", line 188: Error: Ambiguous
> > > partial specializa tion for 
> > > Glib::Container_Helpers::TypeTraits<Glib::RefPtr<Pango::FontFa
> > > mily>>, G lib::Container_Helpers::TypeTraits and
> > > Glib::Container_Helpers::TypeTraits.
> > > "context.cc", line 34:     Where: While specializing 
> > > "Glib::ArrayHandle<Glib::Re
> > > fPtr<Pango::FontFamily>,
> > > Glib::Container_Helpers::TypeTraits<Glib::RefPtr<Pango:
> > > :FontFamily>>>".

The .h and .cc files are generally generated, from the .hg and .ccg files,
but please hack about with the .h and .cc files so we can see what code the
.hg and .ccg files should be generating.

So, the error starts in pango/pangomm/context.cc, on this line I think:

Glib::ArrayHandle< Glib::RefPtr<FontFamily> > Context::list_families() const
{
  ..
}

This code looks the same in gtkmm 2.0.2, by the way.

I'm not sure what the compiler is complaining about, but I suggest that you
try:
- Specifying the Traits, instead of depending on the default template
parameter.
  You might use a typedef to make that easier. For instance:

  typedef Glib::Container_Helpers::TypeTraits<
Glib::RefPtr<Pango::FontFamily> > testtraitstype;
  typedef Glib::ArrayHandle< Glib::RefPtr<FontFamily>, testtraitstype>
testhandletype;

  See glib/glibmm/arrayhandle.h: 184 for more information about that
template.

- #ifdefing that method out, so we can concentrate on the other ones.

But there seems to be some interaction of FontFamily and FontFace - both are
mentioned in the error, but I'm not sure why.

Basically, I think something somewhere should specify a template paramter
instead of hoping that the compiler knows which specialization to use. That
might be a method somewhere, or a class - you can call
something.somemethod<TheClass>(), for instance.

Keep reading, please:

> > > and seem to be in the following files:
> > > 
> > > glib/glibmm/slisthandle.h
> > > glib/glibmm/listhandle.h  
> > > glib/glibmm/arrayhandle.h
> > > 
> > > Also pixmap.cc and screen.cc have the following errors:
> > > "pixmap.cc", line 84: Error: Overloading ambiguity between 
> > > "Glib::unwrap<const G dk::Drawable>(const Glib::RefPtr<const 
> > > Gdk::Drawable>&)" and "Glib::unwrap<const  
> > > Gdk::Drawable>(const Glib::RefPtr<const Gdk::Drawable>&)".

The 2 "ambiguou" methods mentioned there seem to be identical:
  Glib::unwrap<const Gdk::Drawable>(const Glib::RefPtr<const
Gdk::Drawable>&)
  Glib::unwrap<const Gdk::Drawable>(const Glib::RefPtr<const
Gdk::Drawable>&)
which is strange. But Drawable has some strange typedefs - please try using
window.gobj() instead of the Glib::unwrap<>(window).
 
> > > Any help would be appreaceated. I have developers waiting for
> > > this package.

Excellent. We will get there.

Murray Cumming
www.murrayc.com
murrayc usa net



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]