> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of craig_we...@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 

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++ 


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 

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 

openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Reply via email to