[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: |
bob |
Subject: |
Re: [Pan-users] ssl problems, not working on ports 443 or 563 |
Date: |
Mon, 2 Apr 2012 15:41:00 +0000 (UTC) |
User-agent: |
Pan/0.136 (I'm far too busy being delicious; GIT c91adc7 git://git.gnome.org/pan2) |
On Mon, 02 Apr 2012 05:17:06 +0000, Duncan wrote:
> 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 `autogen.sh --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 autogen.sh,
> 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 autogen.sh 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 option.
>
> 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...
Thanks Duncan...
I downloaded the gnutls and started to build it, but, it required nettle..
downloaded nettle to build it and found it required something else, which
I could not find. So, I gave up around 1.00 am CDT.
I was awakened by my next door neighbor at 8:00, as he had locked himself
out of his apartment, for which he had given me a key. Got that taken
care of, so here I am again.
Going to delete all the files in my working directory and re-populate it
and start over again, now that I have a better idea of what I am doing.
I just wish there was somewhere that I could find all these required bits
in one place. This reminds me of the C/PM days wherein each individual
computer brand had it's `own' version, and very little was movable
between different systems. I had to program the UART registers in 8 bit
binary, so I could use a 1200 baud Hayes Smartmodem. The manuals for that
system were contained in THREE Three inch, three ring binders, barely
translated from the original Japanese.
- Re: [Pan-users] ssl problems, not working on ports 443 or 563, (continued)
- Re: [Pan-users] ssl problems, not working on ports 443 or 563, bob, 2012/04/01
- Re: [Pan-users] ssl problems, not working on ports 443 or 563, Heinrich Mueller, 2012/04/01
- Re: [Pan-users] ssl problems, not working on ports 443 or 563, bob, 2012/04/01
- Re: [Pan-users] ssl problems, not working on ports 443 or 563, Duncan, 2012/04/02
- Re: [Pan-users] ssl problems, not working on ports 443 or 563,
bob <=
- Re: [Pan-users] ssl problems, not working on ports 443 or 563, Duncan, 2012/04/02
- Re: [Pan-users] ssl problems, not working on ports 443 or 563, Joe Zeff, 2012/04/02
- Re: [Pan-users] ssl problems, not working on ports 443 or 563, Duncan, 2012/04/03
- Re: [Pan-users] ssl problems, not working on ports 443 or 563, Joe Zeff, 2012/04/03
- Re: [Pan-users] ssl problems, not working on ports 443 or 563, bob, 2012/04/05
- Re: [Pan-users] ssl problems, not working on ports 443 or 563, Duncan, 2012/04/06