Introduction

The error about @rpath/libcudart.8.0.dylib means the program was built or configured expecting the CUDA 8 runtime library, but macOS could not find that dynamic library at runtime. In older TensorFlow GPU builds on Intel Macs with NVIDIA hardware, that usually meant a CUDA installation mismatch; in modern macOS environments, it more often means you are following an outdated setup path that no longer matches current TensorFlow support.

What the Error Actually Means

dyld is the macOS dynamic loader. When it reports that @rpath/libcudart.8.0.dylib cannot be loaded, one of these is true:

• CUDA 8 is not installed
• CUDA 8 is installed, but the library path is not visible to the binary
• TensorFlow or one of its dependencies was compiled against a different CUDA version than the one on disk
• the build instructions are for an older NVIDIA-based macOS setup that is no longer realistic on your machine

The important clue is the exact filename: libcudart.8.0.dylib. That points to CUDA 8 specifically, not just “some CUDA installation”.

Historical Context Matters

Older TensorFlow GPU builds on macOS depended on NVIDIA CUDA libraries. That is the era this error belongs to. Current official TensorFlow installation guidance for macOS no longer centers on NVIDIA CUDA, and Apple’s current acceleration path is tensorflow-metal on supported Mac GPUs.

So before debugging path variables, ask a more basic question: are you intentionally reproducing an old TensorFlow plus CUDA-on-macOS build, or are you just trying to run TensorFlow on a modern Mac?

If the answer is the second one, the right fix is usually not to chase libcudart.8.0.dylib. The right fix is to move to the current supported installation path.

If You Are Maintaining an Old CUDA-Based Build

For a genuinely old Intel Mac plus NVIDIA workflow, the fix is version alignment. TensorFlow, CUDA, cuDNN, Bazel, and the compiler toolchain all need to match the build instructions for that TensorFlow release.

At minimum, verify that the expected library actually exists:

find /usr/local -name 'libcudart.8.0.dylib' 2>/dev/null

If it is present, inspect the loader paths used by the failing binary:

otool -L path/to/binary_or_shared_object

If the binary expects @rpath/libcudart.8.0.dylib but the runtime cannot resolve that path, you are dealing with an rpath problem or an environment mismatch.

In older setups, developers often tried environment variables such as DYLD_LIBRARY_PATH, but that should be treated as a debugging aid, not the first design choice. The more robust fix is to ensure the build uses the right library locations from the start.

A Better Current Path for Modern Macs

If the goal is simply “run TensorFlow on macOS today”, use a supported modern install path instead of resurrecting CUDA 8 era instructions.

1python3 -m venv ~/venv-tf
2source ~/venv-tf/bin/activate
3python -m pip install --upgrade pip
4python -m pip install tensorflow

On supported Apple GPU systems that use the Metal plugin path:

python -m pip install tensorflow-metal
python -c "import tensorflow as tf; print(tf.config.list_physical_devices())"

This avoids the old NVIDIA CUDA dependency entirely.

Diagnostic Strategy

Treat the problem as a compatibility matrix issue, not just a missing file issue.

Check:

• exact TensorFlow version
• exact CUDA version expected by that TensorFlow build
• exact macOS hardware and architecture
• whether the setup is old Intel plus NVIDIA or a modern Apple GPU system

If any one of those assumptions is wrong, patching library paths will not produce a stable environment.

Common Pitfalls

The biggest pitfall is trying to fix a modern Mac setup with legacy CUDA-on-macOS instructions. That usually wastes time because the platform support story has changed.

Another mistake is installing a random CUDA toolkit version and hoping TensorFlow will adapt. TensorFlow binaries are built against specific library versions, and mismatches surface as loader errors.

A third issue is using loader path hacks before verifying whether the binary should exist on that platform at all.

Summary

• The error means a build expects CUDA 8 runtime libraries that macOS cannot resolve.
• In old NVIDIA-based macOS setups, the fix is strict version alignment across TensorFlow, CUDA, and related tools.
• In modern macOS environments, the better answer is usually to stop following legacy CUDA instructions.
• Check the actual binary dependencies with otool -L before changing path variables.
• If your goal is current TensorFlow on Mac, use the supported tensorflow and, when applicable, tensorflow-metal path instead.