Thread: Small SSL-related patch...
Attached is a small patch that fixes a small "bug" with specifying the
souce directory of OpenSSL as argument to the --with-openssl - argument.
./configure --with-openssl=/tmp/openssl-0.9.5/ - the libcrypto.a is in the
"base" directory, not lib/.
Also, there's 2-3 typo fixes to the documentation for SSL - it should be
"server.crt", not "server.cert".
Thanks,
--
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
Attachment
Applied. Seems this is not longer mentioned in the docs. > > Attached is a small patch that fixes a small "bug" with specifying the > souce directory of OpenSSL as argument to the --with-openssl - argument. > > ./configure --with-openssl=/tmp/openssl-0.9.5/ - the libcrypto.a is in the > "base" directory, not lib/. > > Also, there's 2-3 typo fixes to the documentation for SSL - it should be > "server.crt", not "server.cert". > > > Thanks, > -- > Dominic J. Eidson > "Baruk Khazad! Khazad ai-menu!" - Gimli > ------------------------------------------------------------------------------- > http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/ Content-Description: [ Attachment, skipping... ] -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
(I thought I sent this before but my email has been shaky lately.) IMHO, it is not the task of the `--with-<package>' options to account for unusual installation paths on the build machine. We have --with-includes and --with-libraries for that, and we already rejected various other attempts to add more spellings of that. Now this patch doesn't actually add any options but it still opens a can of worms. Normal installation procedures (including that of OpenSSL!) install into PREFIX/lib and PREFIX/include, and I don't think that adding various other subsidary algorithms of finding the required files, in locations that are not sanctioned by the package in question, is going to do a lot of good. Bruce Momjian writes: > Applied. Seems this is not longer mentioned in the docs. > > > > > Attached is a small patch that fixes a small "bug" with specifying the > > souce directory of OpenSSL as argument to the --with-openssl - argument. > > > > ./configure --with-openssl=/tmp/openssl-0.9.5/ - the libcrypto.a is in the > > "base" directory, not lib/. > > > > Also, there's 2-3 typo fixes to the documentation for SSL - it should be > > "server.crt", not "server.cert". > > > > > > Thanks, > > -- > > Dominic J. Eidson > > "Baruk Khazad! Khazad ai-menu!" - Gimli > > ------------------------------------------------------------------------------- > > http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/ > Content-Description: > > [ Attachment, skipping... ] > > > -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Sat, 16 Sep 2000, Peter Eisentraut wrote:
> (I thought I sent this before but my email has been shaky lately.)
> IMHO, it is not the task of the `--with-<package>' options to account
> for unusual installation paths on the build machine. We have
> --with-includes and --with-libraries for that, and we already rejected
> various other attempts to add more spellings of that. Now this patch
> doesn't actually add any options but it still opens a can of worms.
> Normal installation procedures (including that of OpenSSL!) install
> into PREFIX/lib and PREFIX/include, and I don't think that adding
> various other subsidary algorithms of finding the required files, in
> locations that are not sanctioned by the package in question, is going
> to do a lot of good.
Ya know, I was gonna disagree with you here, basd on my experiences with
FreeBSD and its very non-instandard installation procedures ... as well as
my experiences with *alot* of packages out there that gratuitously allow
'--with-package=<location>' ... but, since we do have the
--with-{includes,libraries} options to configure, I think we do it so much
simpler then most ...
I'll side with you on this one ...
>
>
> Bruce Momjian writes:
>
> > Applied. Seems this is not longer mentioned in the docs.
> >
> > >
> > > Attached is a small patch that fixes a small "bug" with specifying the
> > > souce directory of OpenSSL as argument to the --with-openssl - argument.
> > >
> > > ./configure --with-openssl=/tmp/openssl-0.9.5/ - the libcrypto.a is in the
> > > "base" directory, not lib/.
> > >
> > > Also, there's 2-3 typo fixes to the documentation for SSL - it should be
> > > "server.crt", not "server.cert".
> > >
> > >
> > > Thanks,
> > > --
> > > Dominic J. Eidson
> > > "Baruk Khazad! Khazad ai-menu!" - Gimli
> > > -------------------------------------------------------------------------------
> > > http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
> > Content-Description:
> >
> > [ Attachment, skipping... ]
> >
> >
> >
>
> --
> Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
>
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Sat, 16 Sep 2000, Peter Eisentraut wrote:
> (I thought I sent this before but my email has been shaky lately.) IMHO,
> it is not the task of the `--with-<package>' options to account for
> unusual installation paths on the build machine. We have --with-includes
> and --with-libraries for that, and we already rejected various other
> attempts to add more spellings of that. Now this patch doesn't actually
> add any options but it still opens a can of worms. Normal installation
> procedures (including that of OpenSSL!) install into PREFIX/lib and
> PREFIX/include, and I don't think that adding various other subsidary
> algorithms of finding the required files, in locations that are not
> sanctioned by the package in question, is going to do a lot of good.
The only reason I did this, was because it made sense to me to be able to
do things like downloading the OpenSSL tarball, ./configure'ing and
make'ing OpenSSL (without doing a "make install", and then compiling PG
with --with-openssl, to get the SSL support. Of course this also assumed
that libpq would compile in openssl statically, so that libpq-wit-openssl
could function as drop-in replacement for the old libpq-without-openssl.
It seems this isn't the case, since I ended up getting unresolved symbol
errors for several SSL_* functions... Not sure if it was intended to do a
drop-in (w/o having to recompile applications, just replace libpq and
restart) or not.
FWIV, feel free to back out the patch.
--
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
Dominic J. Eidson writes: > The only reason I did this, was because it made sense to me to be able to > do things like downloading the OpenSSL tarball, ./configure'ing and > make'ing OpenSSL (without doing a "make install", Naaah, that doesn't work. You can't use packages right out of the source tree. Besides being unclean it's also unportable and unpredicable. > with --with-openssl, to get the SSL support. Of course this also assumed > that libpq would compile in openssl statically, so that libpq-wit-openssl > could function as drop-in replacement for the old libpq-without-openssl. > It seems this isn't the case, since I ended up getting unresolved symbol > errors for several SSL_* functions... Not sure if it was intended to do a > drop-in (w/o having to recompile applications, just replace libpq and > restart) or not. It probably should work that way but we haven't bothered to fix it yet. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Sun, 17 Sep 2000, Peter Eisentraut wrote: > Dominic J. Eidson writes: > > > The only reason I did this, was because it made sense to me to be able to > > do things like downloading the OpenSSL tarball, ./configure'ing and > > make'ing OpenSSL (without doing a "make install", > > Naaah, that doesn't work. You can't use packages right out of the source > tree. Besides being unclean it's also unportable and unpredicable. Okay, this one I will disagree with ... there are *several* packages out there that quite happily do that ... PHP4 is one, for its IMAP support, Ghostscript is another for its JPEG support, and, there is one more, but can't recall which it is, for its SSL support (I thought it was OpenSSH, but its been so long since I've built it) ... For PHP4, as an example, I have zero desire to taint my system with UofW IMAP, any more then I wish to have it tainted with MySQL ... so, I un-tar the sources, build it, and point PHP4 to the source directory to get its lib/headers for its build, and then delete the IMAP source tree ... For GS, ports under FreeBSD extracts the jpeg port, link's it to the gs port for the build process and then removes the jpeg port, without installing ... I've never tried it with anything else, as its never come up before ...
On Sun, 17 Sep 2000, The Hermit Hacker wrote:
> Okay, this one I will disagree with ... there are *several* packages out
> there that quite happily do that ... PHP4 is one, for its IMAP support,
> Ghostscript is another for its JPEG support, and, there is one more, but
> can't recall which it is, for its SSL support (I thought it was OpenSSH,
> but its been so long since I've built it) ...
Apache with apache-ssl/mod_ssl. (That being where I first encountered
compiling against a package's source install.)
--
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
Dominic J. Eidson writes: > Apache with apache-ssl/mod_ssl. (That being where I first encountered > compiling against a package's source install.) The point is that you are free to do anything you want, and the options are there. But I'm not so interested in instituting mechanisms that undermine another package's defined interface, which in case of OpenSSL is: $ ./config $ make $ make test $ make install If mod_ssl feels that they don't need to do that then that's their problem (and they probably know what they're doing because the packages essentially have the same maintainers and are effectively written specifically for each other). We on the other hand are not in a position to keep track of changing installation layouts and other oddities that might be going on with non-installed files, such as missing executable bits or shared-library paths. In fact, both of these are issues which will potentially prevent you from using OpenSSL without installing it anyway. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/