Comprehensive Guide to Resolving "gcc: error: x86_64-linux-gnu-gcc: No such file or directory"

Error Background and Root Cause Analysis

In Autotools-based build systems, proper configuration of GCC compiler command-line arguments is crucial. When executing gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/include/python2.7 -std=c99 x86_64-linux-gnu-gcc -pthread ..., GCC interprets x86_64-linux-gnu-gcc as an input filename rather than a compiler identifier. This misinterpretation stems from the platform-specific compiler name being incorrectly included in the CFLAGS variable within the Autoconf-generated Makefile.

From a technical perspective, GCC argument parsing follows a strict order: option arguments (such as -I, -std) are processed first, while remaining non-option arguments are treated as input files. When x86_64-linux-gnu-gcc appears in a non-option position, GCC attempts to open it as a source file, resulting in the "No such file or directory" error.

Complete Build Environment Configuration

Successful Nanoengineer compilation requires a complete development environment and dependency chain. First, install essential build tools:

sudo apt-get install build-essential autoconf libtool pkg-config python-opengl python-imaging python-pyrex python-pyside.qtopengl idle-python2.7 qt4-dev-tools qt4-designer libqtgui4 libqtcore4 libqt4-xml libqt4-test libqt4-script libqt4-network libqt4-dbus python-qt4 python-qt4-gl libgle3 python-dev

These packages provide C/C++ compilers, Python development headers, graphical interface libraries, and scientific computing infrastructure. Notably, build-essential includes the GCC toolchain, while python-dev provides Python header files—key dependencies emphasized in other answers.

Numerical Computing Library Installation

Nanoengineer relies on legacy Python numerical computing libraries. Install NumArray 1.5.2 as follows:

wget http://goo.gl/6gL0q3 -O numarray-1.5.2.tgz
tar xfvz numarray-1.5.2.tgz
cd numarray-1.5.2
sudo python setup.py install

Similarly, install Numeric 23.8:

wget http://goo.gl/PxaHFW -O numeric-23.8.tgz
tar xfvz numeric-23.8.tgz
cd Numeric-23.8
sudo python setup.py install

These older libraries provide array manipulation capabilities. Although superseded by NumPy, they remain necessary in legacy projects.

HDF5 Data Format Support

Scientific data storage requires the HDF5 library:

wget ftp://ftp.hdfgroup.org/HDF5/releases/hdf5-1.6/hdf5-1.6.5.tar.gz
tar xfvz hdf5-1.6.5.tar.gz
cd hdf5-1.6.5
./configure --prefix=/usr/local
sudo make 
sudo make install

Specifying --prefix=/usr/local during configuration ensures library files are installed in standard locations. Compatibility issues with modern compilers may require source code modifications during compilation.

Core Error Resolution

For the x86_64-linux-gnu-gcc error, the most direct solution involves creating an empty file in the sim/src directory:

touch sim/src/x86_64-linux-gnu-gcc

While seemingly unconventional, this approach leverages GCC's file handling logic: it reports an error when a specified file is missing but continues processing other arguments when an empty file is found. From an engineering perspective, this avoids modifying complex Autotools-generated files.

A more fundamental solution would involve correcting Autoconf configuration, but given the project's age, the file creation method provides a quickly applicable workaround.

Additional Compilation Issues

HDF5 compilation may encounter errors due to modern GCC strictness. Modify line 548 in perform/zip_perf.c:

output = open(filename, O_RDWR | O_CREAT, S_IRUSR|S_IWUSR);

This adds the file mode parameter, complying with POSIX open system call specifications. The original code's missing mode parameter triggers errors in modern compilers.

For Python header path issues, set environment variables:

export CPPFLAGS=-I/usr/local/include/python2.7
./configure
make
sudo make install

This ensures the C preprocessor can locate Python development headers.

Runtime Problem Fixes

After successful compilation, startup may encounter OpenGL import errors. Modify import statements in relevant files:

from OpenGL.GL import GL_ARRAY_BUFFER_ARB
from OpenGL.GL import GL_ELEMENT_ARRAY_BUFFER_ARB

Change to:

from OpenGL.GL.ARB.vertex_buffer_object import GL_ARRAY_BUFFER_ARB
from OpenGL.GL.ARB.vertex_buffer_object import GL_ELEMENT_ARRAY_BUFFER_ARB

This reflects the evolution of OpenGL extension management, where these constants have been moved to specific extension modules in modern versions.

System Compatibility Considerations

Different Linux distributions vary in toolchain configuration. Debian-based systems use the x86_64-linux-gnu- prefix to identify cross-compilation tools, while other distributions may use different naming conventions. Build systems should handle these differences properly, but older projects often assume specific environments.

The solution's generality lies in understanding the error's essence, allowing adjustments for specific environments. For instance, similar toolchain prefix issues might manifest as different missing file errors on other systems.

Build System Evolution Perspective

The transition from Autotools to CMake reflects build system evolution. Modern CMake offers better cross-platform support and dependency management, but maintaining legacy projects requires understanding traditional toolchain operations.

Through this specific case, developers can gain deep insights into core concepts such as compiler argument parsing, build system configuration generation, dependency management, and cross-version compatibility—knowledge equally applicable when maintaining other legacy projects.