[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] ssl problems, not working on ports 443 or 563

From: Duncan
Subject: Re: [Pan-users] ssl problems, not working on ports 443 or 563
Date: Mon, 2 Apr 2012 05:17:06 +0000 (UTC)
User-agent: Pan/0.136 (I'm far too busy being delicious; GIT 72905f5 /st/portage/src/egit-src/pan2)

bob posted on Sun, 01 Apr 2012 22:49:03 +0000 as excerpted:

> On Sun, 01 Apr 2012 20:22:32 +0000, bob wrote:
>> On Sun, 01 Apr 2012 21:16:02 +0200, Heinrich Mueller wrote:
>>> Did you configure with --with-gnutls and set to SSL ?
>> I did the build myself, but there was nothing that I could find to tell
>> me how to set the configure, and nothing in the blog mentioned it.
>> if the [ --with-gnutls and set to SSL ] is what I need to do then I
>> will redo the build. the gnutls was downloaded, but no configuration
>> notes were listed.
>> As far as I am concerned I would like to build a full blown version,
>> all the bells and whistles.
> I ran  ` --with-gnutls' still no cigar.  I get a pagefull of
> gnutls entries in synaptic, which one should I install and how should I
> set things up to compile with it.

Try adding the --with-gnutls at the configure step, after, 
before make.

FWIW, the traditional tarball build process (regardless of package) is 
untar, cd into the build dir, ./configure (thus, run the configure script 
in the current dir, ./), make, make install.

The configure script takes various options (like our --with-gnutls) and 
adapts the make scripts to the current environment, detecting various 
tools and dependencies, etc.  Then the make actually builds the binaries 
from sources, and make install actually installs them to their permanent 
location on the system.  Often there's an optional make docs or some such 
that you can run as well, before doing the make install.

But if you're building from a raw repository (as we are with live-git), 
there's an extra step or two before the ./configure, that actually 
rebuilds the configure script itself, adapting it not to the current 
system (that's what configure does), but to the current changes in the 
source code, since the last time time it was updated.  (This is rather 
simplified, there's several possible steps, each of which adapts a 
different thing.)  That's where the comes in.

But the (./)configure should still be run afterward, to detect what's on 
the system itself and modify the make scripts accordingly, before the 
actual make/build itself.

As for figuring out what switches are available, once the configure 
script is current, before running the ./configure, run
./configure --help .  That will spit out a bunch of options, including 
options that control where stuff installs, and options to enable/disable 
various optional features.  --with-gnutls should be one such listed 

Then when you actually run the ./configure, you'll know what options to 
feed it to get the result you want, turning on or off such things as the 
optional spellcheck support, notifier support, ssl/gnutls support, etc, 
as well as where you want the various bits (docs, manpages, infopages, 
libraries, binaries, config-files... not all packages have them all) 
installed, if you don't like the defaults.  Generally the default install 
prefix is /usr/local, thus /usr/local/bin for binaries, 
/usr/local/share/man/man* for manpages, etc.  FWIW, most distros use 
simply /usr as their prefix for package-managed packages, so build with 
that prefix.  That leaves the default /usr/local for locally installed 
packages not managed by the distro's package-manager.

This is why I punted, saying I didn't have time to explain, earlier.  
Because there was more to explain than I had time for at the time...

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]