Description of problem: Anjuta -> Start New Project -> Select Gtkmm -> Start build and configure fails with "unable to find gtkmm-2.0". Looking at the generated configure script shows the offending line as follows: ($PKG_CONFIG --exists --print-errors "gtkmm-2.0") 2>&5 And configure.in shows PKG_CHECK_MODULES(PACKAGE, [gtkmm-2.0]) We have gtkmm-2.4.pc installed after the updates in /usr/lib/pkgconfig. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. As above. Actual results: As above. Expected results: A successful build of the skeleton. Additional info: Workarounds as follows: 1. Edit the configure.in script and alter the project properties so that configure.in is not overwriiten. Replace the faulty line with PKG_CHECK_MODULES(PACKAGE, [gtkmm-2.4]) OR 2. su and create a symbolic link in /usr/lib/pkgconfig with the command ln -s gtkmm-2.4 gtkmm-2.0. Either of the above results in a successful build of the gtkmm project skeleton. Presumably the glademm skeleton is similarly affected but I have not tested this.
Surely these problems are gtkmm ones and not anjuta ones? To make sure, I've checked the files you've cited in anjuta and gtkmm is not listed anywhere.
I don't understand this. I can repeat it on my machine no problem. All you need to do is to try and create a gtkmm project using the anjuta project wizard. I don't think it's a gtkmm problem since pkg-config --exist gtkmm-2.4 returns a successful result and gtkmm-2.4.pc does exist in /usr/lib/pkgconfig. In what way would this be a gtkmm problem?
Yep. Looks like an anjuta issue: $ strings /usr/bin/anjuta |grep gtkmm |grep PKG_CHECK PKG_CHECK_MODULES(PACKAGE, [gtkmm-2.0]) Patching this to use gtkmm-2.4 instead would get you through this error. I don't use gtkmm or anjuta so I don't know if there are other things that the anjuta wizard are setting up that should be adjusted for gtkmm-2.4, though. If gtkmm-2.4 has been out for a while, upstream anjuta might have some ideas floating around their development branches as well.
My apologies - too many things going on. Yes, it's an anjuta bug - the problem is that gtkmm is not found in the base configure.in, so it must be elsewhere. I'll need to have a search for that and if all else fails, I'll ask upstream for advice. It certainly seems odd though that -2.0 should be included as the anjuta website says that it doesn't target any version in particular (or words to that effect).
I'll patch it later thanks as I have since done a rebuild. My tests seemed to indicate that there would be no other problems as all the LD flags etc looked correct by checking them against the dependencies listed in gtkmm-2.4.pc but I'll run some more tests later.
I've asked upstream about this but have not had a reply as yet. Did you have any luck with the patch. I have a feeling that Nasar is now just concentrating on the 2.0.x branch. I am currently working on getting the deps for this through the FE approval list (it depends on gnome-build, autogen and gdl being in place)
Sorry for the delay. The patch works fine as do the other workarounds. I had a look at the version 2 branch on Sourceforge (looks sexy!) but the install required testing versions of glib and friends plus a few other things and I wasn't prepared to compromise my system stability at this stage for "bleeding edge" stuff. Glad to hear that it is going through approval though as it will be nice to have UML etc.
which config.in file needed patching? Anjuta2 is sexy, it's just a pain to build!
I'll get back to you on this later today or tomorrow as I've just done a fresh build (been messing around and broke my machine).
Not to worry, I've patched the source which is a far better idea than patching a config file IMHO. I've tested it here on an x86_64 box and it seems to work happily in rawhide. The icon still says 2.0, but given 1.2.4a is no longer maintained (other than security fixes), I'd rather concentrate on getting the 2.0.x branch working happily.