Thanks, Allin.
For one thing, you need to ensure that you're building 64-bit versions of the libraries if you want to overwrite the distro-supplied versions. I'm not familiar with CentOS but presumably this should be documented.
It's building 64-bit versions all right, the problem seems to be putting them in the right place.
Secondly, there's no point in building/installing obsolete "unstable" versions of the libraries in question (e.g. glib 2.27.93): use current stable versions, which for glib means 2.28.7 or 2.30.2.
I picked 2.27.93 because the gtk+ 2.24 configure told me I needed glib 2.27 or greater. I figured getting the latest sub-release of 2.27 would (1) get me the most stable 2.27 and (ii) avoid any larger inconsistencies with the rest of CentOS that might be introduced by a much more recent version. At one point in my numerous experiments yesterday I did try to build the very latest 2.30 (I think 2.30.2) and the glib configure complained about yet more missing dependencies. Not needing an even greater headache I quickly abandoned that effort. Are you aware of something about 2.27.93 that makes it a particularly poor choice, or that makes 2.28.7 a particularly good one? I would definitely prefer to get myself as minimally far in front of the rest of CentOS as possible.
Third, consider the environment variable PKG_CONFIG_PATH.
Sleeping on things overnight I'm thinking the best option may be to go back to the default configure options, let all the new packages dump their stuff in /usr/local, and adjust my environment as necessary to pick up those libraries, etc., in advance of the CentOS-included ones, which would include adjusting PKG_CONFIG_PATH as you've advised. Hopefully if I do this then the pkg-config call that's used to set my compile flags and library directories will get me all the right stuff?
Thanks! Roger _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
