#621 closed defect (fixed)
OpenSSL install locations generally unrecognized
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | BOOK | Version: | ~5.0 |
| Severity: | minor | Keywords: | |
| Cc: |
Description
The OpenSSL install locations, /usr/include/openssh and /usr/lib, are completely nonstandard (although standards-compliant) and therefore every single program which wants to use SSL requires a configure option to find it. Even worse, because the includes and libraries are not at equal subdirectory levels from /usr, if configure does not have TWO options, one for the includes and one for the libs, sometimes even specifying --with-openssl=/usr is no help (this occurs, for example, with bind-9.2.2).
I am not an advocate for standards-noncompliance, but I think some symlinks should be created in, say, /usr/share/openssl/{lib,include} so that a single prefix may be specified.
Change History (5)
comment:1 by , 20 years ago
comment:2 by , 20 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
I was thinking specifically of bind; I tried to configure it yesterday and it failed most dramatically to find SSL until I make the symlinks in /usr/share/openssl. Strangely, it works today. One could argue that the configuration option shouldn't be necessary in that or the other cases, but it's not worth it.
comment:3 by , 20 years ago
Check the INSTALL file in the openssl source dir. It talks specifically about *not* installing/symlinking headers in /usr/include.
comment:4 by , 20 years ago
It does not, in fact, say this (at least not in mine, but I installed 0.9.7a; maybe newer versions do). What it does say is that the includes were placed in include/openssl to avoid naming conflicts with headers in include, and I'm not advocating smylinking them to headers in include. I suggested that a directory such as /usr/share/openssl be made with lib and include subdirectories that contained links to the libs and headers, so that programs which, for some reason, were unable to find these things because the includes were in include/openssl, would be able to be directed to a single parent directory that has the expected tree structure.
"every single program which wants to use SSL requires a configure option to find it"
OpenSSH - no OpenLDAP - no Bind - no wget - no NTP - no Apache - no
I don't know of a program that can't find SSL in the configure process, some need --with-ssl to look for it, but I don't recall having to declare the lib location on any install. Can you point one out for me?