Remove a binding causing compilation issues

[reaperhulk]

CRYPTO_malloc_debug_init has caused us quite a bit of heartache (from FreeBSD ports to mysterious OS X issues). We're not using it and pyOpenSSL isn't using it either so I propose we just remove it for now.

This is technically a backwards compatibility break (albeit almost certainly not one that will affect anyone), so arguably we should list it in the changelog.

If others have a better idea for resolving this speak up!

[jenkins-cryptography]

Test PASSed.
Refer to this link for build results: https://jenkins.cryptography.io/job/cryptography-pr-experimental/2875/

[public]

I don't think we can commit to supporting the entire OpenSSL API :)

[Ayrx]

I think we should list it in the CHANGELOG. Otherwise +1 on this.

[alex]

I'm not wild about removing something without understanding why. ISTM it's not unlikely that the result is that on these platforms some other binding complains.

[koobs]

@alex It was causing test failures (on FreeBSD), so I couldn't QA recent updates to keep the Port up to date. Happy to provide the errors here if you need more info, I provided @reaperhulk with a login to the machine last week to investigate.

[reaperhulk]

Closing this as the underlying cause isn't the binding.

[alex]

@reaperhulk can you share what the underlying cause was?

[reaperhulk]

@public and @dstufft are probably better equipped to answer this

[dstufft]

FreeBSD does it's install in two steps which can be summarized as python setup.py build <build args> && python setup.py install <install args>. In Python calling python setup.py install also calls python setup.py build but generally distutils attempts to detect if it needs to build the .sos again and bails out early if not. However cffi doesn't actually check if it needs to write the file out, it just records that it wrote the file to an in memory location. This means that two successive invocation of setup.py build_ext (implicitly via build and install) will both write the file even if it it's going to just write the exact same data. This causes distutils to see that the .c file is newer than the .so file and will recompile it. Combine that with the fact that FreeBSD only passes the build options to the python setup.py build command when distutils attempts to compile it a second time when running python setup.py install it doesn't get the correct build options and looks in the wrong folders for things.

[Ayrx]

Does this explain that reported OS X failure as well?
On Fri, 30 Jan 2015 at 6:14 am Donald Stufft notifications@github.com
wrote:

FreeBSD does it's install in two steps which can be summarized as python
setup.py build && python setup.py install . In
Python calling python setup.py install also calls python setup.py build
but generally distutils attempts to detect if it needs to build the .sos
again and bails out early if not. However cffi doesn't actually check if it
needs to write the file out, it just records that it wrote the file to an
in memory location. This means that two successive invocation of setup.py
build_ext (implicitly via build and install) will both write the file
even if it it's going to just write the exact same data. This causes
distutils to see that the .c file is newer than the .so file and will
recompile it. Combine that with the fact that FreeBSD only passes the build
options to the python setup.py build command when distutils attempts to
compile it a second time when running python setup.py install it doesn't
get the correct build options and looks in the wrong folders for things.

—
Reply to this email directly or view it on GitHub
#1635 (comment).

[dstufft]

No idea.