From: Thomas Walker Lynch Date: Tue, 6 May 2025 07:39:58 +0000 (-0700) Subject: adding documents X-Git-Url: https://git.reasoningtechnology.com/usr/lib/python2.7/encodings/palmos.py?a=commitdiff_plain;h=851f84c3c9769f65e7f4f7357c7029c01c0ca753;p=RT-gcc adding documents --- diff --git "a/document\360\237\226\211/configure/RT metagdata.org" "b/document\360\237\226\211/configure/RT metagdata.org" new file mode 100644 index 0000000..bbed67a --- /dev/null +++ "b/document\360\237\226\211/configure/RT metagdata.org" @@ -0,0 +1,84 @@ +#+TITLE: RT_gcc Build Branding and Documentation URLs +#+AUTHOR: Thomas Walker Lynch +#+DATE: 2025-05-06 +#+OPTIONS: toc:nil num:nil +#+LANGUAGE: en + +This document outlines the recommended settings for GCC distributor metadata options when building the standalone ~RT_gcc~ compiler toolchain. These settings help clarify origin, version, and support paths for any distributed binaries based on this toolchain. + +* Purpose +GCC offers metadata fields to help identify binary builds, especially when they include custom patches or are not compiled from the official FSF release tree. Since RT_gcc introduces features like `#assign` and modular build scripts, we recommend setting these fields clearly. + +* Recommended Configuration + +** --with-pkgversion +:PROPERTIES: +:default: GCC +:controls: Label shown by `gcc --version` to identify the binary origin +:END: + +** Recommended setting +#+BEGIN_EXAMPLE +--with-pkgversion="RT_gcc standalone by Reasoning Technology" +#+END_EXAMPLE + +This distinguishes RT_gcc binaries from FSF-provided GCC builds. + +You can optionally append a build number or commit hash: +#+BEGIN_EXAMPLE +--with-pkgversion="RT_gcc standalone r1 (commit 9f3b123)" +#+END_EXAMPLE + +** --with-bugurl +:PROPERTIES: +:default: https://gcc.gnu.org/bugs/ +:controls: Where users are told to report bugs +:END: + +** Recommended setting +#+BEGIN_EXAMPLE +--with-bugurl="https://github.com/Thomas-Walker-Lynch/RT_gcc/issues" +#+END_EXAMPLE + +Use the GitHub Issues tracker unless you prefer an email or internal system. + +** --with-documentation-root-url +:PROPERTIES: +:default: https://gcc.gnu.org/onlinedocs/ +:controls: Where documentation links in error messages point +:END: + +** Recommended setting +#+BEGIN_EXAMPLE +--with-documentation-root-url="https://gcc.gnu.org/onlinedocs/" +#+END_EXAMPLE + +You may leave this as-is unless you plan to host modified docs yourself. + +** --with-changes-root-url +:PROPERTIES: +:default: https://gcc.gnu.org/ +:controls: Where version-specific release notes are linked +:END: + +** Recommended setting +#+BEGIN_EXAMPLE +--with-changes-root-url="https://gcc.gnu.org/" +#+END_EXAMPLE + +Alternatively, if you maintain a changelog of your patched builds: +#+BEGIN_EXAMPLE +--with-changes-root-url="https://github.com/Thomas-Walker-Lynch/RT_gcc/releases/" +#+END_EXAMPLE + +* Summary Table +#+LATEX_HEADER: \usepackage{booktabs} +#+ATTR_LATEX: :environment tabular :align lll +#+NAME: Distributor Option Summary +| Option | Purpose | Suggested Setting | +|------------------------------+-------------------------------------+--------------------------------------------------------------------| +| --with-pkgversion | Identify GCC build source | RT_gcc standalone by Reasoning Technology | +| --with-bugurl | Where users report issues | https://github.com/Thomas-Walker-Lynch/RT_gcc/issues | +| --with-documentation-root-url | Docs base for online help | https://gcc.gnu.org/onlinedocs/ | +| --with-changes-root-url | Changelog root | https://github.com/Thomas-Walker-Lynch/RT_gcc/releases/ | + diff --git "a/document\360\237\226\211/configure/directory settings.org" "b/document\360\237\226\211/configure/directory settings.org" new file mode 100644 index 0000000..88592fa --- /dev/null +++ "b/document\360\237\226\211/configure/directory settings.org" @@ -0,0 +1,92 @@ +#+TITLE: GCC Configure Directory Settings +#+AUTHOR: Thomas Walker Lynch +#+DATE: 2025-05-06 +#+OPTIONS: toc:nil num:nil +#+LANGUAGE: en + +See `terms - machine roles` and `compiler deployment scenarios` for context on build environments. + +* --prefix + +This path determines where the GCC build will put the build products: binaries, libraries, and include files. Though other configuration options can override these locations. + +In other words, it specifies the directory to hold the build products. Put yet in other words, it specifies the current build target directory. + +Default: /usr/local + +Examples: + +- If you want to install GCC into a custom toolchain directory called `/opt/gcc-12` use + `--prefix=/opt/gcc-12` + +- Thomas is building a standalone toolchain into `$TOOLCHAIN`, so he sets: + `--prefix=$TOOLCHAIN` + to ensure all artifacts are installed in that controlled location. + +* --exec-prefix + +Sets the prefix for machine-specific files (binaries and libraries). If omitted, defaults to the value of `--prefix`. + +Rarely needed unless separating machine-independent files (docs, configs) from machine-dependent binaries. + +Default: Same as `--prefix` + +Example: + +- To split architecture-specific files into `/opt/gcc-12/x86_64`, you could use: + `--prefix=/opt/gcc-12` + `--exec-prefix=/opt/gcc-12/x86_64` + +* --with-sysroot + +Sets the logical root directory for headers and libraries used by the target system. This is especially useful for cross-compilation. + +- Default: (none) +- Usage: + During cross-compilation or isolated builds, you use this to point to a directory that mimics the target system's root. + +- Example: Thomas builds in a clean sysroot at `$SYSROOT`, so he passes: + `--with-sysroot=$SYSROOT` + +* --with-local-prefix + +Specifies the location of *site-specific* include files (those not part of the system standard, but still available locally). + +- Default: /usr/local +- Usage: + If you are building GCC for a sandboxed system and do not want GCC to search `/usr/local/include`, this option helps isolate your build. + +- Example: Thomas is building a minimal toolchain and wants no accidental includes from host system, so he disables it: + `--with-local-prefix=/dev/null` + + *Note:* If you are building a cross-compiler or isolating your build, you almost certainly want to set this — otherwise `/usr/local/include` from the build machine could sneak into your target build. + +* --with-native-system-header-dir + +Sets the default location that GCC searches for system headers during compilation. + +- Default: /usr/include +- Usage: + Combine with `--with-sysroot` to define where GCC will look for headers inside the sysroot. + +- Example: Inside a musl-based sysroot at `$SYSROOT`, headers live in `$SYSROOT/usr/include`. Thomas sets: + `--with-sysroot=$SYSROOT` + `--with-native-system-header-dir=/usr/include` + + This ensures GCC internally treats the headers as if they were in `/usr/include` — *relative to* `$SYSROOT`. + +* Summary Table + +#+BEGIN_LATEX +\begin{tabular}{|l|l|p{6cm}|} +\hline +\textbf{Option} & \textbf{Default} & \textbf{Purpose} \\ +\hline +\texttt{--prefix} & /usr/local & Installation root for GCC binaries, libs, etc. \\ +\texttt{--exec-prefix} & Same as --prefix & Overrides install path for arch-specific files. \\ +\texttt{--with-sysroot} & (none) & Logical root of target system (headers, libs). \\ +\texttt{--with-local-prefix} & /usr/local & Where GCC looks for local includes (non-system). \\ +\texttt{--with-native-system-header-dir} & /usr/include & Directory (inside sysroot) with system headers. \\ +\hline +\end{tabular} +#+END_LATEX diff --git "a/document\360\237\226\211/terms/deployment scenarios.org" "b/document\360\237\226\211/terms/deployment scenarios.org" new file mode 100644 index 0000000..5429e0f --- /dev/null +++ "b/document\360\237\226\211/terms/deployment scenarios.org" @@ -0,0 +1,49 @@ +#+TITLE: Compiler Deployment Scenarios +#+AUTHOR: Thomas Walker Lynch +#+DATE: 2025-05-06 +#+OPTIONS: toc:nil num:nil +#+LANGUAGE: en + +See `terms - machine roles' for the definitions of 'build', 'host', and 'target' machines. + +* Native Compilation: Build = Host = Target. + +In a native compilation, all three roles — the machine that builds GCC (`build`), the machine on which the resulting compiler will run (`host`), and the machine for which that compiler will generate code (`target`) — are the same. + +- Example 1: Alice is running Debian on an x86_64 machine. She builds GCC from source directly on that system. The compiler runs on her Debian machine and compiles code for that same environment. + In terms of machine categories: + `build = host = target = x86_64-pc-linux-gnu` + +- Example 2: A system administrator compiles GCC inside a Fedora x86_64 container. The resulting compiler is used within that same container to build programs for Fedora x86_64. + In terms of machine categories: + `build = host = target = x86_64-redhat-linux` + +* Cross Compilation: Build = Host ≠ Target. + +In a cross compilation, the compiler is built and will run on one type of system (`build = host`), but is used to produce binaries for a different kind of system (`target`). + +- Example 1: Bob is using an x86_64 Ubuntu machine to build a GCC toolchain that runs on Ubuntu but outputs code for a Raspberry Pi (ARM). + In terms of machine categories: + `build = host = x86_64-pc-linux-gnu`, + `target = arm-linux-gnueabihf` + +- Example 2: A developer builds a MIPS cross-compiler on an x86_64 workstation. The resulting GCC is used on that workstation to compile code for an embedded MIPS device. + In terms of machine categories: + `build = host = x86_64-pc-linux-gnu`, + `target = mipsel-linux-uclibc` + +* Canadian Cross: Build ≠ Host ≠ Target. + +A Canadian Cross involves three distinct machines. GCC is built on one system (`build`), but the resulting compiler is meant to run on a different system (`host`), and it will generate binaries for yet another system (`target`). + +- Example 1: A toolchain is built on an x86_64 Linux desktop (`build`). It produces a GCC that runs on PowerPC AIX (`host`) and generates code for ARM embedded systems (`target`). + In terms of machine categories: + `build = x86_64-pc-linux-gnu` + `host = powerpc-ibm-aix` + `target = arm-none-eabi` + +- Example 2: Charlie uses his Linux laptop to build a Windows-native GCC cross-compiler (`host = Windows`). This Windows-hosted compiler will produce binaries for Android ARM (`target`). + In terms of machine categories: + `build = x86_64-pc-linux-gnu` + `host = x86_64-w64-mingw32` + `target = arm-linux-androideabi` diff --git "a/document\360\237\226\211/terms/gcc directory terminology.org" "b/document\360\237\226\211/terms/gcc directory terminology.org" new file mode 100644 index 0000000..6bc6c4b --- /dev/null +++ "b/document\360\237\226\211/terms/gcc directory terminology.org" @@ -0,0 +1,68 @@ + +#+TITLE: GCC Directory Terminology +#+AUTHOR: Thomas Walker Lynch +#+DATE: 2025-05-06 +#+OPTIONS: toc:nil num:nil +#+LANGUAGE: en + +* build directory (objdir) + +The directory where a build process takes place. + +For GCC this must be distinct from the source directory (srcdir). + +* current build + +Refers to the specific build being executed right now, as opposed to previously installed or referenced builds. + +Example: +- "The current build will output to `$BUILD_DIR/gcc`" +- "Avoid mixing headers from an old build with the current build" + +* current build target directory + +The destination directory into which the current build places its build products. + +This term combines the concepts of the `current build` and `target directory`, emphasizing that the output location is for the present compilation effort. + +Examples: +- If `make install DESTDIR=$SYSROOT`, then `$SYSROOT` is the current build target directory. +- For an isolated toolchain, `$TOOLCHAIN` might be the current build target directory + +* installation directory + +Any directory from which components are *intended to be used from*, whether built locally or installed from packages. A final resting place for binaries, scripts, libraries, headers, or anything else that gets 'used' as part of everyday work. + +In the GCC documents, an 'installation directory' is not limited to directories that the current build will put things into. In fact, sometimes it is used to refer to a directory the build will get things from. + +Examples include: +- System-wide locations like `/usr/bin` +- Custom toolchain roots like `$TOOLCHAIN/bin` + +* local-prefix + +Path where GCC searches for locally installed headers (like `/usr/local/include`). +This is not a build target directory, rather it is used for lookup during compilation. + +* prefix +The root path where GCC will install itself: +- Binaries to `$prefix/bin` +- Headers to `$prefix/include` +- Libraries to `$prefix/lib` + +* source directory (srcdir) +The directory where the original GCC (or binutils/glibc) source code resides. +Often deleted or archived after the build completes. +* sysroot +A directory that acts as a "fake root" (`/`) for headers and libraries. +Used in controlled builds or cross-compilation to isolate from the host system. +* target directory +The directory where *build outputs* are placed — typically the result of `make install` or a direct build artifact. + +This may be the same as `prefix`, or it may be a temporary staging area. It refers specifically to the destination for *this build’s* outputs, not a system path in general. + +Examples: +- `$TOOLCHAIN/bin` if that’s where you are installing +- `DESTDIR=/tmp/stage make install` — `/tmp/stage` is the target directory + + diff --git "a/document\360\237\226\211/terms/glossary.org" "b/document\360\237\226\211/terms/glossary.org" new file mode 100644 index 0000000..87c1cb5 --- /dev/null +++ "b/document\360\237\226\211/terms/glossary.org" @@ -0,0 +1,76 @@ +#+TITLE: RT_gcc Terminology Glossary +#+AUTHOR: Thomas Walker Lynch +#+DATE: 2025-05-06 +#+OPTIONS: toc:nil num:nil +#+LANGUAGE: en + +A glossary of commonly used terms and variables in the GNU toolchain documentation, +with emphasis on their meaning in the context of building GCC. + +* General Terms + +** GCC +The GNU Compiler Collection — a suite of compilers for C, C++, Fortran, and other languages. + +** GNU +GNU's Not Unix — a free software project started by the Free Software Foundation (FSF). + +** FSF +The Free Software Foundation — original sponsor and maintainer of the GNU project and GCC. + +** toolchain +A set of programs used to build software, usually including a compiler (GCC), linker (ld), assembler (as), and C library (glibc or musl). + +** native build +A build where `build = host = target`. You are compiling GCC for the same system you're building it on. + +** cross-compiler +A compiler built on one machine (the build system), to run on another (the host), and generate code for yet another (the target). + +** bootstrap +The process of building GCC in multiple stages: +1. Build a minimal compiler (stage1) +2. Use it to build a full compiler (stage2) +3. Use the result to rebuild itself (stage3) and verify output is stable + + +* Build Triplets + +** build +The system on which the *build process itself* runs. + +** host +The system where the resulting GCC binary will *run*. + +** target +The system for which GCC will *generate code*. +Only meaningful when building a cross-compiler. + +* Build Options + +** --enable- +Turns on an optional feature at configure time. + +** --disable- +Explicitly disables an optional feature. + +** --with-=value +Sets a feature or path used by the build system (e.g., `--with-sysroot`, `--with-pkgversion`). + +** --with-pkgversion +Custom string shown in `gcc --version`, useful to identify modified builds. + +** --with-bugurl +Sets the URL shown in `gcc --version` for reporting bugs. + +** --enable-languages +Limits the frontends to be built (e.g., C, C++, Fortran). +Useful to speed up bootstrap or reduce size. + +** --disable-multilib +Disables building 32-bit and 64-bit variants together (relevant on x86_64 systems). + +* Components + +** binutils +A set of binary tools including `as` diff --git "a/document\360\237\226\211/terms/machine and system roles.org" "b/document\360\237\226\211/terms/machine and system roles.org" new file mode 100644 index 0000000..c2188ea --- /dev/null +++ "b/document\360\237\226\211/terms/machine and system roles.org" @@ -0,0 +1,57 @@ +#+TITLE: Terms - Machine and System Roles +#+AUTHOR: Thomas Walker Lynch +#+DATE: 2025-05-06 + +* Machine vs System + +In this context, "machine" and "system" are often used interchangeably, but they can carry slightly different connotations depending on the context in which they are used. + +** Machine + + - Machine typically refers to the physical hardware or the machine itself — a particular physical computing device, such as a laptop, server, or embedded device. + + - When we talk about the target machine, we are usually referring to the physical or virtual hardware on which the final compiled binaries will run. + +** System + + - System generally refers to the complete environment in which the software operates. This includes the hardware but also extends to the operating system (OS), libraries, and other software that makes up the environment in which the machine operates. + + - The target system refers not just to the physical hardware but to the entire environment where the program will execute, including the OS, libraries, etc. + +** Target Machine vs Target System + + - The target machine is indeed a specific instance of hardware (e.g., a Raspberry Pi or an ARM-based system). + + - The target system can also refer to the environment in which that machine operates, which includes not just the hardware (machine) but also the operating system and the software environment required to run the compiled binaries. + +In many contexts, the terms are used interchangeably, but there’s a subtle distinction: + + - Target Machine emphasizes the hardware aspect. + - Target System emphasizes the complete environment, including hardware, OS, and libraries. + +** Examples + + - Target Machine: "The target machine is an ARM Cortex-M processor." Here, the focus is on the physical hardware. + - Target System: "The target system is an ARM Cortex-M processor running a specific version of an embedded OS." Here, the focus is on both the hardware and the environment (OS, libraries, etc.). + + +* System Roles + +* 'build' +The system on which the GCC compiler **is being built**. + +- John downloads the GCC source code and compiles it on his x86_64 Debian laptop. The GCC compiler **is built on** this laptop, so the build system is Debian on x86_64. +- Sarah uses her macOS machine to build a GCC compiler intended for use on a different system. Even though she won’t run it locally, the compiler **was constructed on macOS**, making macOS the build system. + +* 'host' +The system where the **compiled GCC binary will run** — where you’ll actually invoke `gcc`. + +- Alice builds a GCC binary on Ubuntu, but installs and runs it on an Alpine Linux container. The host is Alpine Linux because that’s where the compiler binary will execute. +- A CI pipeline builds GCC on an x86 Linux node but deploys the resulting `gcc` executable to a FreeBSD system, where users will compile programs. FreeBSD is the host. + +* 'target' +The system for which the **compiled GCC binary will generate code** — where the output binaries are meant to run. + +- Mark compiles a version of GCC that runs on x86 Linux (host), but it produces binaries for ARM Cortex-M chips. The target is ARM Cortex-M. +- A developer builds a GCC compiler on x86 that will run on macOS, and it generates code for RISC-V devices. The target is RISC-V — the eventual destination of the compiled programs. + diff --git "a/document\360\237\226\211/tool_chain_dependency_layers.org" "b/document\360\237\226\211/tool_chain_dependency_layers.org" new file mode 100644 index 0000000..94c7a70 --- /dev/null +++ "b/document\360\237\226\211/tool_chain_dependency_layers.org" @@ -0,0 +1,78 @@ +#+TITLE: Toolchain Dependency Layers +#+AUTHOR: Thomas Walker Lynch +#+DATE: 2025-05-06 +#+OPTIONS: toc:nil num:nil +#+LANGUAGE: en + +* Purpose + +This document outlines the dependencies involved in building a standalone GCC toolchain. It compares two approaches: + +1. Using system-provided tools and headers to build GCC +2. Building a fully self-consistent standalone toolchain + +Understanding the bootstrap sequence is critical for modifying or reproducing GCC builds, especially when building in isolation. + +* The Story: Bootstrap Spiral + +So this programmer — he wanted to add a new directive to GCC. + +So he downloaded the GCC sources with the intent to make a modified, standalone copy. + +But to compile GCC, he needed standard C library headers — which meant downloading glibc. + +But to compile glibc, he needed a working C compiler. So he would first need a minimal GCC — stage 1. + +But to build that stage 1 GCC, he needed glibc headers. + +So he compiled the glibc headers first. + +Then he compiled stage 1 GCC. + +Then he compiled the full glibc. + +Then he compiled the full GCC. + +Ah, but to compile the glibc headers, he first needed the Linux kernel headers... + +There was an old lady who swallowed a fly. I don’t know why she... + +* Approach 1: System-Assisted Bootstrap + +This method uses the host system’s tools and headers to provide bootstrap support. It is simpler and faster, but not fully isolated. + +** Dependencies: + +- System-provided: + - C compiler (e.g. GCC) + - libc (headers and shared objects) + - binutils + - Linux kernel headers + +- Build Steps: + 1. Build binutils using system GCC + 2. Build GCC using system libc and headers + +** Characteristics: +- Fast +- Relies on host environment +- Not self-contained + +** Use Case: +- Building a local variant of GCC that will be used on the same system +- Development where purity or relocatability isn’t required + +* Approach 2: Fully Self-Consistent Toolchain + +This method builds every component of the toolchain in a clean directory, using only upstream sources. It isolates the build from host interference. + +** Dependencies: + +- Linux kernel headers (must be provided up front) +- Binutils source +- Glibc source +- GCC source + +** Build Sequence: + +1. Install Linux kernel headers → needed to build glib diff --git "a/document\360\237\226\211/why_version_12.org" "b/document\360\237\226\211/why_version_12.org" new file mode 100644 index 0000000..f2a8e38 --- /dev/null +++ "b/document\360\237\226\211/why_version_12.org" @@ -0,0 +1,38 @@ +#+TITLE: The Fictional Story of The GCC 15 Install +#+AUTHOR: Thomas Walker Lynch +#+DATE: 2025-05-06 +#+OPTIONS: toc:nil num:nil +#+LANGUAGE: en + +Once upon a time, there was a programmer who wanted to add a new directive to the C preprocessor, cpp. cpp was a simple tool. It expanded macros and did basic text substitutions, nothing more. The programmer thought, “I’ll just modify cpp. That’s easy enough. + +But he could not find cpp. Rather cpp is part of gcc, part and parcel. Well he thought, +gcc is a mature tool, and after making mods to cpp, it will build merely by calling make. + +So he downloaded the latest gcc, gcc-16, but then discovered, there were no release branches. "It won't be stable." He thought, then backed off to gcc-15. + +Then upon attempting to build gcc-15 as baseline before making any mods, he discovered that the system glibc was not version compatible for the build. + +Ok, simple matter, he thought, “I’ll download glibc too. It’s just part of the process.” + +But then attempting to compiling glibc, he encountered something he hadn’t expected. To compile glibc, he needed a version compatible C compiler, and the system compiler is not up to. "Ah I remember," he said as recalled, that gcc can be built in two stages, with the +first stage not requiring glibc, but being sufficient to compile glic. + +So he set to work on the stage 1 GCC, but as he got deeper, he realized that the stage 1 GCC required certain C runtime files — specifically crt1.o, crti.o, and crtn.o. “Ah, no problem,” he said. “I’ll just generate those.” + +The programmer found that the files could be generated using the glibc make file, so he attempted that, but alas, headers were needed, and a version compatible binutils was needed. + +So the programmer downloaded the linux headers and the binutils sources. Binutils could be built with the system gcc, so all was good. + +“Now, I’ve got the CRT files. Let’s move on,” he thought. With the CRT files in hand, he turned to compiling the glibc headers. This was simple enough, and once those were built, he could proceed with the stage 1 GCC. + +After completing the first stage of GCC, he thought, “Great. Now I can move on to the full glibc. It’s just the next step.” + +And so, he used his stage 1 GCC to compile the full glibc. It wasn’t a complex process, just a bit more time-consuming. But with glibc now fully built, the programmer could finally finish the GCC build. The full toolchain was nearly ready. + +With everything falling into place, the programmer turned to compile the full GCC. And just like that, the toolchain was built. He linked everything together, a self-contained, fully functional GCC, ready for use. + +But you ask me why this story is fiction? Well the answer is simple, because glibc make did not create the crt files. Perhaps it doesn't do that. IDK. + +So this is the story of how we ended up at version 12, which does compile with system tools. + diff --git "a/script_gcc_min-12\360\237\226\211/build_gcc.sh" "b/script_gcc_min-12\360\237\226\211/build_gcc.sh" index 1e6ca88..d198a37 100755 --- "a/script_gcc_min-12\360\237\226\211/build_gcc.sh" +++ "b/script_gcc_min-12\360\237\226\211/build_gcc.sh" @@ -1,31 +1,43 @@ #!/bin/bash +# build_gcc.sh – Build GCC 12.2.0 using system libraries and headers + set -euo pipefail -# Load environment source "$(dirname "$0")/environment.sh" -echo "🔧 Starting final GCC build..." +echo "🔧 Starting GCC build..." -mkdir -p "$GCC_BUILD_FINAL" -pushd "$GCC_BUILD_FINAL" +mkdir -p "$GCC_BUILD" +pushd "$GCC_BUILD" "$GCC_SRC/configure" \ + + --with-pkgversion="RT_gcc standalone by Reasoning Technology" \ + --with-bugurl="https://github.com/Thomas-Walker-Lynch/RT_gcc/issues" \ + --with-documentation-root-url="https://gcc.gnu.org/onlinedocs/" \ + --with-changes-root-url="https://github.com/Thomas-Walker-Lynch/RT_gcc/releases/" \ + + --host="$HOST" \ --prefix="$TOOLCHAIN" \ - --with-sysroot="$SYSROOT" \ - --with-native-system-header-dir=/usr/include \ - --target="$TARGET" \ + --with-local-prefix=/dev/null \ + + --build="$HOST" \ + --target="$HOST" \ + --with-native-system-header-dir="/usr/include/x86_64-linux-gnu" \ --enable-languages=c,c++ \ --enable-threads=posix \ - --enable-shared \ - --disable-nls \ --disable-multilib \ --disable-bootstrap \ - --disable-libsanitizer \ - $CONFIGURE_FLAGS + --disable-nls \ + --with-system-zlib \ + CPPFLAGS_FOR_TARGET="-isystem /usr/include/x86_64-linux-gnu" \ + CFLAGS_FOR_TARGET="-I/usr/include/x86_64-linux-gnu" \ + CXXFLAGS_FOR_TARGET="-I/usr/include/x86_64-linux-gnu" -$MAKE +$MAKE -j"$MAKE_JOBS" $MAKE install popd -echo "✅ Final GCC installed to $TOOLCHAIN/bin" +echo "✅ GCC installed to $TOOLCHAIN/bin" +"$TOOLCHAIN/bin/gcc" --version diff --git "a/script_gcc_min-12\360\237\226\211/build_gcc_final_requisites.sh" "b/script_gcc_min-12\360\237\226\211/build_gcc_final_requisites.sh" deleted file mode 100755 index 5d36697..0000000 --- "a/script_gcc_min-12\360\237\226\211/build_gcc_final_requisites.sh" +++ /dev/null @@ -1,46 +0,0 @@ -#!/bin/bash -set -euo pipefail - -# Load shared environment -source "$(dirname "$0")/environment.sh" - -echo "📦 Checking prerequisites for final GCC..." - -# Required host tools -required_tools=(gcc g++ make curl tar gawk bison flex) -missing_tools=() - -for tool in "${required_tools[@]}"; do - if ! type -P "$tool" > /dev/null; then - missing_tools+=("$tool") - fi -done - -if (( ${#missing_tools[@]} )); then - echo "❌ Missing required tools: ${missing_tools[*]}" - exit 1 -fi - -# Check for libc headers and startup objects in sysroot -required_headers=("$SYSROOT/include/stdio.h") -required_crt_objects=( - "$SYSROOT/lib/crt1.o" - "$SYSROOT/lib/crti.o" - "$SYSROOT/lib/crtn.o" -) - -for hdr in "${required_headers[@]}"; do - if [ ! -f "$hdr" ]; then - echo "❌ C library header missing: $hdr" - exit 1 - fi -done - -for obj in "${required_crt_objects[@]}"; do - if [ ! -f "$obj" ]; then - echo "❌ Startup object missing: $obj" - exit 1 - fi -done - -echo "✅ Prerequisites for final GCC met." diff --git "a/script_gcc_min-12\360\237\226\211/project_requisites.sh" "b/script_gcc_min-12\360\237\226\211/project_requisites.sh" index c6c56ec..1688e92 100755 --- "a/script_gcc_min-12\360\237\226\211/project_requisites.sh" +++ "b/script_gcc_min-12\360\237\226\211/project_requisites.sh" @@ -112,6 +112,15 @@ for mod in "${optional_py_modules[@]}"; do fi done +glibc_version=$(ldd --version 2>/dev/null | head -n1 | grep -oE '[0-9]+\.[0-9]+' | head -n1) +glibc_path=$(ldd /bin/ls | grep 'libc.so.6' | awk '{print $3}') +if [[ -n "$glibc_version" && -f "$glibc_path" ]]; then + found_requisite_list+=("library: glibc @ $glibc_path (version $glibc_version)") +else + missing_requisite_list+=("library: glibc") +fi + + echo echo "Summary:" echo "--------" @@ -141,7 +150,7 @@ else echo " - $item" done echo - echo "These may be expected if you are building them from source:" + echo "The following are expected to be missing if you are building them from source:" echo " - mpc" echo " - isl" echo " - zstd"