[openssl-users] OpenSSL 1.0.2.f undefined reference: _Stoul

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Craig_Weeks at trendmicro.com
> Sent: Tuesday, October 18, 2016 14:05
> 
> Ok, I see *how* this is happening, but I don't understand why.  In the
> version of stdlib.h that I am including I see:
> [omitted] 
> 
> So, for C code this header maps strtoul() (see parse_tagging() in
> crypto/asn1/asn1_gen.c for an example) to _Stroul().  That is definitely
> "helping" me more than I want but I don't know how to make it stop.

This looks like a conflict between your standard C headers and standard C library - that is, it appears the former came from one source, and the latter from another (or a sufficiently-different version).

strtoul is defined by the C standard. It's part of the standard library. However, an implementation can provide it as a macro (with some caveats I won't get into). stdlib.h is also defined by the C standard.

In this case, you have a stdlib.h which defines strtoul as a function-like macro that becomes an invocation of the function _Stoul. That function is not defined by the C standard, but it's in a part of the namespace that's reserved to implementors, so we can guess that it's part of the implementation this stdlib.h comes from.

However: You're building on a system that splits the C standard library up into header and library components. (Most do, but it's possible to conform to the standard using other arrangements.) And whatever your build system is finding to be the linkage component of the C standard library does not implement this _Stoul.

So OpenSSL is building with C library headers that don't match the C library linkage library. (On Windows, the latter would be either a static library or an import library - a .LIB file of some sort. On Linux and UNIX platforms, it would be a shared object or library of some sort - most often an ELF shared object, though AIX, for example, uses an archive library containing XCOFF shared objects.) The most likely cause is conflicting software installed on your system, but it may be that the OpenSSL Configure process is locating the wrong files due to some environmental quirk in your setup.

Historical note: The name "_Stoul" suggests your stdlib.h is descended from the one written by P. J. Plauger, one of the major players in C and C++ standardization:

http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/CUJ/1992/9205/plauger/plauger.htm

Plauger's implementation is widely used by commercial C implementations. GCC, however, has its own C library implementation, which does not have a "_Stoul". So perhaps you're compiling with vendor-supplied headers and linking against glibc?

Here's a quick test. See if this compiles and runs successfully, using the machine and toolchain you're using for OpenSSL:

	#include <stdlib.h>
	int main(void) {return strtoul("0", NULL, 10);}

If that complains about a missing _Stoul, you have the same problem as the OpenSSL build is seeing in your environment. If it works, then your environment is OK, and OpenSSL Configure picked up something weird. EIther way it may help you isolate the issue.

Michael Wojcik 
Distinguished Engineer, Micro Focus