-
Notifications
You must be signed in to change notification settings - Fork 75
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
MacOS Big Sur unable to install #104
Comments
In
the So one alternative would be to modify (Can Another alternative would be "Apple's shipped libpcap and tcpdump since Day One, or close to it, so we'll just assume we have it". If that's too risky, you could try running the command
from the setup script if you're on macOS, and capture its output, to 1) find tcpdump and 2) get the paths of the libraries it has to load; on my 11.2.3 (x86-64) VM, it prints:
|
Confirmed. Ignoring the absence of these files during setup.py allows installation to continue, then everything seems (superficially) OK. In setup.py, commented out lines 87, 88 Added |
Here's a version of |
I still cannot install, at least under macOS 12.5.1. The error is:
This is despite also setting the following as suggested by Homebrew: export LDFLAGS="-L/opt/homebrew/opt/libpcap/lib"
export CPPFLAGS="-I/opt/homebrew/opt/libpcap/include"
export PKG_CONFIG_PATH="/opt/homebrew/opt/libpcap/lib/pkgconfig" I cannot test for Big Sur, but the issue is the same. |
@mwfong-csl I've just tested your change and can confirm it works as expected under macOS 12.5.1 Monterey. Thanks for making it. As a confirmation, here's the build output:
There were some warnings from clang but I skip them to keep the output as short as I can. |
How did you install libpcap? Seems it's in a system wide location. I guess the reason it doesn't work for me is that it's the Homebrew library, but even setting the additional paths won't work. |
@mwfong-csl's change takes advantage of
|
@slhck Per ldconfig equivalent for Mac OS X, did you specify the Homebrew library path via the environment symbol, |
I'm not that experienced with building/shipping these projects in a platform-independent manner, but wouldn't it be possible to rely on |
I tested @mwfong-csl's branch on a clean install Big Sur VM with standard libraries (not brew install) and tested with py36, py37, py38, py39, py310. The installation succeeded on python versions >= py3.8. Here is the output:
|
@slhck What version of Python are you running? Per @tulay's post (above), you need Python 3.8 or newer to install |
I tested with 3.9 and 3.10. Shouldn't it pick up the default libraries anyway? (I don't think the Homebrew ones would interfere here.) |
It should have with Python >= 3.8 and Mac OS >= 11. I wonder that the difference is between your environment and Tulay's and koczanm's. Per koczanm's previous comment (above), what is the result of your running
? |
@slhck Try checking out @mwfong-csl's branch. There is no fix yet in the main repo which you seem to be trying to install from. The original poster was also trying to install on python 2.7. I just tested on python2.7 and it did install. |
Ah, yes, checking out this branch makes it work: https://github.com/mwfong-csl/pypcap/tree/issue-104 — I had tried the master branch before. So I guess this can be made a PR then? |
Attempting to use pypcap under python 2.7 installing via pip.
None of the following found: ['libpcap.a', 'libpcap.so', 'libpcap.dylib', 'wpcap.lib']
Appears to be related to the changes introduced in Big Sur that means the .dylib files no longer exist, they are all part of the new dynamic cache.
For example, here is the homebrew project having the same: Homebrew/brew#7803
Another: openframeworks/openFrameworks#6599 (comment)
More: https://mjtsai.com/blog/2020/06/26/reverse-engineering-macos-11-0/
The Apple release note having the info: https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes
Understandably being as Apple are moving things and changing the norms, lots of this kind of thing are going to break.
Looking for a workaround if possible or a fix that implements the dlopen() alternative - whatever that means!
The text was updated successfully, but these errors were encountered: