[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openssl-users
Subject:    Re: [openssl-users] OpenSSL 1.0.2.f undefined reference: _Stoul
From:       Michael Wojcik <Michael.Wojcik () microfocus ! com>
Date:       2016-10-18 22:05:39
Message-ID: B550B44BF8AF314BB00C4E2AC1C18088015E6ABEEE () prvxmb03 ! microfocus ! com
[Download RAW message or body]

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



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


[prev in list] [next in list] [prev in thread] [next in thread]