Don't turn undefined symbols into an error

[kroeckx]

Clang does not seem to link to libasan when creating shared libraries.

Fixes: #8735

[extended tests]

[kroeckx]

So it seems #8537 introduces that -z defs things, and travis has been failing since.

[kroeckx]

At least for the msan case it seems we can't resolve this. It does not have a shared library we can link to, and the static library is not build using -fPIC and the name of that library depends on the architecture.

[levitte]

Hmm, what's up with Travis?

[levitte]

Also, how did the asan and msan stuff work before we ensured modules wouldn't be built without unresolved symbols?

[kroeckx]

The tests failing on travis already existed, this PR doesn't change that. Note that I've enabled extended tests. This fixes 3 of the 5 broken builds.

asan, ubsan and msan work just the same way as before we used that -z defs, by linking their library in the executable, not the shared library.

I'm not sure why this z defs was added. Did the provider pick up symbols from libcrypto.so, or did it also fail just at some later place?

[levitte]

asan, ubsan and msan work just the same way as before we used that -z defs, by linking their library in the executable, not the shared library.

Then it sounds like the problem lies there, that our shared libraries should be linked with the *san stuff when that's used.

I'm not sure why this z defs was added. Did the provider pick up symbols from libcrypto.so, or did it also fail just at some later place?

Most importantly, the FIPS provider module shouldn't pick up stuff that the application is linked with by accident. That completely defeats the purpose of it being self contained. We extended that to all modules, with the thought that for any external symbol, they should be explicitly linked with the needed libraries, not piggy-back on whatever the application is linked with (which is a recipe for failure anyway, since you can't be sure that the application is linked with all the module needs)

[kroeckx]

> asan, ubsan and msan work just the same way as before we used that -z defs, by linking their library in the executable, not the shared library. Then it sounds like the problem lies there, that our shared libraries should be linked with the \*san stuff when that's used.

Like pointed out above, I can fix that for asan and ubsan, not for msan.

[levitte]

https://clang.llvm.org/docs/MemorySanitizer.html confirms that one should not combine -z defs with msan. So that essentially means that we should not use that flag specifically when msan is enabled. Removing -z defs unconditionally is counter-productive, though.

[kroeckx]

If you have an other suggestion, feel free to open an other PR.

[levitte]

I will look tomorrow. Way too late tonight