GNOME Bugzilla – Bug 79116
compatibility patches for Sun Forte C++ compiler
Last modified: 2004-12-22 21:47:04 UTC
Created attachment 7781 [details] [review] compatibility patches for Sun Forte C++ compiler
I'm sorry for the confusion, but I'd like these patches separated like you first sent them to me. It's easier to review and apply them one-by-one, and it makes the cvs history clearer. But you can just add them all to this one bug. In particular, we probably won't apply the examples patches until we have investigated the function-pointers-with-signals issue.
Created attachment 7837 [details] splitted patches the Sun Forte C++ compiler
That patch was a .tar.gz, by the way, and it included these patches: already applied: gtkmm-1.3.11_sunpro_cc-iterator.cvs_diff (Though I would like some comments to be added as comments next to the #ifndef in the code - ideally with a url of a Sun page saying "Forte is wrong." All conditional compilation should be commented like this. gtkmm-1.3.11_sunpro_cc-missing_namespace.cvs_diff gtkmm-1.3.11_sunpro_cc-missing_returns.cvs_diff gtkmm-1.3.11_sunpro_cc-missing_typename.cvs_diff gtkmm-1.3.11_sunpro_cc-typedef_friend.cvs_diff gtkmm-1.3.11_sunpro_cc-default_arguments.cvs_diff gtkmm-1.3.11_sunpro_cc-extra_semicolon.cvs_diff not yet applied: gtkmm-1.3.11_sunpro_cc-const_mismatch.patch-not_in_cvs (TODO) gtkmm-1.3.11_sunpro_cc-examples_libsigc++.cvs_diff (Waiting for Karl to comment.) gtkmm-1.3.11_sunpro_cc-failed_initialize.cvs_diff (We need more information. I don't think we discussed this on the mailing list. operator overrides should do this automatically. Please show us the compiler error messages.)
I have committed some automatic conversions changes that should have much the same effect as the gtkmm-1.3.11_sunpro_cc-const_mismatch.patch-not_in_cvs file. That leaves: gtkmm-1.3.11_sunpro_cc-examples_libsigc++.cvs_diff (Waiting for Karl to comment.) gtkmm-1.3.11_sunpro_cc-failed_initialize.cvs_diff (Operator overrides should do this automatically. Error messages posted to the list. In progress.) If possible, could you test our progress so far, by building from cvs. You will need to apply these last 2 patches to your local copy.
> I have committed some automatic conversions changes > that should have much the same effect as the > gtkmm-1.3.11_sunpro_cc-const_mismatch.patch-not_in_cvs > file. This works now fine without any changes under Sun Forte C++ too. In version 1.21 of gdk/src/pixmap.hg the changes introduced by gtkmm-1.3.11_sunpro_cc-default_arguments.cvs_diff (1.20) got lost again. Seems to be a checkin mistake - please patch it again. BTW, I think gtkmm-1.3.11_sunpro_cc-missing_typename.cvs_diff has not been applied yet. I still see these warnings under Sun Forte C++.
> In version 1.21 of gdk/src/pixmap.hg the changes introduced > by gtkmm-1.3.11_sunpro_cc-default_arguments.cvs_diff (1.20) got > lost again Yes, I had removed that /* = -1 */ because our gtkmmproc parser couldn't parse it. Rather than remove the default argument value, the correct solution was to fix the parser so that the value did not appear in the .cc file. I have done that now. > gtkmm-1.3.11_sunpro_cc-missing_typename.cvs_diff Yes, I must have forgotten that. However I now get these errors from gcc 2.96RH: In file included from ../../glib/glibmm/sarray.h:27, from ../../glib/glibmm/containers.h:28, from ../../glib/glibmm/object.h:31, from closure.cc:25: ../../glib/glibmm/arrayhandle.h:379: parse error before `const' ../../glib/glibmm/arrayhandle.h:379: confused by earlier errors, bailing out If nobody provides a portable solution for this, then please provide a patch which adds #ifndef sections, with detailed comments saying why the #ifndef is necessary.
Putting 'typename' after 'const' made it work. It all compiles fine now, thus I committed the patch.
configure now checks for std::iterator_traits<> and the Sun-style reverse_iterator<>. When anoncvs finally caught up (it's sometimes 24h - 48h behind), could you please test whether the configure checks work? Thanks, --Daniel
The recent changes work perfectly under Forte C++. Great job done!!! Still open remain gtkmm-1.3.11_sunpro_cc-failed_initialize.patch and gtkmm-1.3.11_sunpro_cc-examples_libsigc++.patch. Unfortunately the libsigc++ mailing is not responding at the moment. Now where gtkmmproc is changed to skip the default parameters for the implementation files, should we reverse the changes from gtkmm-1.3.11_sunpro_cc-default_arguments.patch? (pango/src/layoutline.hg, gdk/src/pixmap.hg, gtk/src/bin.ccg, gtk/src/adjustment.ccg, gtk/src/imagemenuitem.ccg, gtk/src/statusbar.ccg)
Have you subscribed to the libsigc++ list? There is nothing wrong with the patches to the .ccg files. Regarding the .hg files, I have already restored the default value in pixmap.hg, and in the layoutline.hg file it seems to be sensible to remove the default value from the forward declaration.
I have applied gtkmm-1.3.11_sunpro_cc-examples_libsigc++.cvs_diff because it doesn't actually change many things - most signal handlers are only in the custom derived classes anyway - e.g. on_mybutton_click(). Regarding gtkmm-1.3.11_sunpro_cc-failed_initialize.patch, with gcc these conversions are done by the operator| overloads in gtkmm/enums.h. Without a full SUN environment it's hard for us to investigate why this isn't working for you. Maybe you could try moving those operator| functions out of the Gtk namespace into the global namespace.
The remaining problem with Forte C++ (gtkmm-1.3.11_sunpro_cc-failed_initialize.patch) has nothing to do with the operator| overloads in gtkmm/enums.h. The error shows up without it too. According to the ISO C++ standard, the following rules apply: enum flag { a=1, b=2, c=4, d=8 }; // range 0:15 flag f1 = 5; // type error: 5 is not of type flag flag f2 = flag(5) // OK: flag(5) is of type flag and in range flag f3 = a|b // type error: a|b is not of type flag flag f4 = flag(a|b) // OK: flag(a|b) is of type flag and in range flaf f5 = 16 // undefined: 16 is out of range of flag Enums are only allowed to be initialized or explicit converted from integral types. Thus the provided patches are correct so far. The problem here was that g++ treats enums as integers, which is not correct. Most UNIX compilers don't do it this way. > Have you subscribed to the libsigc++ list? Yes, I did. The problem description was send to the list on 18th April, still waiting for approval. Fortunately the people can see Murray's entry from the weekend.
> The remaining problem with Forte C++ > (gtkmm-1.3.11_sunpro_cc-failed_initialize.patch) has nothing to do > with the operator| overloads in gtkmm/enums.h. The error shows up > without it too. Of course the error shows up without them. The point is, it should work _with_ the operator|() overloads. I'll try digging into this problem on the SourceForge compiler farm today.
I checked it with a sample program without any namespaces. The operator|() is simply not called with Forte C++, with g++ it is.
Created attachment 7956 [details] testcase: enums + operator overloads
The attached testcase works fine on SourceForge's compiler farm. daniel_e@usf-cf-sparc-solaris-1:~$ CC -c -o testcase_enum.o testcase_enum.cc daniel_e@usf-cf-sparc-solaris-1:~$ CC -V CC: Sun WorkShop 6 update 1 C++ 5.2 2000/09/11
I'm sorry, but I have the bad news: [szombath@frodo:~/Foo]$ CC -c -o testcase_enum testcase_enum.cc "testcase_enum.cc", line 34: Error: Cannot use int to initialize Foo::BitFlags. "testcase_enum.cc", line 35: Error: Formal argument 1 of type Foo::BitFlags in call to Foo::test_func(Foo::BitFlags) is being passed int. "testcase_enum.cc", line 36: Error: Formal argument 1 of type Foo::BitFlags in call to Foo::test_func(Foo::BitFlags) is being passed int. "testcase_enum.cc", line 39: Error: Formal argument 1 of type Foo::BitFlags in call to Foo::Bar::test_method(Foo::BitFlags) is being passed int. 4 Error(s) detected. [szombath@frodo:~/Foo]$ CC -V CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-06 2002/03/09 I will send this example to the Sun Forte C++ forum.
> I will send this example to the Sun Forte C++ forum. There are already two responses at http://forum.sun.com/thread.jsp?forum=5&thread=8852, which say the code is okay. I'm still waiting for some responses from Sun's folk.
From that link it looks like you are unlucky. In the meantime I have applied gtkmm-1.3.11_sunpro_cc-failed_initialize.patch to the gtkmm source, but not to the examples. Actually, that is only a default value in gtk/src/table.hg. This should allow people with that particular version of the compiler to build gtkmm. They will then need to worry about this small problem with some of the examples, and with their own code. So, I hope to hear soon that gtkmm builds and works for you on Sun/Forte. Then I can announce that with a new release.
Yes, I can confirm that Sun Forte C++ now compiles the library out of the box. With the patches in examples/dnd/dndwindow.cc examples/rulers/rulers.cc also the examples go through. My observations when running the examples: (1) All examples show the following warning: GLib-GObject-WARNING **: specified instance size for type `gtkmm__AtkStateSet' is smaller than the parent type's `AtkStateSet' instance size (2) paned/paned emits lots of warnings: Gtk-CRITICAL **: file gtktreeviewcolumn.c: line 2178: assertion `tree_column->cell_list != NULL' failed and remains empty. (3) dnd/testdnd crashes when dragging with segementation error. It happens in DnDWindow::on_image_drag_motion() of dnd/dndwindow.cc at the g_print() call (source_widget seems to be invalid). All other examples work fine. The setup used: - Forte C++ 5.3 plus all actual patches applied, - automake-1.6.1, autoconf-2.5.3, libtool-1.4.2 - gtk-2.0.2, glib-2.0.1, atk-1.0.1, pango-1.0.1 Thus, please go forward with a new release. It's really a big step and I hope that other people using commercial compilers will be encouraged to help make Gtk-- more portable and finally to use it.
1) Yes, that's a bug that I have just introduced. 2) Confirmed. Open another bug if it doesn't get fixed soon. 3) Works for me. It might be Solaris-specific. Please try the gtk+ tests/testdnd app.
Just to let you, know that the Sun C++ compiler is hopefully going in the right direction. With the upcoming compiler patch 111685-09, which I already got from Sun Service for test purposes, the inability to overload enum operator is resolved. I will let you know, when the patch is publicly available, as we still have one case in the library code, beside of many in the examples, where the code was changed to help Sun's compiler.