Hi there,
On Fri, 8 Dec 2000, Forrest Aldrich wrote:
> I wasn't able to get our port to compile correctly (emailed the
> maintainer), however I was able to compile manually. When I run apache, I
> get:
>
> [Fri Dec 8 19:42:44 2000] [warn] pid file /var/run/httpd.pid overwritten
> -- Unclean shutdown of previous Apache run?
> /usr/libexec/ld-elf.so.1: /usr/apache/sbin/httpd: Undefined symbol
> "sk_X509_NAME_ENTRY_num"
This function disappeared when the "safestack" macros were changed to
generate typesafe casts rather than function wrappers. The former does
code checking in the precompiler, the latter generates a new function in
the output with its own prototype which then uncovers attempted type
violations later on.
Basically, it looks like you're trying to load a shared library that was
compiled with a version of OpenSSL before that change was made. As such,
it is expecting to use all the little macro-generated wrapper functions
that no longer exist. In particular, it looks like some part of your code
is not being recompiled against the latter OpenSSL release - or perhaps it
is including headers from some other location which has the older
safestack code?? (Often happens when compiling a newer OpenSSL when an
older one, complete with headers, is installed somewhere in system visible
locations).
Don't just recompile OpenSSL - recompile the code that uses it and ensure
that it is including the newer headers as well as linking against the
newer libraries (either statically or dynamically).
> I understand the httpd.pid part :)
>
> This is applicable to openssl-0.9.5a. I tried recompiling everything to
> ensure that all was compiled against the system libs (buildworld
> today). "make test" runs fine without problems.
OpenSSL itself seems to be recompiled fine, because you no longer have an
sk_X509_NAME_ENTRY_num symbol :-) The problem is the code that was
previously linking to that symbol also needs recompiling against the newer
headers to realise that sk_X509_NAME_ENTRY_num is now a macro;
#define sk_X509_NAME_ENTRY_num(st) SKM_sk_num(X509_NAME_ENTRY, (st))
which thanks to another macro;
#define SKM_sk_num(type, st) ((int (*)(const STACK_OF(type) *))sk_num)(st)
results in binary output which actually expects to link against a symbol
called "sk_num" - which is now the only "_num" stack function that is
generated in binary output. This spaghetti is necessary so that we can
have type-specific stacks that give compilation errors when accidently
using incompatible types, but don't require generating type-specific
functions for each possible stack type (which is what was done before).
Something you're running hasn't been recompiled with this change but is
trying to link (dynamically) against a version of OpenSSL that has.
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]