Edward Catmur wrote:
> 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.
>
Thanks, I will use these variables next time I need to hack an ebuild.
--
Michael Andrews | <[EMAIL PROTECTED]>
0xE7D25F66 | keyserver.net
--
gentoo-user@gentoo.org mailing list
