Ulf Moeller <[EMAIL PROTECTED]> writes:
> On Fri, Jul 09, 1999, Lenny Foner wrote:
>
> > autoconf work I've got, SSLeay compiled effortlessly under HPUX 9 and
> > 10, Solaris, NetBSD, Linux (4.2 and 5.1), Irix (32 and 64 bit), Alphas
> > (64 bit, or course) and probably some other OS's I'm forgetting---all
> > simply by typing ./configure and then make.
>
> With OpenSSL, you type ./config and then make. :)
>
> Most of the actual problems we have been having are caused by compiler
> bugs in the Sun, IRIX and HPUX compilers. I don't think autoconf would
> really have helped there. Correct me if I'm wrong, though.
with autoconf you can actually tell it to run arbitrary C code and see if
the resulting executable runs or not (for seriously fatal compiler bugs).
You can also check the exit code of a compiled program easily (for
invalid-code type compiler bugs).
You could do this withing Configure as well, but it is probably easier in
autoconf.
> > autoconf work in the Windows port? I'd hope not; I'd imagine instead
> > that something like CygWin would make this Just Work, but I've never
> > ever tried to build anything there.
>
> Sure, with CygWin, Unix script stuff Just Works, but having to install
> that is much more of a nuisance than just Perl (which I understand
> nowadays comes with the OS anyway).
Autoconf will supposedly work on windows in the next major release. Last I
heard at least. :)
> > Note in particular this line:
> > checking which DES optimizations to use... -DDES_RISC2 -DDES_PTR
>
> Nice, but in some cases it is better to actually know what you are doing
> than just pick some flags and try if it appears to work.
Why not actually run the tests and choose the one that is actually faster?
This way you do not have to add in a new config for compiler version n+1
where all of a sudden RC4_INT is better than RC4_CHAR (or whatever the
names are).
You could always special-case the very funky combinations (if any) where
the auto-detection fails to pick the right combination of options for
whatever reason.
Also, when you add a new OS or compiler to the list, it would 'just work'
instead of having to experiment yourself and figure out which one to use.
> Your autoconf log doesn't show signs of the more interesting parts of the
> OpenSSL config process such as testing for the CPU version of x86
> machines or creating the assembler files.
Checking the CPU version could be done through autoconf & the 'try to run
this program' type of tests. Generating the assembler files could be done
the way it is now - just run an external script.
Autoconf boils down to just raw shell script and handy M4 macros instead of
function calls (which are not portable to all shells unfortunately).
> There is a long list of checks. What would have happened if for example
> "ln -s" had failed or "strings.h" or "unistd.h" had not been available?
If strings.h is not found, then HAVE_STRINGS_H would not be defined in
openssl/opensslconf.h. Ditto for unistd.h and HAVE_UNISTD_H. If 'ln -s'
did not work, then in the makefiles that were created, the 'LN' variable
would be set to something appropriate... lemme check the source... it uses
just plain 'ln' if ln -s fails.
-bp
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
