Darcy Kahle posted on Wed, 24 Jul 2013 22:50:39 -0400 as excerpted: > I am trying to compile Pan on a 64-bit version of Linux, and I am having > problems. gmime is installed as a 64-bit library under /usr/lib64, but > configure cannot find it. What configuration option do I need to > provide so that the library can be found and used?
You don't mention what distro, but presumably it's a binary-package distro, not a distro that routinely builds from source like gentoo (which I run). On such binary-package based distros, library packages are generally split in half, the runtime half that pre-built packages require, and the build-time half (typically named as libname-dev or libname-devel) that pretty much anything depending on that library needs to build, but that isn't required at run-time. The build-time half typically contains header-files (*.h, typically located in /usr/include/), pkgconfig files (*.pc, typically located in /usr/lib64/pkgconfig/), static-archive files (*.a, not generally necessary unless binaries are built with all libraries included instead of dynamically loaded at runtime), libtool files (*.la, similarly not often required to build dynamic loading executables on a modern system) and perhaps documentation for developers, etc. Since it's the pkgconfig (*.pc) files that a configure script typically looks for, on these binary-package based distros configure scripts often complain that the library isn't installed if the -dev(el) package isn't installed, seriously confusing users trying to build a package for the first time, who don't yet know about library splits and the consequent existence of these -dev(el) packages. So to solve the immediate problem, you'd probably simply look for and install a package named something like gmime-dev or gmime-devel. However, doing it that way, one at a time, is likely to lead to frustration, since as soon as you install that package and get past that configure script error, you're very likely going to encounter another just like it for another library, and another after that, and another after that... Luckily, there's a simple way around that problem. Even if your distro's version of whatever you're ultimately trying to install (pan in this case) is a bit behind, install and build the sources package. This will pull in all the -dev(el) packages that are required to build the package as deps, only all at once instead of one at a time. By actually doing the package build as well, even if it's for an older version, you should get a better idea of what the build process actually looks like and demonstrate to yourself that it actually does build. Of course if there's an error at that stage, since it's a distro package build you should be able to get distro support for fixing it as well, but hopefully there won't be. Once you have the distro's sources package building and installing properly, THEN graduate to building from the latest upstream version tarball. It's possible that you'll need to manually upgrade a few libs to newer versions at this point if the upstream's minimum version dependency has changed, but you'll have far fewer packages to install manually now than you would have otherwise, and you'll already have demonstrated that the (presumably) older version from your distro builds, so tackling any new problems should be far easier. If you want to stick with upstream's latest release version, stop there; if however you want to try the latest development code direct out of the upstream repository (often but not always git, these days, it's git for pan), continue. With have the latest upstream release version building, you can try building the live code direct from upstream's repository. Do be aware, however, that there's likely to be a few differences in the build process for the latest code direct from the upstream repo, because there's a few additional steps typically done to the live-code to prepare it for release, that you'll need to do on your own if you try building direct from live repository. After people figure out the split library packages thing, it's generally fairly easy to build the latest release version, but fewer people try building the live code and many/most of those that do are developers, so it's assumed they already know how to prepare that code for actual building, and this step thus tends to be far less documented than the earlier steps. So many people get stuck here and either have to ask for help or simply decide to stick with the latest upstream version. I know I had problems figuring out how to build from live code back when I was on a binary-package-based distro, and am not sure I actually learned how to do it until after I was on gentoo. Even still, while gentoo has live-ebuilds available for many packages for those who want to try it, where that's not available, I generally sort of cheat and look at a live ebuild for something similar, then adjust and copy what it does, rather than truly understanding the full process. Luckily however, there's a live-build available for pan which I've been using (and occasionally hacking on) for some time, so when non-gentooers ask about the steps necessary, I can just refer to what the live ebuild does and tell them to do the same things manually that the script automates for me. HTH... =:^) -- 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
