a year ago
My app failed deployment after its been up and running for a couple years now. I don't understand why. Here is a what the build log says:
Attachments
Pinned Solution
a year ago
Railway’s build VM is now using Python 3.12; when pip tries to build cffi it needs the libffi headers and they’re no longer in the default Nixpacks image, so the compile dies with “ffi.h: No such file or directory”.
You can most likely fix it with one of three ways below:
1. Tell Nixpacks to install the headers
Add an env-var in the service settings
NIXPACKS_PKGS="libffi pkg-config"
then redeploy. (Nix package libffi already contains the dev files.)
2. Stick to a Python that has a pre-built wheel
NIXPACKS_PYTHON_VERSION="3.11"
re-deploy and it will pull the ready-made manylinux wheel instead of compiling.
3. Pin a wheel-ready cffi version in requirements.txt
cffi==1.16.0
(or any release that ships wheels for 3.12). Commit, push, redeploy.
Any one of those will let the build pass again – nothing is wrong with your code, the builder just lost the system package it needs.
Your requirements.txt does list cffi, but Railway’s build VM upgraded itself to Python 3.12.
– The wheel for 3 .11 you were getting before is no longer compatible.
– Because cffi has to be compiled for 3 .12, the build now needs the libffi headers (ffi.h) that aren’t in the default image, so it blows up.
Hope this helps! 🙂
19 Replies
a year ago
Instead of screenshots, can you copy-paste the full log into a text snippet, so that we can look at that?
a year ago
error: subprocess-exited-with-error × Building wheel for cffi (pyproject.toml) did not run successfully. │ exit code: 1 ╰─> [68 lines of output] Package libffi was not found in the pkg-config search path. Perhaps you should add the directory containing libffi.pc' to the PKG_CONFIG_PATH environment variable Package 'libffi', required by 'virtual:world', not found Package libffi was not found in the pkg-config search path. Perhaps you should add the directory containing libffi.pc' to the PKG_CONFIG_PATH environment variable Package 'libffi', required by 'virtual:world', not found Package libffi was not found in the pkg-config search path. Perhaps you should add the directory containing libffi.pc' to the PKG_CONFIG_PATH environment variable Package 'libffi', required by 'virtual:world', not found Package libffi was not found in the pkg-config search path. Perhaps you should add the directory containing libffi.pc' to the PKG_CONFIG_PATH environment variable Package 'libffi', required by 'virtual:world', not found Package libffi was not found in the pkg-config search path. Perhaps you should add the directory containing `libffi.pc' to the PKG_CONFIG_PATH environment variable Package 'libffi', required by 'virtual:world', not found /tmp/pip-build-env-sa1h_a_6/overlay/lib/python3.12/site-packages/setuptools/dist.py:759: SetuptoolsDeprecationWarning: License classifiers are deprecated. !! ******************************************************************************** Please consider removing the following classifiers in favor of a SPDX license expression: License :: OSI Approved :: MIT License See https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license for details. ******************************************************************************** !! self._finalize_license_expression() running bdist_wheel running build running build_py creating build/lib.linux-x86_64-cpython-312/cffi copying cffi/api.py -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/cparser.py -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/verifier.py -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/pkgconfig.py -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/__init__.py -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/ffiplatform.py -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/recompiler.py -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/setuptools_ext.py -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/vengine_gen.py -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/error.py -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/cffi_opcode.py -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/model.py -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/backend_ctypes.py -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/vengine_cpy.py -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/commontypes.py -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/lock.py -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/_cffi_include.h -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/parse_c_type.h -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/_embedding.h -> build/lib.linux-x86_64-cpython-312/cffi copying cffi/_cffi_errors.h -> build/lib.linux-x86_64-cpython-312/cffi warning: build_py: byte-compiling is disabled, skipping. running build_ext building '_cffi_backend' extension creating build/temp.linux-x86_64-cpython-312/c gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O3 -Wall -I/nix/store/3nkb6rscay1w5ky9xziy7qnjl0i4dx25-libxcrypt-4.4.36/include -fPIC -DUSE__THREAD -DHAVE_SYNC_SYNCHRONIZE -I/usr/include/ffi -I/usr/include/libffi -I/opt/venv/include -I/nix/store/901c80rlps5q05bnjk1sj4zaz5k736nc-python3-3.12.7/include/python3.12 -c c/_cffi_backend.c -o build/temp.linux-x86_64-cpython-312/c/_cffi_backend.o c/_cffi_backend.c:15:10: fatal error: ffi.h: No such file or directory 15 | #include <ffi.h> | ^~~~~~~ compilation terminated. error: command '/root/.nix-profile/bin/gcc' failed with exit code 1 [end of output] note: This error originates from a subprocess, and is likely not a problem with pip.
Jun 25 14:02:47
ERROR: Failed building wheel for cffi
Jun 25 14:02:47
Failed to build cffi
Jun 25 14:02:47
ERROR: ERROR: Failed to build installable wheels for some pyproject.toml based projects (cffi)
a year ago
Heyy
I think you need to Install the libffi-dev package (e.g., via apt-get install libffi-dev or apk add libffi-dev) before running pip install to fix the missing ffi.h error.
idiegea21
Heyy I think you need to Install the `libffi-dev` package (e.g., via `apt-get install libffi-dev` or `apk add libffi-dev`) before running `pip install` to fix the missing `ffi.h` error.
a year ago
I'm on windows and I can't seem to find out how to do this on windows
a year ago
On Windows, you don’t install libffi-dev. that’s for Linux. Instead Run:
python -m pip install --upgrade pip setuptools wheel
pip install cffi
If it still does not work then you are likely to be using a newer version of py (e.g 3.12) with no prebuilt wheel, so you would have to downgrade to i uhmm 3.11 or downloading a wh1 and installing it manually
idiegea21
On Windows, you **don’t install** `libffi-dev`. that’s for Linux. Instead Run: `python -m pip install --upgrade pip setuptools wheel` `pip install cffi` If it still does not work then you are likely to be using a newer version of py (e.g 3.12) with no prebuilt wheel, so you would have to downgrade to i uhmm 3.11 or downloading a wh1 and installing it manually
a year ago
I already have cffi installed and in my requirements.txt file and my python version is 3.11.9
a year ago
I think a Python version bump may be forcing a rebuild of cffi, rather than using the prebuilt wheel.
You mentioned you're using Python 3.11.9, but the error logs show it's actually building against Python 3.12: /nix/store/...-python3-3.12.7/include/python3.12
Also, you mentioned you're working on a Windows machine, but based on the logs, it looks like your deployment or build environment is running on Linux.
Can you confirm that?
idiegea21
I think a Python version bump may be forcing a rebuild of `cffi`, rather than using the prebuilt wheel. You mentioned you're using Python 3.11.9, but the error logs show it's actually building against Python 3.12: `/nix/store/...-python3-3.12.7/include/python3.12` Also, you mentioned you're working on a Windows machine, but based on the logs, it looks like your deployment or build environment is running on Linux. Can you confirm that?
a year ago
Yes the build environment is in linux. I was referring to my personal laptop. I'm honestly not too familiar with railway.
a year ago
Is your issue still open ?
supercool27
Is your issue still open ?
a year ago
The question is not showing solved so it is open
a year ago
Add to your nixpacks.toml
[phases.build]
nixPkgs = ["libffi", "pkg-config"]a year ago
As you mentioned you don't know Railway too well this will help https://docs.railway.com/reference/config-as-code#configuring-a-build-provider-with-nixpacks
sim
Add to your nixpacks.toml ``` [phases.build] nixPkgs = ["libffi", "pkg-config"] ```
a year ago
This didn't work
abomidaba
This didn't work
a year ago
I am sorry. I will try doing a test deployment today and figure out the solution
sim
I am sorry. I will try doing a test deployment today and figure out the solution
a year ago
Okay thank you
sim
I am sorry. I will try doing a test deployment today and figure out the solution
a year ago
Were you able to come up with a solution?
a year ago
Railway’s build VM is now using Python 3.12; when pip tries to build cffi it needs the libffi headers and they’re no longer in the default Nixpacks image, so the compile dies with “ffi.h: No such file or directory”.
You can most likely fix it with one of three ways below:
1. Tell Nixpacks to install the headers
Add an env-var in the service settings
NIXPACKS_PKGS="libffi pkg-config"
then redeploy. (Nix package libffi already contains the dev files.)
2. Stick to a Python that has a pre-built wheel
NIXPACKS_PYTHON_VERSION="3.11"
re-deploy and it will pull the ready-made manylinux wheel instead of compiling.
3. Pin a wheel-ready cffi version in requirements.txt
cffi==1.16.0
(or any release that ships wheels for 3.12). Commit, push, redeploy.
Any one of those will let the build pass again – nothing is wrong with your code, the builder just lost the system package it needs.
Your requirements.txt does list cffi, but Railway’s build VM upgraded itself to Python 3.12.
– The wheel for 3 .11 you were getting before is no longer compatible.
– Because cffi has to be compiled for 3 .12, the build now needs the libffi headers (ffi.h) that aren’t in the default image, so it blows up.
Hope this helps! 🙂
colinrm000
Railway’s build VM is now using Python 3.12; when pip tries to build cffi it needs the libffi headers and they’re no longer in the default Nixpacks image, so the compile dies with “ffi.h: No such file or directory”. You can most likely fix it with one of three ways below: 1\. Tell Nixpacks to install the headers Add an env-var in the service settings `NIXPACKS_PKGS="libffi pkg-config"` then redeploy. (Nix package _libffi_ already contains the dev files.) 2\. Stick to a Python that has a pre-built wheel `NIXPACKS_PYTHON_VERSION="3.11"` re-deploy and it will pull the ready-made manylinux wheel instead of compiling. 3\. Pin a wheel-ready cffi version in requirements.txt `cffi==1.16.0` (or any release that ships wheels for 3.12). Commit, push, redeploy. Any one of those will let the build pass again – nothing is wrong with your code, the builder just lost the system package it needs. Your requirements.txt does list cffi, but Railway’s build VM upgraded itself to Python 3.12. – The wheel for 3 .11 you were getting before is no longer compatible. – Because cffi has to be **compiled** for 3 .12, the build now needs the **libffi headers** (ffi.h) that aren’t in the default image, so it blows up. Hope this helps! 🙂
a year ago
Thanks, it worked! I changed the cffi version in my requirments.txt file and got it deployed. Appreciate the help!
abomidaba
Thanks, it worked! I changed the cffi version in my requirments.txt file and got it deployed. Appreciate the help!
a year ago
Amazing! I am happy to hear that and you're welcome!
Happy deving! 😄
Status changed to Solved brody • 11 months ago