windows - "The Ordinal 112 could not be located in dynamic link library..."

Question

The Whole Error is as follows: " The ordinal 112 could not be located in the dynamic link library D:GNU-C-compilerGNUstepinopenssl.exe "

i've been searching around a lot on the web for a solution to no avail. I recently started getting into encryption using OpenSSL however during the process of installation i installed multiple different version of the software for testing but during my deletion of these other versions i just deleted the folder instead of doing the proper uninstall procedure (the openssl program saves some dll's into the windows system directory so these multiple dll's were kept). Thus i believe that these extra dll's are the source of the problem (maybe) but i cant find a way to easily uninstall them and so i am asking for a reasonable solution to this problem.

Answer 1

“The Ordinal 112 could not be located in dynamic link library…”

I'm speculating its SSLv23_server_method or BN_MONT_CTX_free from OpenSSL 1.0.2; or RSA_PSS_PARAMS_free or SSL_CONF_CTX_clear_flags from OpenSSL 1.1.0. Based on some recent changes, I'm guessing its OpenSSL 1.0.2 and SSLv23_server_method.

# OpenSSL 1.1.0
$ find $PWD -type f -iname '*.num' -exec grep " 112" {} ;
RSA_PSS_PARAMS_free                     112 1_1_0   EXIST::FUNCTION:RSA
SSL_CONF_CTX_clear_flags                112 1_1_0   EXIST::FUNCTION:
...

# OpenSSL 1.0.2
$ find $PWD -type f -iname '*.num' -exec grep " 372" {} ;
BN_MONT_CTX_free                        112 EXIST::FUNCTION:
SSLv23_server_method                    112 EXIST::FUNCTION:RSA
...

You will need to verify it by using dumpbin or Dependency Walker. Also see How can I find the exported function name from ordinal (export by ordinal)? on Stack Overflow.

---

The ordinals are created using <openssl src>utilmkdef.pl. You can see the source code from OpenSSL's GitHub presence. Here is 1.0.2 and here is 1.1.0.

Here are the head comments for the file:

#!/usr/local/bin/perl -w
#
# generate a .def file
#
# It does this by parsing the header files and looking for the
# prototyped functions: it then prunes the output.
#
# Intermediary files are created, call libcrypto.num and libssl.num,
# The format of these files is:
#
#   routine-name    nnnn    vers    info
#
# The "nnnn" and "vers" fields are the numeric id and version for the symbol
# respectively. The "info" part is actually a colon-separated string of fields
# with the following meaning:
#
#   existence:platform:kind:algorithms
#
# - "existence" can be "EXIST" or "NOEXIST" depending on if the symbol is
#   found somewhere in the source, 
# - "platforms" is empty if it exists on all platforms, otherwise it contains
#   comma-separated list of the platform, just as they are if the symbol exists
#   for those platforms, or prepended with a "!" if not.  This helps resolve
#   symbol name variants for platforms where the names are too long for the
#   compiler or linker, or if the systems is case insensitive and there is a
#   clash, or the symbol is implemented differently (see
#   EXPORT_VAR_AS_FUNCTION).  This script assumes renaming of symbols is found
#   in the file crypto/symhacks.h.
#   The semantics for the platforms is that every item is checked against the
#   environment.  For the negative items ("!FOO"), if any of them is false
#   (i.e. "FOO" is true) in the environment, the corresponding symbol can't be
#   used.  For the positive itms, if all of them are false in the environment,
#   the corresponding symbol can't be used.  Any combination of positive and
#   negative items are possible, and of course leave room for some redundancy.
# - "kind" is "FUNCTION" or "VARIABLE".  The meaning of that is obvious.
# - "algorithms" is a comma-separated list of algorithm names.  This helps
#   exclude symbols that are part of an algorithm that some user wants to
#   exclude.