Closed BarryBo closed 6 years ago
Wow, that looks like a lot of trouble. mitls.exe built just fine on my WSL (my main environment these days), so I'm surprised you needed to make changes to libmipki. We may be using different version of gcc or similar.
Looks good to me except for the bit about the space
variable which I don't understand either.
I hit a number of issues linking and using .so files on Bash for Windows running Ubuntu.
libmipki.so was linked without -lcrypto, leaving it with unresolved symbols. That meant that every app that linked against libmipki.so also had to link in our build of OpenSSL libcrypto*.so.
libmipki.so was linked without -lpthread, again, leaving it with unresolved symbols. However, just passing -lpthread when building cmitls.exe didn't work... got a mysterious error about pthread_at_fork being hidden. Turns out libmpki.so and cmitls.exe cannot both share the same binding to libpthread.so. Same fix as libcrypto*.so... link libmipki.so against libpthread.so.
pass -Wl,-z,defs to catch accidental missing symbols in the future
tidy up how the test apps were build and run, so they can directly reference .so files in-place, without needing to copy them, both for linking and to run.
I confirmed that these changes still work on Cygwin.
EDIT: Sigh. No, the mingw linker doesn't like the -z switch after all. I missed the error when I built on Cygwin. Will refactor it out into a !Cygwin path.
EDIT: Neither Cygwin nor OS/X versions of ld support -z, so I made the change Linux-specific.