> From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of
> Gisle Vanem
> Sent: Friday, 10 March, 2023 06:11
>
> Jonathan Day wrote:
>
> > This generates a whole series of warnings and errors. I've only included the
> first few of each.
> >
> > warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO'
This is unrelated to the problem. The easy fix is to get rid of /EDITANDCONTINUE, which in my opinion doesn't add much value anyway.
> > 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.
Microsoft's C implementation is horrible in a number of ways, and this is one. They offer multiple versions of the language runtime and they cannot be mixed (generally speaking) or Bad Things Happen. Linker errors are one of the better outcomes.
Earlier versions of OpenSSL, when asked to build static libraries on Windows, would link with the static MSVC runtime. This makes a certain amount of sense but was a problem if, say, you wanted to link OpenSSL statically into a program or DLL that was using the dynamic MSVC runtime, which is generally preferred for the usual reasons.[1]
The same may be true of 3.0; that is, it appears libcrypto_static.lib is linked against the static MSVC runtime. I haven't been directly involved in my team's recent move to 3.0, so I don't know the details.
We changed the OpenSSL 1.x Windows builds to create static libraries linked against the appropriate MSVC runtime ("appropriate" meaning "what we were using for our code"). We may have done the same for 3.0, or there may already be an OpenSSL configure option for it.
[1] Those would be smaller image size, possibility of code-page sharing, incorporating future fixes to the runtime without having to relink and redeliver your module. Though the first doesn't matter much because it's smaller on disk, but disk is cheap, and not smaller in memory; the second because the Windows PE loader often fails to share code; and the third because Microsoft's awful SxS mechanism means your program is probably stuck with whatever version of the runtime you originally linked with. Oh, well. It's not like shared libraries were a solved problem before Microsoft ever got in that game or anything. And let's not even mention linking by ordinal.
--
Michael Wojcik
