Introduction

If TensorFlow builds successfully from source but import tensorflow still fails, the problem is usually outside the compiler itself. Common causes include installing the wheel into the wrong Python environment, mixing Python versions, missing shared libraries, or importing from a directory that shadows the package. The fastest path to a fix is to verify the interpreter, the installed wheel, and the runtime library dependencies in that order.

Confirm Which Python You Are Using

The most common source-build failure is not a bad build. It is using one Python interpreter to build and another to import.

Start by checking the exact interpreter:

python -c "import sys; print(sys.executable); print(sys.version)"

Then confirm where pip is installing packages:

python -m pip --version
python -m pip show tensorflow

If pip and python point at different virtual environments, the wheel may be installed correctly but not in the environment you are actually running.

Install the Built Wheel Into the Active Environment

A successful source build usually produces a wheel. The next step is to install that wheel with the same Python interpreter that will import TensorFlow.

python -m pip install /path/to/tensorflow_build.whl

Avoid using plain pip install without qualifying it through python -m pip. That small habit prevents a lot of interpreter mismatches.

After installation, test the import immediately:

python -c "import tensorflow as tf; print(tf.__version__)"

If this still fails, the problem is usually runtime linkage or environment layout, not installation alone.

Watch for Local Directory Shadowing

Another common issue is running Python from a directory that already contains a tensorflow folder, file, or leftover build artifact. Python imports the local path first, so a source checkout can shadow the installed package.

Check the working directory and import origin:

python -c "import tensorflow; print(tensorflow.__file__)"

If the printed path points into your source tree instead of the installed site-packages directory, you are not importing the packaged wheel you think you are.

The usual fix is to:

• leave the source directory before testing the import
• remove stale tensorflow.py files
• clear old build artifacts that confuse module resolution

Match the Python ABI and Build Configuration

TensorFlow wheels are tied to a specific Python version and ABI. If you built against one interpreter and install into another, import errors are expected.

For example, building against Python 3.11 and importing from Python 3.10 is not a supported swap. The shared objects inside the wheel are compiled for the interpreter they were built against.

That means the build environment should be consistent:

• one chosen Python interpreter
• matching headers and development files
• the same interpreter used for pip install and python -c

Check Shared Library Dependencies

If the wheel is installed in the right place but import still fails with a loader error, inspect the compiled library dependencies. On Linux, ldd is often enough to reveal a missing system library.

ldd /path/to/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so

On macOS, the equivalent tool is:

otool -L /path/to/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so

If a required library is missing or points to an unexpected version, the import can fail even though the package itself is installed correctly.

Keep Build and Runtime Environments Clean

TensorFlow source builds are sensitive to stale caches and mismatched toolchains. If the environment has been changed repeatedly, a clean rebuild is often faster than trying to reason about every leftover artifact.

Practical cleanup steps include:

• using a fresh virtual environment
• rebuilding with the intended Python only
• reinstalling the produced wheel into that same environment
• testing import outside the source tree

This is not automation for its own sake. It is a way to remove ambiguous state from the debugging process.

Common Pitfalls

• Building with one Python interpreter and importing with another.
• Installing the wheel with pip from a different environment than the one used by python.
• Running import tensorflow from inside a source checkout that shadows the installed package.
• Assuming a successful build guarantees that runtime shared libraries are available.
• Reusing a dirty environment with stale build artifacts and unclear paths.

Summary

• Start by verifying that python, pip, and the installed TensorFlow wheel all refer to the same environment.
• Install the built wheel with python -m pip, not an ambiguous pip.
• Check whether local files or directories are shadowing the real TensorFlow package.
• Inspect shared library dependencies if the import fails after installation.
• A clean virtual environment is often the shortest path to a reproducible fix.