Ed Fletcher posted on Sat, 19 May 2012 20:38:18 -0300 as excerpted: > On 05/19/2012 08:07 PM, Duncan wrote: >> Ed Fletcher posted on Sat, 19 May 2012 18:29:58 -0300 as excerpted: >>> Where does configure get the version information? >> >> Often/normally from pkgconfig files, which are replacing the old >> libtool methods, etc. >> >> Look in /usr/lib(64)?/pkgconfig/ (standard location, distro may change >> it) for a gnutls.pc file. Whatever that's pointing to is very likely >> to be what's detected. Also check the include files at (again, >> standard location) /usr/include/gnutls/* , as those are likely to be >> the headers built against.
> Bingo! Found /usr/local/lib/pkgconfig/ with the two files in it. Moved > them to /usr/lib64/pkgconfig/ and now the ./configure file in pan can > see the newer version of GnuTLS. > > Hmph. Now make fails: > > make[3]: Entering directory `/root/pan2/pan/data' > CXX article.o CXX article-cache.o CXX encode-cache.o CXX > cert-store.o > cert-store.cc: In member function 'void > pan::CertStore::remove_hard(const pan::Quark&)': > cert-store.cc:302:22: error: 'unlink' was not declared in this scope > make[3]: *** [cert-store.o] Error 1 > > I take it from the cert-store.o that it something to do with TLS. Maybe > I broke something by moving the files around by hand. Yes, cert-store has to do with storing the certificates pan receives for a secure connection, so indeed, it's ssl-related. My guess is that it's still finding the old include files since you didn't mention moving them or editing the *.pc file. The *.pc file should give the correct paths, but in the actual compilation, it's likely the system paths are coming first, in ordered to be able to find other libs, so the build is using the headers in those system paths, which are still the old headers since that version wasn't removed. Meanwhile, in the other subthread you mentioned possibly building the new version, pointed at the system location, thereby replacing the old one already there. That should work for pan since you're rebuilding it now, but do be aware that it may well break other apps/libs depending on gnutls. They'd likewise be fixed with a rebuild (possibly with a patch or of a newer version), but I'd at least check to see what packages you actually have linked against gnutls, so you have some idea of how big the hole you're digging might get. That's one good thing about gentoo and similar managed-build-from-source distros. Since everything's built from source, and at least gentoo has a tool called revdep-rebuild that can automatically scan for such broken dependencies and tell you what to rebuild, breaking such dependencies due to update is no big deal, you simply run the tool and let it rebuild what it needs to, afterward, and since everything's built from source already, there's no worry about having to manually bring in whole lists of missing build dependencies and resolve everything one manual build and test at a time. I remember running mandrake and having to do that manually, and how nice it was when I first started on gentoo, having it all "just work", because the whole set of assumptions were different when you were building /everything/ from sources. -- 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
