| sean finney on 31 Dec 2008 11:18:41 -0800 |
|
hiya, On Wed, Dec 31, 2008 at 12:01:14PM -0500, Eric wrote: > While I agree with you in general this *may* be a specific case where > compiling from source can help. The current binary is from July of '08 > and the OS is Ubuntu 8.10. I suspect there may be some subtle library > changes that compiling from source *may* help. If not: Oh Well I Tried :-D yeah, sometimes the libraries that the package in question uses changes in a way where the abi is subtly broken and it's not detected by the developer or any of the automated tools. sometimes just recompiling against all the same libraries on your current system will magically fix it in that case. > The thing that annoys me in the compile-from-source option is that I > don't know until I start what libraries and headers I need. I compile apt-get build-dep <pkg> is a good starting point (after adding the relevant deb-src lines for your distro/release). > until there is an error, try to figure out what's missing that caused > the error and install that, then re-try. It's similar to diagnosing > medical conditions like Dr. House :-) if you do the above it will get you quite far. you can also then look in debian/rules in the existing source package, which will usually have the configure/make options buried somewhere in it. a few other things that might prove useful (though i don't know how useful for your situation, i'll just blurt them all out for shits and giggles) - apt-get source -b <pkg> will download and recompile the source package in question into a new .deb. in the case of subtle library changes this is often an easy way out. - depending on the quality of the package, local patches, and other changes, you can sometimes get away with doing a cp -a on the debian directory from the source package into a newer/unpackaged version of the source code, creating a fake changelog entry in debian/changelog, and then rebuilding with dpkg-buildpackage - if you build the code entirely from source, you should consider installing it somewhere that will not conflict with the pkg management system, ideally somewhere that you could easily uninstall it later. i prefer using stow, or a --prefix that's otherwise unique and open to an rm -rf later. - if you build the code entirely from source but other packages depend on one of the binary packages, you can create a "fake package" with equivs. hth, sean Attachment:
signature.asc ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|