On Wed, Jul 19, 2017 at 6:27 PM, Dr. Stephen Henson <steve@xxxxxxxxxxx> wrote: > Try linking with fipscanister.lib too: that's where those symbols are located. OK, I'd tried that before with no luck, but I tried harder. I found that if my lib line has the fips_premain.obj, then the fipscanister.lib, then the rest of the program's obj files and libs in exactly that order, the symbols are resolved. That's progress! Now I'm hitting the dreaded MSVCRT conflicts with use of other libs problem. Most of the application is compiled with /MT, but openssl-fips-2.0.16 is using /MD, could this be an issue? Can I/should I convince ms\do_fips to build against the multi-threaded runtime? It may also be other obj files causing the issue, the MSVC message is not so helpful, I'm continuing to look. I used /nodedefaultlib:msvcrt (even though its supposed to not be recommended) and I got a link of openssl-cli, though with lots of "LNK4049 locally defined symbol _exit imported", which sounds like its another symbol of /MT and /MD mismatch. I also almost got a link of node, but it died with fipscanister.lib(cryptolib.obj): error LNK2001: unresolved symbol __imp_wcsstr, and __imp___stdio_common_vsscanf, both of which sound suspiciously like a problem with the runtime compilation flags to me. Cheers, Sam -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
