Need help with OpenSSL static library

[Olivier Mascia]

> Le 13 mars 2023 à 13:16, Jonathan Day <dayjonathanc at gmail.com> a écrit :
> 
> > > > specification warning LNK4098: defaultlib 'MSVCRT' conflicts with use
> > > > of other libs; use /NODEFAULTLIB:library LINK : warning LNK4217:
> > > > symbol '__time32' defined in 'libucrtd.lib(time.obj)' is imported by
> > > 'libcrypto_static.lib(libcrypto-lib-http_client.obj)' in function
> > > '_OSSL_HTTP_REQ_CTX_set_request_line'
> > > > LINK : warning LNK4286: symbol '__time32' defined in
> > > > 'libucrtd.lib(time.obj)' is imported by 'libcrypto_static.lib(libcrypto-lib-
> > >> bss_conn.obj)'
> > > > LINK : warning LNK4286: symbol '__time32' defined in
> > > > 'libucrtd.lib(time.obj)' is imported by 'libcrypto_static.lib(libdefault-lib-
> > > drbg.obj)'
> > > > LINK : warning LNK4217: symbol '__time32' defined in
> > > > 'libucrtd.lib(time.obj)' is imported by 'libcrypto_static.lib(libcrypto-lib-
> > > bio_lib.obj)' in function '_BIO_do_connect_retry'
> > >
> > > Looks like some part was compiled with '-MDd' and some other parts
> > > (the .libs?) with '-MTd'.
> > 
> > Yes, or -MD (or /MD) versus -MT, or some other combination thereof. It's some
> > form of mixed MSVC runtimes, which is what the LNK4098 message is
> > warning you about.
> 
> I've tried various options without much success, but I'll keep trying. Does anyone on the list know the specific flag that OpenSSL's static library compiles under?
> 
> I'm puzzled as to how fixing that would fix the errors (the missing functions), but it's possible Visual Studio is getting confused.
> 
> The code I have is compiled both as a debug version (/MTd) and a release version (/MT) and both produce the same errors. So if this is the problem then OpenSSL must be compiled under one of the other two. That's going to be a problem. But an understood problem is easier to solve than one that's not understood!

I never had issues building some of my utilities as fully statically linked, linking in the static libraries, instead of the import libraries.
You have to ensure you're giving proper link inputs to the linker settings in your project, or to add #pragma comment (lib,...) pointing at the right libraries.
I always build my own OpenSSL binaries, using the stock untouched OpenSSL build procedure.

Here is what looks the comment lib instructions in one (only one) of my source code files. Of the paths and names where to pick the right libraries are specific to my build process.

	#ifdef _DLL
		#pragma comment (lib, "openssl/x64/libssl.lib")
		#pragma comment (lib, "openssl/x64/libcrypto.lib")
	#else
		#pragma comment (lib, "openssl/x64/static/libssl.lib")
		#pragma comment (lib, "openssl/x64/static/libcrypto.lib")
	#endif

_DLL will be defined when compiling /MD or /MDd.
It will be undef when compiling /MT or /MTd.

nasm is out of the problem. It works well and you need it to get decent builds accelerated through some key algorithms implemented through assembler.

Part of my own personal recipe for building OpenSSL looks like this.
The pristine source code into \osrc.
Empty \obuild, \odll and \ostatic directories.

Then with a freshly opened command prompt, set yourself into the \obuild directory and initialize the environment properly for Visual Studio build tools.

"C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Auxiliary\Build\vcvars64"

The exact path to that batch file, provided by Microsoft (for amd64 builds on amd64 host) has to be adjusted according to your own configuration.
You also need nasm, default install and Strawberry Perl distribution, usually into C:\Strawberry and properly setup into your default path.

Then, as instructed by the OpenSSL build instructions, which are perfectly correct,  follow or adjust the following which are merely my very own settings.
(I use "no-deprecated" but it is not required as it might not fit your needs).

perl \osrc\Configure VC-WIN64A --openssldir=C:\ProgramData\OpenSSL no-deprecated
nmake
nmake test
nmake DESTDIR=\odll install_sw

And you collect the appropriate resulting pieces from the \odll tree.


To built the static versions after all the above, please EMPTY the \obuild directory, close your prompt and reopen a new one, into the \obuild directory again.

"C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Auxiliary\Build\vcvars64"
perl \osrc\Configure VC-WIN64A --openssldir=C:\ProgramData\OpenSSL no-shared no-deprecated
nmake
nmake test
nmake DESTDIR=\ostatic install_sw

And you collect the appropriate resulting pieces from the \ostatic tree.

The key point here is to use the "no-shared" option to drive the build process into building the static versions and not the DLL versions.
Again no-deprecated is a matter of choice.

Keep in mind that your runtime library issue might come from incorrect and competing settings (/MT, /MD) in any portion of your code or other libraries you link. It might not be related to OpenSSL itself.

-- 
Olivier Mascia

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230313/99f4c6e8/attachment-0001.htm>