Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

On Mac, target macOS 10.9 when possible (fixes build on XCode 10+) #13

Merged
merged 1 commit into from
Apr 13, 2021

Conversation

JoshRosen
Copy link
Contributor

This patch aims to fix an issue where python-sasl cannot be compiled with newer versions of XCode. In particular, this library fails to compile out-of-the-box on OS X Mojave (see cloudera/thrift_sasl#15).

The problem seems to be related to missing stdlibc++ headers, which are not installed by default in XCode 10+.

To fix this issue, I copied changes from pandas-dev/pandas#24274 (with proper attribution). Quoting from that patch description:

For extension builds, distutils targets the same macOS version as python was built for, even if the host system is newer. This can cause problems when building on a 10.9+ system, with a python built for <10.9. Targetting macOS <10.9 sets the c++ standard library to stdlibc++, which was deprecated in 10.9 in favour of libc++. Starting with Xcode 10, stdlibc++ is no longer installed by default, so isn't guaranteed to be available. This can be an issue with the current 64/32b universal builds of python, which target macOS 10.7.

Another reason to do this is to move over to 10.9 / libc++ where possible, as the current 64-bit builds of python have done.

This worked for me and I think it's a simpler approach than some of the other workarounds suggested in cloudera/thrift_sasl#15 and hkwi/python-geohash#27 because it doesn't require the installation of additional headers or commandline tools. I have little experience with native code builds, however, so please chime in if I'm overlooking something.

Copy link
Contributor

@wesm wesm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks OK to me. Who is maintaining this now and can make a release, @timarmstrong @toddlipcon?

@timarmstrong
Copy link

I think @lekv was investigating a release.

@lekv
Copy link

lekv commented Mar 6, 2019

Yes, I'm planning to put together a new release in the next days. I'm still figuring out the process and probably will put up a RC beforehand so everyone can have a look at it.

@jrkinley-zz
Copy link

I've just hit this issue. Is there an RC available @lekv?

@lekv
Copy link

lekv commented Apr 17, 2019

We've just released version 0.15.0 and it's available on pypi.

@JoshRosen
Copy link
Contributor Author

JoshRosen commented May 15, 2019

HI @lekv,

Could you point me to the PyPI listing page for the 0.15.0 release of sasl?

From https://pypi.org/project/sasl/ it looks like there hasn't been a new release. Are you sure you were referring to this library and not a different one in your comment? Edit: looks like you were referring to an Impyla release, not this library.

I'm bumping this because it sounds like this is still a problem for thrift_sasl users, some of whom are resorting to installing from my branch rather than an official PyPI release: cloudera/thrift_sasl#15 (comment)

@jrkinley-zz
Copy link

Hi @lekv, I'm still having to install from @JoshRosen's branch. Please can we get an official fix on pypi?

@lekv
Copy link

lekv commented Nov 22, 2019

I confused this one with impyla. However, pip install sasl works for me on Mojave in a fresh venv with both python2 and python3 and outside of a venv. How are you trying to install it?

Tagar added a commit to sparkur/python-sasl3 that referenced this pull request Nov 29, 2019
@Tagar
Copy link

Tagar commented Nov 29, 2019

https://pypi.org/project/sasl3/
incorporates this PR

@VincentBLortie
Copy link

@lekv pip install sasl in a fresh venv running Python 3.7.0, on MacOS 10.14.6 gives me:

    warning: include path for stdlibc++ headers not found; pass '-stdlib=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
    sasl/saslwrapper.cpp:249:10: fatal error: 'string' file not found
    #include <string>
             ^~~~~~~~
    1 warning and 1 error generated.
    error: command 'gcc' failed with exit status 1

sasl3 on PyPI does seem to fix the problem, but thrift_sasl's dependency is on this package.

@lekv
Copy link

lekv commented Jan 13, 2020

Thanks @VincentBLortie for posting the error. From [https://github.com/pandas-dev/pandas/issues/23424#issuecomment-446393981|pandas/issues/23424#issuecomment-446393981] it looks to me like some older library versions on my system have made this work.

It may work for some users, for 1 of 2 reasons:

  • libstdc++ is lying around somewhere from a previous Xcode 9 install
  • when running a recent 64-bit only variant of python, which targets macOS 10.9 and hence libc++

With that understanding the change looks good to me (I validated that it can be installed from with this PR on my local machine).

attilajeges pushed a commit to attilajeges/python-sasl that referenced this pull request Mar 30, 2021
@attilajeges attilajeges merged commit 416e863 into cloudera:master Apr 13, 2021
hsheth2 added a commit to hsheth2/datahub that referenced this pull request Jun 11, 2021
This resolves some MacOS build issues, which stem from the release of
XCode10. See cloudera/python-sasl#13 for details
about the issue itself. The [sasl3
fork](https://github.com/sparkur/python-sasl3) contains these changes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants