Thanks Andy, Yes, there is a discrepancy between the standard cross-compiler we use and the fact that we currently still use libc_r, in that "-pthreads" resolves to -lpthread. For our builds the -pthread option is not used so it never came up, but to use the cross-compiler to build FIPS module and libcrypto for the platform it is of course an issue. In the future we will move to libpthread, but I have to resolve this issue now to prep for change letter validation.
>From what I can tell, the specs file is "built-in" to gcc. Yes I can look at it with -dumpspecs, and I can override it with, e.g., -specs=myspecs, but then I am back to having to modify Configure script (and config to point to a new unique platform. I don't think gcc automatically loads a specs file from some known location - it uses what is built into it or what is specified with the -specs option. Maybe there is another way? I'm getting resistance here about changing the cross-compiler itself because of our eventual switch to libpthread. Kevin On Wed, Jun 27, 2012 at 10:31 AM, Andy Polyakov <[email protected]> wrote: > > 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] >
