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 335522 - gtkmm 2.0/2.2: Cannot convert `int*' to `void**' for argument
gtkmm 2.0/2.2: Cannot convert `int*' to `void**' for argument
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: build
2.2
Other All
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2006-03-22 14:14 UTC by Toralf Lund
Modified: 2006-04-11 17:05 UTC
See Also:
GNOME target: ---
GNOME version: 2.1/2.2


Attachments
Workaround (5.28 KB, patch)
2006-03-22 14:21 UTC, Toralf Lund
none Details | Review

Description Toralf Lund 2006-03-22 14:14:58 UTC
Please describe the problem:
gtkmm 2.2.12 fails to build on top of glibmm 2.6 or newer.

Error message is
   spawn.cc: In function `void Glib::spawn_async_with_pipes(const
   std::string&, const Glib::ArrayHandle<std::string,
   Glib::Container_Helpers::TypeTraits<std::string> >&, const
   Glib::ArrayHandle<std::string,
   Glib::Container_Helpers::TypeTraits<std::string> >&,
   Glib::SpawnFlags, const SigC::Slot0<void>&, int*, int*, int*, int*)':
   spawn.cc:92: error: cannot convert `int*' to `void**' for argument
   `7' to `gboolean g_spawn_async_with_pipes(const gchar*, gchar**,
   gchar**, GSpawnFlags, void (*)(void*), void*, void**, gint*, gint*,
   gint*, GError**)' 

The problem appears to be that the paramter types of g_spawn_... functions have
changed.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Toralf Lund 2006-03-22 14:21:31 UTC
Created attachment 61763 [details] [review]
Workaround

To make it build, I've updated the code as shown in this patch. Note that it changes parameters in call to glib without updating the glibmm declarations with newer types.

I chose to pass a local variable to glib functions, then assign to return value, as opposed to just type-converting the pointers, as I believe this apporach is somewhat more robust. Crashes are avioided if GPid/void * has different size an int - but there will obviously still be truncation issues in that case.
Comment 2 Toralf Lund 2006-03-22 14:24:25 UTC
Note that the glib version test needs to be reviewed, as I'm not sure when exactly the parameter type changed.
Comment 3 Murray Cumming 2006-03-22 14:55:41 UTC
Looks good. I'll release a new gtkmm 2.2 version after some time, when you are sure that it has everything you need.
Comment 4 Murray Cumming 2006-03-22 14:56:19 UTC
Note that you mean glib 2.6, not glibmm 2.6, above.
Comment 5 Toralf Lund 2006-03-22 15:34:49 UTC
Of course. I mistyped, there. It is actually glibmm as released with gtkmm-2.2.12 that fails to build on a current glib. Also, I've looked at the glib sources a bit closer, and found that:

1. The problem is partly platform-specific as GPid may be defined as int, not void *, on some platforms. The patch still applies to all of them, though, in the sense that it will always be more correct to declare the parameter as GPid (and not make assumptions about what that actually means.)

2. GPid was actually introduced somewhere during the 2.3 release cycle, so the #if-test should perhaps be changed somewhat. Maybe we shouldn't worry too much about 2.3.x (they are defined as "unstable", aren't they?), and just test for MINOR_VERSION 4 instead of 6 (is there any point in re-issuing the patch for such a minor update?) 

Note that a new release should probably also address the issue described in bug 309030 - I'm trying to build for mingw target with "GTKMM_API" in the TreeViewColumn class declaration right now.
Comment 6 Murray Cumming 2006-03-22 17:00:51 UTC
> Maybe we shouldn't worry too much about 2.3.x

Yes, ignore old unstable versions.

> Note that a new release should probably also address the issue described in bug
309030 

OK. Can you confirm that that patch fixes it for you?

Comment 7 Toralf Lund 2006-03-23 14:14:25 UTC
(In reply to comment #6)

> OK. Can you confirm that that patch fixes it for you?
Yes. In a somewhat limited sense, that is. The patch makes the actual compilation error disappear, but unfortunately, there are some related issues that also need to be addressed. I have added a note to the other report describing the details.
Comment 8 Murray Cumming 2006-04-03 11:20:22 UTC
Committed to the gtkmm2 cvs module. 
Comment 9 Murray Cumming 2006-04-11 17:05:03 UTC
So, this particular bug seems to be done.