On Wed, 2005-04-20 at 16:16 -0400, [EMAIL PROTECTED] wrote: > I am trying to build a package called sipXphone. It requires > glib-2.4.2, but most of my current packages require glib-2.6.3 (the > latest version).
"requires" glib-2.4.2 sounds unlikely. Presumably you mean that it doesn't compile against glib-2.6.3? If the issue you are coming up against is http://track.sipfoundry.org/browse/XPL-107 then the bug is (a) obvious and (b) trivial to fix: replace #include <glib/g*.h> with <glib.h>. > One would think that the versioning would be backwards > compatible but this is not the case. I still don't know how to proceed > except by building this old version, in a special area that doesn't > conflict with the rest of the system (ie. /usr/local). Yup. glib's internal SLOT-like logic means that two 2.x versions will conflict, as its includes and libraries take the name glib-2.0. Installing to /foo with portage is in theory possible, but tricky: assuming the package uses autotools and the ebuild uses econf and emake, you need to mess around with EXTRA_ECONF and EXTRA_EINSTALL, or just hack the ebuild to pass appropriate prefix (see ebuild(5)). You would also have conflicts with the pkgconfig .pc files; first you would need to get it to drop the .pc files in a different place than /usr/lib/pkgconfig, then export PKG_CONFIG_PATH=/path/to/pc/files when compiling using the new package. What could be easier is setting up a chroot environment and building packages there; glib has AFAICR excellent binary compatibility. -- gentoo-user@gentoo.org mailing list
