Re: [Pan-users] SSL on Pan 137

[Duncan]

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