"cannot stat 'Modules/_crypt.cpython-312-x86_64-linux-gnu.so': No such file or directory" in Linux with Homebrew #2823
Comments
|
I have the same problem. I installed |
You're right. I seem to have some warnings but other versions of python seem to work. |
|
@punowo this is the reason: Homebrew installs This stops one from being able to build software using the system toolchain -- because the flags it produces only work out of the box if using a Homebrew-provided compiler. Pyenv doesn't use packages from Homebrew in Linux by default. That's because Homebrew is more problematic to use than distro-provided packages. Unlike most distros, Homebrew is rolling-release -- and as such, its dependency package upgrades break existing Pyenv-provided installations whenever their To build with the system's toolchain,
To build with Homebrew's toolchain,
|
native-api
changed the title
|
@native-api Thank you for your explanation. I understand what is happening but I'm not really sure on how to deal with it. I'll give a brief explanation as to what I'm trying to do. I use homebrew on my Mac to handle pretty much everything package related, so for this machine I'm currently encountering this type of problem I wanted to have the baseline offered by Ubuntu and some other stuff, like go, fnm ( for node ), pyenv ( for python ) handled by homebrew similarly to how I handle it on my Mac. I opted for installing pyenv using homebrew since it will automatically get updated as I update other homebrew packages. Correct me if I'm wrong but unlinking pkg-config would be a temporary solution right, same goes for using a homebrew provided compiler ( my current mental model as a non C/C++ dev is that in case some component is provided by Ubuntu, but was not installed by homebrew I'm going to have the same issue ) ? Is it better for my use case to not use homebrew at all for pyenv, or better remove homebrew from PATH during it's runtime ? Sorry but I couldn't attach this log, I uploaded here: https://0x0.st/HJAk.log The command I executed was: |
This looks like #2693 (comment) (cited below).
|
removing Homebrew from |
The following are not symlinks: The command should be something like this right ? |
|
This worked: Should I worry about the warnings ? |
The mentioned modules will be missing so the associated Python functionality won't work. This may or may not be significant for you. |
Strange. For me, it worked with just |
Sorry I left my laptop at work. I'll post the version only with CC and the one with everything on Monday. |
|
As a resolution to this topic, it seems we'd need to add an exception to Pyenv to use Homebrew in Linux by default if Pyenv itself has been installed with Homebrew. (Then you would not need to use a Homebrew-provided compiler 'cuz Pyenv itself would be adding the compiler options that those add implicitly.) Shall we also print a warning if Homebrew is not going to be used but a Homebrew-provided |
|
Hello. I've updated pyenv. Here is the first command I tried running which failed: Here are the logs: And here is the second command I tried which was successful: |
Installing python 3.12.0 raised Using Ubuntu 22.04 LTS and |
|
|
|
|
PSA this can be easily undone by the counterpart |
this did not work for me. I'm on a Mac, so I wanted to avoid the brew toolchain, so my cmd was:
where that CC came from brew install gcc, in case that's not obvious: the error: why does python assume my gcc is really clang? |
|
@robbiemu Sorry I don't know how to help. I didn't have any problems on Mac OS at all. I haven't had any problems but then again when I'm on Mac OS I've learned to just use the clang it arrives. By default, on a Mac, gcc points to it. For the record I have this in my .zprofile. # Setup pyenv ( python version manager )
if [ -x "$HOMEBREW_PATH/bin/pyenv" ]; then
export PYENV_ROOT="$HOME/.pyenv"
export PYTHON_CONFIGURE_OPTS='--enable-optimizations --with-lto'
export PYTHON_CFLAGS='-march=native -mtune=native'
export LDFLAGS="-L/opt/homebrew/opt/zlib/lib"
export CPPFLAGS="-I/opt/homebrew/opt/zlib/include"
command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"
fi |
|
@punowo - hey, thank you for answering my question! the fact that gcc by default points to clang in the Mac framework is a great reason why it would do that. I went back to the other way to install and eventually also solved my problem. When you get a new Mac, you might want to try out the game porting toolkit and play a game or two, instead of immediately setting up your coding env, I'm sure I have some sympathy in that. I used a pattern at first that installed the x64 version of homebrew to set up windows games (later migrated to whisky, because it is cleaner). So I have two homebrews, one of which is for the x64 arch instead of arm64. It was being picked up and preventing me from success using the default method. uninstalling libb2 with the x64 version of homebrew solved my problems. I'm good, using 3.12 now :) |
|
|
This also worked for me using linux mint, installed at first using homebrew, then i uninstalled and installed pyenv manually, still got the problem. So if you use homebrew once you have to do this before installing latest python version |
Ubuntu Linux 23.10
amd64
pyenv version: 2.3.30
gcc (Ubuntu 13.2.0-4ubuntu3) 13.2.0
trace.log
python-build.20231018124421.17515.log
I installed pyenv using homebrew on Linux, but I also had a similar issue when using the pyenv installer on another Ubuntu 23.10 machine.
The text was updated successfully, but these errors were encountered: