<div dir="ltr">OK I see, thanks.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 1, 2020 at 6:27 PM Matt Caswell <<a href="mailto:matt@openssl.org">matt@openssl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">liblegacy.a is an internal artifact! You're not supposed to link your<br>
applications against it!<br>
<br>
You are supposed to link against libcrypto normally. If legacy.so isn't<br>
in the default install location then make sure the OPENSSL_MODULES<br>
environment variable is pointing at its directory.<br>
<br>
Matt<br>
<br>
<br>
On 01/05/2020 17:14, Guido Vranken wrote:<br>
> When I configure using "./config enable-legacy" it creates<br>
> providers/liblegacy.a, then in the program I link with it,<br>
> OSSL_PROVIDER_load fails (returns NULL).<br>
> <br>
> When I configure using "./config enable-legacy -static" it works as<br>
> expected.<br>
> <br>
> However, building with -static fails on OSS-Fuzz when building with<br>
> sanitizers, and I need the .a file instead of the .so file for fuzzing.<br>
> <br>
> So, is it possible to configure using "./config enable-legacy" and have<br>
> a working liblegacy.a? Is this a bug?<br>
> <br>
> Thanks<br>
</blockquote></div>