Re: [Pan-users] compiling PAN on 64-bit Linux

[Duncan]

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