> It would obviously not be hard to write a set of stubs for these
> things, getting those stubs called selectively in the "no real RSA"
> case also not being very difficult. One way would be to put them in a
> lower version-numbered shared lib, like OpenBSD did it, so that the
> application would fall through to link against the stub version if
> librsaref.so.2 was not found. Another, better way, would be to use
> weak symbols and a dlopen(), e.g.:
[snip]
> That way it's not an error to link against the openssl library without
> librsa, though if you do link with -lrsa and -lssl then you can also
> skip the stubs entirely and not encur the dlopen() overhead, something
> which makes the -static (or stand-alone) linkers happy.
I'm not familiar with OpenSSL's link lines, but here's a question.
Are linking with -lrsa and -lssl normally necessary, or is it normally
just -lssl? If it't the latter, then programs that expect to link
against OpenSSL will succeed to build and link, but fail to run
properly. I realize that every OS has its quirks for building
packages, but I find this sort of change vulgar.
Naturally, if OpenSSL-based programs *expect* to build against -lrsa
and -lssl, then I have no objections.
joelh
--
Joel Ray Holveck - [EMAIL PROTECTED]
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
