Mike Brown posted on Fri, 06 Apr 2012 07:41:41 -0500 as excerpted: > System is Fedora 13 64-bit. > > When configure is run from the 135 source, it bails when it gets to the > gmime package test. > > The problem is that while gmime 1.5.1-1 is installed (yum is used), but > a "pc" file is not created, so pkg-config doesn't think it is on the > system. > > What is needed to get around this issue?
That one's fairly easy, I think. =:^) On binary-based distros such as Fedora, most users don't do a lot of building from sources, so common library packages are split in half, the "runtime" half containing the binaries, etc, and the "dev" half that contains the pc files, headers, etc, necessary to build anything depending on those libraries. You have the runtime half installed but are trying to build something depending on it, so need the dev half as well. Look for a gmime-dev package of the same version. Install it and you should get past that, but will likely have the same issue with a few other libs as well. IIRC from my Mandrake years (nearly a decade ago but...), rpm-based distros have srpms, aka src.rpms, available, that track build-time dependencies and allow you to rebuild the package from sources. If you first find the old pan 0.133 or whatever srpm and try to rebuild pan using it, it'll pull in all the dependencies it needed for building that version. That will install most of what you need, tho it's possible there will be a few newer or added dependencies in the newer pan version that you're actually trying to build. But it'll be more like one or two, than 10 or a dozen, which you'd otherwise be finding out about one at a time, as your configure failed at a later point each time as you installed them. FWIW, that's one of the bonuses of running a source-based distro such as gentoo, which I run now. Since the assumption is then that you build everything yourself, including whatever triggered your install of the library package, it makes little sense to split such packages into runtime and -dev packages. That means that even when building something outside the normal packaged system, it's much easier, as far more of them are already installed in ordered to build packages that ARE tracked by the packaged system. =:^) Of course the same thing could be accomplished with a normally binary-based distro by using srpms for everything, but because the assumptions are still different, that's not as easy either -- less of it is automated and what is handled automatically doesn't expose the same level of build-time options that a good source-based distro will give you. For instance, packages that can be built with additional kde and gnome support both, will usually be built with the optional support and linked in dependencies turned on for the one the distro defaults to, but turned off for the other one, since it'll bring in more dependencies. If you happen to prefer a desktop other than the one the distro defaults to, you thus end up with less optional support for it than you might like, while it drags in additional deps for the optional support for the default desktop, which you normally don't run anyway. One of the advantages (beyond not having to worry about -dev packages) of a good from-source distro is that such build-time-optional deps will normally be exposed for the user to control. In gentoo, such options are exposed as USE flags. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
