On Fri, Apr 23, 1999 at 12:38:45AM +0200, Anonymous wrote:
> Other libraries & tools live happily together in /usr/local/{bin,lib,include}.
> I think openssl should, too. Then there are no symbolic links, no empty
> directories, the openssl binary is available in /usr/local/bin which is
> already in users' paths, and if the includes are in /usr/local/include/openssl
> (a la /usr/local/include/X11) it'll make sense and avoid future conflicts too.
$ ls -l /usr/include/X11
lrwxrwxrwx 1 root root 20 Apr 10 01:35 /usr/include/X11 ->
../X11R6/include/X11/
/usr/local/include/openssl avoids future conflicts only if all
recursive #include-s use <openssl/foo.h> and not <foo.h> (which would
also be outright silly when the files are put into that directory).
The only way to compile the library if it has <openssl/foo.h>
everywhere is with an all-but-empty directory ./include and all the
files (or links) in ./include/openssl/. Now whether
/usr/local/include/openssl is a link or a directory with copies of all
the files doesn't really make a difference, what counts is that the
name-space makes sense.
For old code that does not work with that path, all you have to do is
add an -I compiler option pointing to a directory where the header
files can be found directly. That shouldn't be too hard.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
