> both the FIPS module and OpenSSL use the -pthreads option for gcc when
> building a *BSD/x86 target. With our cross-compiler, -pthreads results
> in "-lpthread", although on our target we actually use libc_r for thread
> support. While sorting out how I can resolve this in the
> config/Configure scripts, I have been wondering why the thread library
> is even needed to build a libcrypto containing the FIPS Module. Yes,
> openssl provides multi-threading support, through the use of callbacks
> set by an application. But I haven't seen any code that uses the
> libpthread or libc_r API. If an application requires multithreading, it
> will itself link in libc_r and libcrypto. But I don't understand why I
> need that dependency built into libcrypto...

-pthreads not only links with additional/alternative library but even
can define a macro that might redefine some interface. *For example* on
Solaris it changes 'errno' to '*(___errno())'. Former is single global
variable, which is not multi-thread safe, while latter refers to
thread-specific variable. It's perfectly possible [and appropriate] to
use MT variant even in single-threaded application, but not vice versa.
And therefore if one wants to have libcrypto.a that can be used in
either context, multi- or single-threaded application, then it should be
compiled with -pthreads. This is the reasoning for why. Note that *your*
application doesn't have to be compiled/linked with -pthreads. At least
no problems were ever reported that would indicate otherwise.

As for -lpthread vs. -lc_r and what's right for your target
cross-compiled platform (right?). Sounds like your cross-compiler
doesn't do right. In such case Configure is probably not right place to
solve this specific problem, gcc specs file is. I mean when gcc runs, it
looks for specs file, which describes how different compiler options are
threated, -pthreads included. You can examine current specs by running
gcc -dumpspecs.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [email protected]
Automated List Manager                           [email protected]

Reply via email to