[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] compiling PAN on 64-bit Linux
From: |
Duncan |
Subject: |
Re: [Pan-users] compiling PAN on 64-bit Linux |
Date: |
Thu, 25 Jul 2013 05:48:43 +0000 (UTC) |
User-agent: |
Pan/0.140 (Chocolate Salty Balls; GIT 80384ce /usr/src/portage/src/egit-src/pan2) |
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