📝 pytorch_checkpoint_as_at_last_modification.md

PyTorch CPU Build — Checkpoint

Date: 2026-08-26
Host: root@forum / VMware guest
Project: /root/pytorch
Build directory: /root/pytorch/build

1. Objective

Build the current PyTorch source as a CPU-only build on an older CentOS/Linux environment.

Current hardware/configuration:

2. Important history

The VM originally ran out of disk space during the PyTorch build:

c++: fatal error: could not write to temporary response file /tmp/cc3xdDU1
/dev/sda1 ... 100% /

The VMware disk was subsequently expanded.

LVM now reports approximately:

vg_clone
lv_root 30.51g
lv_swap 1.00g

The build directory contains substantial compiled objects. At one point:

du -sh /root/pytorch/build
1.6G

The build had reached approximately 58–59% before failing.

3. First major failure

At approximately 58%:

[ 58%] Linking CXX shared library ../lib/libtorch_cpu.so
...
ld: cannot find -lfoxi_loader
collect2: error: ld returned 1 exit status
make[2]: *** [lib/libtorch_cpu.so] Error 1

CMake cache showed:

torch_cpu_LIB_DEPENDS=...;foxi_loader;...

The source tree contains:

/root/pytorch/third_party/foxi

The CMake configuration also showed ONNX-related components being configured.

4. Suspicious generated-source pollution

The build directory contains many bizarre generated filenames such as:

Activation.cpp.DEFAULT.cpp
Activation.cpp.AVX2.cpp
Activation.cpp.DEFAULT.cpp.DEFAULT.cpp
Activation.cpp.DEFAULT.cpp.DEFAULT.cpp.DEFAULT.cpp.DEFAULT.cpp
Activation.cpp.AVX2.cpp.DEFAULT.cpp.AVX2.cpp
...

This is highly suspicious and may indicate that the existing build directory has accumulated/generated duplicate source transformations.

At the time, the torch_cpu object directory was approximately:

754M /root/pytorch/build/caffe2/CMakeFiles/torch_cpu.dir

Therefore, do not assume the existing build directory is clean.

5. Current failure

After another build attempt, compilation reached 59%:

[ 59%] Built target XNNPACK
[ 59%] Building CXX object caffe2/CMakeFiles/torch_cpu.dir/onnx/backend.cc.o
[ 59%] Building CXX object caffe2/CMakeFiles/torch_cpu.dir/onnx/backend_rep.cc.o

Then failed:

/root/pytorch/caffe2/onnx/helper.h:4:10:
fatal error: onnx/onnx_pb.h: No such file or directory

#include "onnx/onnx_pb.h"

The build stopped with:

make[3]: *** [caffe2/CMakeFiles/torch_cpu.dir/onnx/backend.cc.o] Error 1
make[2]: *** [caffe2/CMakeFiles/torch_cpu.dir/all] Error 2
make[1]: *** [all] Error 2
make: *** [all] Error 2

6. Current CMake facts already established

The CMake configuration reported:

BUILD_CAFFE2:BOOL=ON
BUILD_CAFFE2_MOBILE:BOOL=OFF
BUILD_CAFFE2_OPS:BOOL=ON
USE_CUDA:BOOL=OFF
USE_ROCM:BOOL=OFF

It also reported:

disabling CUDA because USE_CUDA is set false
disabling ROCM because USE_ROCM is set false

ONNX 1.10.1 was configured:

ONNX version              : 1.10.1
ONNX NAMESPACE : onnx_torch
ONNX_USE_LITE_PROTO : OFF
USE_PROTOBUF_SHARED_LIBS : OFF
Protobuf_USE_STATIC_LIBS : ON
ONNX_DISABLE_EXCEPTIONS : OFF
ONNX_WERROR : OFF
ONNX_BUILD_TESTS : OFF
ONNX_BUILD_BENCHMARKS : OFF
ONNXIFI_DUMMY_BACKEND : OFF
ONNXIFI_ENABLE_EXT : OFF

CMake also generated these protobuf-related files:

build/third_party/onnx/onnx/onnx_onnx_torch-ml.proto
build/third_party/onnx/onnx/onnx-operators_onnx_torch-ml.proto
build/third_party/onnx/onnx/onnx-data_onnx_torch.proto

But the required:

onnx/onnx_pb.h

was not found by the compiler.

7. Environment limitations

Compiler:

/opt/rh/devtoolset-7/root/usr/bin/c++
GCC 7.3.1

CMake:

3.25.2

Python:

/usr/local/bin/python3
Python 3.6.3
NumPy 1.19.5

The system does not have MKL or a general BLAS library detected:

MKL library not found
Cannot find a library with BLAS API. Not using BLAS.

PyTorch therefore falls back to Eigen/pocketfft as configured.

OpenMP is available:

-fopenmp
OpenMP TRUE

CPU feature detection found:

AVX
AVX2
AVX512F

CUDA is intentionally disabled.

8. Current state — DO NOT blindly continue

The immediate failure is:

fatal error: onnx/onnx_pb.h: No such file or directory

There was also an earlier:

cannot find -lfoxi_loader

and suspicious duplicate generated Activation.cpp.* files.

Therefore, do not simply run make -j4 again without first diagnosing the CMake/build configuration.

Useful diagnostic commands that were proposed but should be run before changing anything:

cd /root/pytorch/build

grep -E 'INTERN_DISABLE_ONNX|BUILD_CAFFE2|USE_ONNX|ONNX' CMakeCache.txt | head -30

ls -l /root/pytorch/build/third_party/onnx/onnx/onnx_pb.h

find /root/pytorch/build /root/pytorch/third_party -name onnx_pb.h -print

Also useful:

grep -R "foxi_loader" CMakeCache.txt CMakeFiles 2>/dev/null | head -30

9. Key question for the three AIs

We need to determine the cleanest and safest way to finish this CPU-only PyTorch build.

Specifically:

  1. Is ONNX/Caffe2 ONNX actually required for the intended PyTorch build?
  2. Can ONNX/ONNXIFI/FOXI be disabled cleanly in this particular PyTorch source version?
  3. Why is torch_cpu_LIB_DEPENDS still containing foxi_loader?
  4. Why is onnx/onnx_pb.h missing despite ONNX protobuf generation being configured?
  5. Are the repeated Activation.cpp.DEFAULT.cpp... filenames evidence that the build directory must be deleted and CMake reconfigured from scratch?
  6. If the build directory must be rebuilt, what exact CMake command should be used to produce a CPU-only build while avoiding the ONNX/FOXI problem?
  7. Given approximately 6 GB RAM, 4 CPUs, 1 GB swap, and ~30.5 GB root storage, what build parallelism (make -jN) is safest?
  8. Can the existing 59% of compiled objects be safely preserved, or is a clean rebuild preferable?

10. Important operational constraint

The machine previously filled its root filesystem completely during linking. Disk space must therefore be monitored before and during another build:

df -h /
free -h

Do not recommend deleting arbitrary files from /root/pytorch/build until it is clear whether they are required for incremental compilation.

11. Desired response from the consulting AIs

Please provide:

Do not assume that reaching 59% means the build is permanently checkpointed. Explain what CMake/make will actually reuse if the build directory is retained.