update wheel builder script for static linking on linux

[reaperhulk]

We don't need to do an LD_LIBRARY_PATH when calling auditwheel because we're now statically linking OpenSSL.

This is blocked on:

• switch to building static libs for cryptography wheels infra#120
• ARCH is not propagating to the install_openssl script properly infra#121

We should consider doing a 2.0.1 for this probably.

[mention-bot]

@reaperhulk, thanks for your PR! By analyzing the history of the files in this pull request, we identified @alex to be a potential reviewer.

[alex]

Can you please explain how this PR works? Shouldn't we have to use SUPRESS_LINK_FLAGS?

[reaperhulk]

I honestly don't understand how static linking works on Linux. I actually used the documentation @Lukasa wrote up in our docs to do this and then confirmed that _openssl.so wasn't linked against libssl or libcrypto via ldd. It makes sense that we would want to suppress linker flags like we do on macOS, but maybe that's unnecessary (or maybe this is only working via coincidence). Sorry to do this again, but cc @njsmith (sorry Nathaniel!)

[njsmith]

What's SUPPRESS_LIBRARY_FLAGS?

[alex]

Some gibberish we invented: https://github.com/pyca/cryptography/blob/master/src/_cffi_src/build_openssl.py#L15-L36

[njsmith]

I think you want to not set SUPPRESS_LIBRARY_FLAGS on Linux. Right now you're eventually passing -lcrypto -lssl to the linker, and so it's looking for libcrypto.so.X or libcrypto.a, finding the latter, and linking it on. Likewise for libssl. You could stop passing those, but then you'd need to have some other way to get the information to the linker that you want to link to openssl. Which is possible and I guess must be what you're doing on Darwin for some sensible reason that I don't know about, but why jump through those hoops?

... It does randomly occur to me that you might want to double check that your static openssl is being built with -fPIC, but that's unrelated.

[reaperhulk]

On macOS the easiest way we found to get static linking was just to pass absolute paths to the .a files themselves. We are building with fpic (https://ci.cryptography.io/blue/rest/organizations/jenkins/pipelines/pyca/pipelines/infra/branches/master/runs/131/nodes/51/steps/553/log/?start=0)

…

On Jul 25, 2017, at 3:33 PM, Nathaniel J. Smith ***@***.***> wrote: I think you want to not set SUPPRESS_LIBRARY_FLAGS on Linux. Right now you're eventually passing -lcrypto -lssl to the linker, and so it's looking for libcrypto.so.X or libcrypto.a, finding the latter, and linking it on. Likewise for libssl. You could stop passing those, but then you'd need to have some other way to get the information to the linker that you want to link to openssl. Which is possible and I guess must be what you're doing on Darwin for some sensible reason that I don't know about, but why jump through those hoops? ... It does randomly occur to me that you might want to double check that your static openssl is being built with -fPIC, but that's unrelated. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[alex]

I did not realize that -l would hapilly look for either a .so OR a .a this makes sense to me now.

[njsmith]

pass absolute paths to the .a files themselves.

You can do that too. I believe that the only difference is that -l triggers the library search logic, so you might prefer to pass absolute paths if you don't trust the search logic.