Bob posted on Thu, 02 May 2013 19:58:24 +0000 as excerpted: > On Thu, 02 May 2013 19:54:39 +0000, Bob wrote: > >> what would I need to download to do so? >> Am running Mint 13 Maya (LTS) AMD-64. >> >> Already posted similar message in the developer group, >> >> Bob > > OOP's also have Mint LMDE 201303 AMD-64 newly installed and running.
I'm not the best authority on this, as I run gentoo, which being end-user build-from-source by default, doesn't do the runtime/buildtime package splits that most binary distros do. However, since nobody else seems to be responding... and years ago I did run a binary-based distro (Mandrake) and build from sources for some things, so I do know a bit about it... The easiest way to build from live-git on a binary-based distro is to break it down into steps. Note that the below is a bit of a worst-case, and that in most cases, other than the runtime/devel split I mention below, which a good package management system should pretty much take care of for you with step #1, it ends up sounding much worse than it actually ends up being when you actually do it. Step one, get the existing distro package to build from source using its source-package (srpm or whatever, I don't know what debian-based-distros call the source package). That will pull in most of the dependencies you need, including the -dev/-devel packages for the necessary libraries. It's worth noting specifically once again, since it confuses nearly everybody on a binary-based distro the first time or two they build something from source, that binary-based distros break most of their libraries into two packages, the runtime package that is commonly depended upon by other binary packages using that library, and the build- time or -dev(el) package that only those building anything that depends on that library from source need. The runtime package contains the actual library binaries, while the build-time package contains the headers (*.h files), pkgconfig files (*.pc), etc, that aren't needed to actually run anything using that library, but ARE needed to build against it. So if you see an error that libsomething.so isn't installed when you know it is, what's normally because the libsomething-devel package isn't installed, so while the binary/runtime bits of the library might be installed, it can't be used to build anything because the -devel package is missing. By first building the existing version from sources using the distro's normal source-package, its package-manager should pull in most of these -dev packages automatically, and if it misses any, you should get an error that's easier to match up to a missing -dev package or whatever, than you would if you went straight to building live-git. Of course, that also serves as a "gentle" intro to building from source, while the distro package manager is still managing most of the deps, etc, thus taking some of the mystery out of it while getting you used to the general procedure, what a normal build looks like, etc. Step two, once you can successfully build and run the distro's existing version from its existing sources, advance to the latest version tarball from upstream, pan 0.139 in our case. Sometimes, you'll need a later version of some library than what shipped with your distro, since you're now building upstream's latest shipped version. Other times, the distro did some distro-specific patching making its version easier to build on that distro, or something, and you'll need to figure out how to make the unpatched sources build or to patch them yourself. But by this point you should recognize what's going on a bit more, making it easier to figure out the problem and the version of the library you need to update to, if that's the problem, or be able to tell because it's looking in the wrong place for something compared to what the distro version did, that the distro version was either configured special to look where it looked, or patched to do so, thus being familiar with what your native distro version build looks like is already half the answer to any problems you encounter at this stage. It's also worth noting that package source tarballs typically include INSTALL and/or README files that tell you something about what you need to build the package, and how. Sometimes there's similar information on the package's homepage. Pan is no exception. Once you get the latest release-version from upstream successfully building and running, THEN go for step 3, actually trying the git-live version. This step can actually be the hardest, because there's less documentation on it, and there's often some additional dependencies that aren't needed for building from a release tarball, because part of the release process is doing some pre-config, etc, that individual users have to do when they're building from the raw un-release-prepared sources. (The same files are often there, just outdated, as the sources have changed since the last release updated the pre-config files to match the sources.) And honestly, I remember not being able to overcome this step back on mandrake for some time -- I could build from a release tarball, but not from the live sources, and I didn't know what I was missing. I don't remember for sure whether I /ever/ actually overcame that on mandrake, or whether it was only after switching to gentoo, that I was able to do it, everything seeming to "just work", because gentoo actually defaults to building from sources so makes vastly different assumptions about the tools and configuration that should be default on the distro. I still don't have the greatest personal understanding of this step, but I've been able to guide a number of folks thru it, by "cheating", as it were, just looking at the gentoo live-ebuild (or one for another similar package if there isn't one for that package, tho for pan there is, so it's easy enough) to see what it does, one command at a time, and having the person I'm guiding thru the process do the same thing, only manually. When you get to that point, I'll do that. Meanwhile, it's enough for now to describe it in higher level terms. Pan, like many free/libre and open source packages, is autotools based. When one builds from a release tarball, normally all one does is unpack the tarball, cd into it, run ./configure (which is a script that detects what's available on the platform and sets up the build appropriately), then make (which actually builds the binaries from sources), then make install (which installs the binaries made in the last step). But, where did this configure script come from? It's auto-generated by the various components of the autotools package, automake, autoconf, etc, in several steps, from much shorter "recipe" files. Running these to update the configure script against the latest sources is a routine part of preparing for a release, and is thus normally already done in the release-version tarballs a project ships. But once you graduate to the level of building from live-sources, you're typically building from sources that have changed since the last time the configure script was built, so it may be outdated and no longer function as expected, unless you do the release-prep steps yourself. The problem is that except for developers themselves, this whole process isn't so well documented, and the documentation for developers tends to be *MUCH* more complicated than it should be for a non-dev normal end- user simply trying to build the current unreleased sources. Among other things, there are several versions of autoconf, automake, libtool, etc, and if a project's using a version different than what a distro ships, there can be issues getting it to work properly. Not to harp on it /too/ much, but this is one of the areas where a default-from-source distro tends to be far easier, because it normally assumes its users are going to be /doing/ such things. For example, on gentoo, it's routine to have several versions of automake and autoconf installed at the same time, parallel to each other, with a wrapper that normally sorts out which one should be used, and a method of specifying one version directly, if for some reason the wrapper is making the wrong choice. On a binary-based distro, by contrast, the assumption is that most users will only run packages pre-built by the distro, and if there's autoconf and automake installed at all by default, there may not be provision to install different versions in parallel, making it far more of a hassle to build a package that doesn't work with a distro's default version. Of course, whatever VCS (version control system, most often git these days as it is with pan, but it used to be svn most often, and rcs before that, and there's other VCSs as well) an upstream uses, must be installed as well, once you're building from live sources. That's unnecessary when building from a pre-packaged tarball. However, given that you already specified building pan from git, it's likely you already expected this requirement. So anyway, once you get step #2, building from the latest pan tarball, working, and have git installed and are otherwise in general ready to go, post again to that effect, and if nobody else does, I'll try to guide you thru the additional pre-configure steps. Again, it probably looks a lot worse as I've described it above than it actually is in practice, but I know I passed the other hurdles easier than I did this one, which took me quite awhile, and I may have only done it once I switched to gentoo. But as I've said, I've helped others thru it, so it's possible. And if you're lucky, your distro might make it easy enough that you find you don't need the extra help I and others did to get over that hurdle, after all. =:^) -- 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
