{"id":20971426,"url":"https://github.com/amanoteam/obggcc","last_synced_at":"2026-04-02T19:30:50.195Z","repository":{"id":153807731,"uuid":"617709837","full_name":"AmanoTeam/obggcc","owner":"AmanoTeam","description":"Linux C/C++ cross-compiler targeting older glibc versions","archived":false,"fork":false,"pushed_at":"2026-03-31T15:28:48.000Z","size":1048,"stargazers_count":52,"open_issues_count":1,"forks_count":2,"subscribers_count":5,"default_branch":"master","last_synced_at":"2026-03-31T16:24:14.091Z","etag":null,"topics":["c","cpp","cross-compiler","gcc","glibc","linux"],"latest_commit_sha":null,"homepage":"","language":"CMake","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"lgpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/AmanoTeam.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2023-03-23T00:15:00.000Z","updated_at":"2026-03-23T14:08:51.000Z","dependencies_parsed_at":"2026-02-23T17:01:53.942Z","dependency_job_id":null,"html_url":"https://github.com/AmanoTeam/obggcc","commit_stats":{"total_commits":23,"total_committers":1,"mean_commits":23.0,"dds":0.0,"last_synced_commit":"37523d54dc9b207f0a17f3e186cca40663c92acd"},"previous_names":[],"tags_count":65,"template":false,"template_full_name":null,"purl":"pkg:github/AmanoTeam/obggcc","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AmanoTeam%2Fobggcc","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AmanoTeam%2Fobggcc/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AmanoTeam%2Fobggcc/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AmanoTeam%2Fobggcc/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/AmanoTeam","download_url":"https://codeload.github.com/AmanoTeam/obggcc/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AmanoTeam%2Fobggcc/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31314378,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-02T12:59:32.332Z","status":"ssl_error","status_checked_at":"2026-04-02T12:54:48.875Z","response_time":89,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["c","cpp","cross-compiler","gcc","glibc","linux"],"created_at":"2024-11-19T04:01:52.440Z","updated_at":"2026-04-02T19:30:50.186Z","avatar_url":"https://github.com/AmanoTeam.png","language":"CMake","readme":"# OBGGCC\n\nA Clang and GCC cross-compiler targeting older glibc versions.\n\n## How it works\n\nI extracted the sysroots from almost all major legacy Debian releases and built a cross-compiler for each. Each toolchain targets a specific Debian version, and therefore a specific glibc version.\n\nThis eliminates the need to install an ancient Linux distribution in Docker/LXC just to build portable binaries, which is the current standard practice.\n\n## Use cases\n\nOBGGCC solves errors like:\n\n```\n./main: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by ./main)\n./main: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./main)\n```\n\nThese occur when you build on a system with a newer glibc than the target system. Most of the time, you don’t need a newer version of a glibc function when compiling, but manually selecting a specific version is a pain, especially if you’re compiling someone else’s code or working on a project with multiple dependencies.\n\n## Supported targets\n\nCurrently, OBGGCC provides cross-compilers targeting 6 major Ubuntu releases and 9 major Debian releases on 5 system architectures.\n\n### Distributions\n\n| distribution_version              | glibc_version | linux_version | gcc_version | availability_date |\n| :-------------------------------: | :-----------: | :-----------: | :---------: | :---------------: |\n| Debian 4 (Etch)                  | glibc 2.3.6   | Linux 2.6.18  | GCC 4.1.1   | 2007              |\n| Debian 5 (Lenny)                 | glibc 2.7     | Linux 2.6.26  | GCC 4.3.2   | 2009              |\n| Debian 6 (Squeeze)               | glibc 2.11    | Linux 2.6.32  | GCC 4.4.5   | 2011              |\n| Debian 7 (Wheezy)                | glibc 2.13    | Linux 3.2.78  | GCC 4.7.2   | 2013              |\n| Ubuntu 12.04 (Precise Pangolin)  | glibc 2.15    | Linux 3.2.0   | GCC 4.6.3   | 2012              |\n| Debian 7 (Sid)                   | glibc 2.17    | Linux 3.12.9  | GCC 4.8.2   | 2014              |\n| Debian 8 (Jessie)                | glibc 2.19    | Linux 3.16.56 | GCC 4.9.2   | 2015              |\n| Ubuntu 16.04 (Xenial Xerus)      | glibc 2.23    | Linux 4.4.0   | GCC 5.3.1   | 2016              |\n| Debian 9 (Stretch)               | glibc 2.24    | Linux 4.9.228 | GCC 6.3.0   | 2017              |\n| Ubuntu 18.04 (Bionic Beaver)     | glibc 2.27    | Linux 4.15.0  | GCC 7.3.0   | 2018              |\n| Debian 10 (Buster)               | glibc 2.28    | Linux 4.19.249| GCC 8.3.0   | 2019              |\n| Debian 11 (Bullseye)             | glibc 2.31    | Linux 5.10.223| GCC 10.2.1  | 2021              |\n| Ubuntu 22.04 (Jammy Jellyfish)   | glibc 2.35    | Linux 5.15.0  | GCC 11.2.0  | 2022              |\n| Ubuntu 24.04 (Noble Numbat)      | glibc 2.39    | Linux 6.8.0   | GCC 13.2.0  | 2024              |\n\n### System architectures\n\n- `aarch64-unknown-linux-gnu`\n- `arm-unknown-linux-gnueabi`\n- `arm-unknown-linux-gnueabihf`\n- `i386-unknown-linux-gnu`\n- `x86_64-unknown-linux-gnu`\n\n### Quick start\n\nFirst, start by [downloading the precompiled binaries for your platform](#releases). For reference, you can download the prebuilt binaries of the toolchain for Linux x86_64 with:\n\n```\n$ wget https://github.com/AmanoTeam/obggcc/releases/download/latest/x86_64-unknown-linux-gnu.tar.xz\n$ tar --extract --file=x86_64-unknown-linux-gnu.tar.xz\n```\n\nAfter unpacking the tarball, you will find the cross-compiler as well as wrapper scripts for targeting specific glibc versions inside the `obggcc/bin` directory:\n\n```\n$ ls obggcc/bin\n...\nx86_64-unknown-linux-gnu2.31-clang\nx86_64-unknown-linux-gnu2.31-clang++\nx86_64-unknown-linux-gnu2.31-g++\nx86_64-unknown-linux-gnu2.31-gcc\n...\n```\n\nYou can use them as follows:\n\n```\n# Compile C programs\n$ x86_64-unknown-linux-gnu2.31-gcc main.c -o main\n# Compile C++ programs\n$ x86_64-unknown-linux-gnu2.31-g++ main.c -o main\n```\n\nIf you prefer, you can use Clang instead of GCC. Just make sure to replace the `gcc`/`g++` suffixes with `clang`/`clang++`.\n\n## Cross-compilation\n\n### CMake\n\nInside the `obggcc/build/cmake` directory, there is a custom CMake toolchain file for each cross-compilation target OBGGCC supports:\n\n```bash\n$ ls obggcc/build/cmake\naarch64-unknown-linux-gnu.cmake\naarch64-unknown-linux-gnu2.19.cmake\n...\narm-unknown-linux-gnueabi.cmake\narm-unknown-linux-gnueabi2.11.cmake\n...\narm-unknown-linux-gnueabihf.cmake\narm-unknown-linux-gnueabihf2.13.cmake\n...\ni386-unknown-linux-gnu.cmake\ni386-unknown-linux-gnu2.11.cmake\n...\nx86_64-unknown-linux-gnu.cmake\nx86_64-unknown-linux-gnu2.11.cmake\n...\n```\n\nTo use one of them, pass the `CMAKE_TOOLCHAIN_FILE` definition to your CMake command invocation:\n\n```bash\n# Setup the environment for cross-compilation\n$ cmake \\\n    -DCMAKE_TOOLCHAIN_FILE=obggcc/build/cmake/aarch64-unknown-linux-gnu2.19.cmake \\\n    -B build \\\n    -S  ./\n# Build the project\n$ cmake --build ./build\n```\n\n### GNU Autotools (aka GNU Build System)\n\nInside the `obggcc/build/autotools` directory, there is a custom bash script for each cross-compilation target that OBGGCC supports:\n\n```bash\n$ ls obggcc/build/autotools\naarch64-unknown-linux-gnu.sh\naarch64-unknown-linux-gnu2.19.sh\n...\narm-unknown-linux-gnueabi.sh\narm-unknown-linux-gnueabi2.11.sh\n...\narm-unknown-linux-gnueabihf.sh\narm-unknown-linux-gnueabihf2.13.sh\n...\ni386-unknown-linux-gnu.sh\ni386-unknown-linux-gnu2.11.sh\n...\nx86_64-unknown-linux-gnu.sh\nx86_64-unknown-linux-gnu2.11.sh\n...\n```\n\nThey are meant to be `source`d by you whenever you want to cross-compile something:\n\n```bash\n# Setup the environment for cross-compilation\n$ source obggcc/build/autotools/aarch64-unknown-linux-gnu2.19.sh\n\n# Configure \u0026 build the project\n$ ./configure --host=\"${CROSS_COMPILE_TRIPLET}\"\n$ make\n```\n\nEssentially, these scripts handle the setup of `CC`, `CXX`, `LD`, and other environment variables so you don’t need to configure them manually.\n\nTo restore your environment to its original state, run the `deactivate.sh` script from the same directory:\n\n```bash\n$ source obggcc/build/autotools/deactivate.sh\n```\n\n## Controlling OBGGCC Behavior\n\nOBGGCC allows you to change its behavior in certain scenarios through the use of environment variables. Below are all the switches OBGGCC supports and their intended purposes:\n\n- `OBGGCC_SYSTEM_LIBRARIES`  \n  - Allows you to compile and link code using libraries and headers from your host machine’s system root in conjunction with the cross-compiler’s system root. See [Linking with system libraries](#linking-with-system-libraries).\n\n- `OBGGCC_BUILTIN_LOADER`  \n  - Allows you to change the dynamic linker of an executable during linkage so that it can be run using OBGGCC’s glibc libraries rather than your host machine’s glibc libraries. See [Running binaries with a specific glibc](#running-binaries-with-a-specific-glibc).\n\n- `OBGGCC_RUNTIME_RPATH`  \n  - Automatically appends the path to the directory containing the GCC runtime libraries (e.g., libsanitizer (AddressSanitizer), libatomic, and libstdc++) to your executables’ RPATH. This option is enabled by default when using `OBGGCC_BUILTIN_LOADER`.\n\n- `OBGGCC_NZ`  \n  - Allows you to use libraries and headers installed using OBGGCC’s package manager (nz) during cross-compilation. See [Software availability](#software-availability).\n\n- `OBGGCC_STATIC_RUNTIME`  \n  - Tells the cross-compiler to prefer linking with the static versions of the GCC runtime libraries rather than the dynamic ones.\n\n- `OBGGCC_ARM_MODE`  \n  - Tells the cross-compiler to generate code in ARM mode rather than Thumb-1/Thumb-2 mode.\n\n- `OBGGCC_VERBOSE`  \n  - Display the GCC subcommand invocation and the current working directory for every compilation process.\n\n- `OBGGCC_STL_VERSION`  \n  - Cross-compile code targeting a specific version of the GCC runtime libraries, rather than using the ones shipped with the compiler. See [Choosing an arbitrary GCC runtime version](#choosing-an-arbitrary-gcc-runtime-version).\n\nYou can enable a switch by setting its value to `true` (e.g: `export OBGGCC_NZ=true`), and disable it by setting its value to `false` (e.g: `export OBGGCC_NZ=false`).\n\nFor every environment variable, there is a matching command-line flag switch available, which you can check with `--obggcc-help`.\n\n```\n$ arm-unknown-linux-gnueabi2.7-gcc --obggcc-help\nusage: arm-unknown-linux-gnueabi2.7-gcc [-f[no-]builtin-loader] [-f[no-]runtime-rpath] [-f[no-]system-libraries] [-f[no-]nz] [-f[no-]static-runtime] [-f[no-]verbose]\n\nLinux C/C++ cross-compiler for targeting older glibc versions.\n\noptions:\n  -f[no-]builtin-loader\n                        Override the default dynamic linker to point to the local glibc installation within OBGGCC.\n  -f[no-]runtime-rpath  Automatically append the path to the directory containing GCC runtime libraries to every executable's DT_RPATH.\n  -f[no-]system-libraries\n                        Allow compilation and linking with libraries and headers from your host machine’s system root alongside the cross-compiler’s system root.\n  -f[no-]nz             Use libraries and headers installed by OBGGCC’s package manager (nz) during cross-compilation.\n  -f[no-]static-runtime\n                        Force linking with static variants of the GCC runtime libraries instead of the dynamic versions.\n  -f[no-]verbose        Display the GCC subcommand invocation and the current working directory.\n\nThe flag switches listed above are not guaranteed to be portable and are primarily intended for testing purposes.\n```\n\n## Software availability\n\nThe cross-compiler ships only with the minimum required to build a working C/C++ program. That is, you won't find any prebuilt binaries of popular projects like OpenSSL or zlib available for use, as you would on an average Linux distribution.\n\nIf your project depends on something other than the GNU C library (or the C++ standard libraries, for C++ programs), you need to either build it yourself or install it from somewhere else. For convenience, OBGGCC provides an APT-like tool to install packages from APT repositories to a local directory and enable their usage during cross-compilations.\n\n### Installing project dependencies with `nz`\n\nYou can install packages to a specific system root using the corresponding `\u003ctriplet\u003e\u003cglibc_version\u003e-nz` command inside the `obggcc/bin` directory.\n\nFor example, let's suppose you want to cross-compile curl for Ubuntu 16.04 (glibc 2.23) with SSL and HTTP/2 support:\n\n#### Step 1\n\nFirst, fetch curl sources and generate the required build files:\n\n```bash\n$ git clone -b curl-8_14_1 https://github.com/curl/curl\n$ cd curl\n$ autoreconf -fi\n```\n\n#### Step 2\n\nNow, configure the environment for cross-compilation:\n\n```bash\n$ source obggcc/build/autotools/x86_64-unknown-linux-gnu2.23.sh\n```\n\n#### Step 3\n\nInstall the required dependencies:\n\n```bash\n$ x86_64-unknown-linux-gnu2.23-nz \\\n    --install 'libnghttp2-dev;libssl-dev;zlib1g-dev;libpsl-dev'\n```\n\nThere is also an `apt` script wrapper around `nz` that you can use to install packages _à la_ the APT way:\n\n```bash\n$ x86_64-unknown-linux-gnu2.23-apt install \\\n    libnghttp2-dev \\\n    libssl-dev \\\n    zlib1g-dev \\\n    libpsl-dev\n```\n\n#### Step 4\n\nBefore cross-compiling curl, set the `OBGGCC_NZ` environment variable to enable OBGGCC to use libraries from nz's system root during the build:\n\n```bash\n$ export OBGGCC_NZ=true\n```\n\n#### Step 5\n\nNow you can build curl the usual way:\n\n```bash\n$ ./configure \\\n    --host=\"${CROSS_COMPILE_TRIPLET}\" \\\n    --with-openssl \\\n    --with-nghttp2 \n$ make\n```\n\n## Linking with system libraries\n\nBy default, you can't mix headers and libraries from both the cross-compiler's system root and your host machine's system root. The main reason is that there may be incompatibilities between the two systems, which could cause the compilation to break or produce broken binaries even if the compilation succeeds. Due to this, the standard practice is that you also cross-compile any external dependency that your program may need to use and put them inside the cross-compiler's system root or explicitly point the compiler to where to find the cross-compiled dependencies by passing the appropriate flags when compiling your binary (`-I`, `-L`, and `-l`).\n\nThat being said, the GNU C library is portable enough to reduce these incompatibilities to some extent.\n\nThe environment variable `OBGGCC_SYSTEM_LIBRARIES` can be used to force OBGGCC to use your host machine's system root when cross-compiling.\n\nLet's take as an example this program which uses OpenSSL to perform a simple SHA-256 calculation:\n\n```c\n#include \u003cstring.h\u003e\n#include \u003cstdio.h\u003e\n\n#include \u003copenssl/sha.h\u003e\n\nint main(void) {\n    unsigned char hash[SHA256_DIGEST_LENGTH];\n    SHA256(\"OBGGCC\", 6, hash);\n    \n    puts(\"It works!\");\n    \n    return 0;\n}\n```\n\nWhen compiling this program on my host machine, it builds fine:\n\n```bash\n$ gcc main.c -lcrypto -o main\n$ ./main\nIt works!\n```\n\nHowever, it fails when cross-compiling with OBGGCC:\n\n```bash\n$ x86_64-unknown-linux-gnu2.3-gcc main.c -lcrypto -o main\nmain.c:3:10: fatal error: openssl/sha.h: No such file or directory\n    3 | #include \u003copenssl/sha.h\u003e\n      |          ^~~~~~~~~~~~~~~\ncompilation terminated.\n```\n\nThat's because there are no prebuilt OpenSSL binaries in the cross-compiler's sysroot.\n\nNow let's try setting the `OBGGCC_SYSTEM_LIBRARIES` environment variable:\n\n```bash\n$ export OBGGCC_SYSTEM_LIBRARIES=true\n```\n\nAnd then compiling the program again:\n\n```bash\n$ x86_64-unknown-linux-gnu2.3-gcc main.c -lcrypto -o main\n$ ./main\nIt works!\n```\n\nThe reason for the build to succeed this time is that `OBGGCC_SYSTEM_LIBRARIES` changes the default cross-compilation behavior so that system directories of the host machine get included in both the library and header location search lists of the cross-compiler.\n\nEssentially, it:\n\n- Adds `/usr/include ` to the list of include directories\n- Adds `/usr/local/lib64`, `/usr/local/lib`, `/lib64`, `/lib`, `/usr/lib64`, and `/usr/lib` to the list of library directories\n\nNote that, despite explicitly adding directories of the host machine to the compiler invocation, any program you compile will still link against the cross-compiler's glibc. That's due to the fact that the directories of the cross-compiler's system root are checked first before the directories of your host machine's system root. Only when the compiler can't find a specific header or library in the cross-compiler's system root does it search for it in your machine's system root. This way, we can build portable programs while still linking against third-party libraries from the host machine.\n\nKeep in mind that `OBGGCC_SYSTEM_LIBRARIES` is only useful when you are cross-compiling software to a target that matches the one of your host machine (e.g., your host machine is an `x86_64-linux-gnu` system, and you are cross-compiling software targeting an `x86_64-linux-gnu` system as well), as you can't link binaries with mismatching ABIs:\n\n```bash\n# My machine is an x86_64 system\n$ gcc -dumpmachine\nx86_64-unknown-linux-gnu\n\n# This will work, as both targets match\n$ x86_64-unknown-linux-gnu2.3-gcc main.c -lcrypto -o main\n\n# But this won't work; mismatching architectures\n$ aarch64-unknown-linux-gnu2.19-gcc main.c -lcrypto -o main\nld: skipping incompatible /lib64/libcrypto.so when searching for -lcrypto\nld: skipping incompatible /usr/lib64/libcrypto.so when searching for -lcrypto\nld: cannot find -lcrypto: No such file or directory\nld: skipping incompatible /lib64/libcrypto.so when searching for -lcrypto\nld: skipping incompatible /usr/lib64/libcrypto.so when searching for -lcrypto\ncollect2: error: ld returned 1 exit status\n```\n\nThis also works if your system has multilib support (i.e., both 32-bit and 64-bit libraries coexist on the same system) and you are cross-compiling software targeting the 32-bit version of your system:\n\n```bash\n$ dpkg --print-architecture\namd64\n$ dpkg --print-foreign-architectures\ni386\n\n# This wil work\n$ x86_64-unknown-linux-gnu2.3-gcc main.c -lcrypto -o main\n$ ./main\nIt works!\n\n# This will work as well\n$ i386-unknown-linux-gnu2.3-gcc main.c -lcrypto -o main\n$ ./main\nIt works!\n```\n\n## Running binaries with a specific glibc\n\nThere may be cases where you might want to run your software under a specific glibc version, either to check how it will behave or to try a new glibc feature that was added in a later version but isn’t available in the glibc installed on your system.\n\nThe environment variable `OBGGCC_BUILTIN_LOADER` can be used to change the default loader (aka dynamic linker) of an executable when cross-compiling. In other words, you can use this to force your binary to use a different glibc at runtime, ignoring the one available in your system.\n\nFor some background, here is my current system:\n\n```bash\n$ cat /etc/os-release\nNAME=\"CentOS Linux\"\nVERSION=\"7 (Core)\"\n...\n\n$ ldd --version\nldd (GNU libc) 2.17\n...\n```\n\nI'm running CentOS 7 with glibc 2.17. Let's suppose I want to try the new `getrandom()` routine that was introduced in glibc 2.25. I would then write something like this:\n\n```c\n#include \u003cstdio.h\u003e\n#include \u003csys/random.h\u003e\n\nint main(void) {\n    \n    size_t index = 0;\n    \n    unsigned char buffer[16];\n    getrandom(buffer, sizeof(buffer), 0);\n    \n    for (index = 0; index \u003c sizeof(buffer); index++) {\n        if (index != 0) {\n            printf(\" \");\n        }\n        \n        printf(\"0x%X\", buffer[index]);\n    }\n    \n    printf(\"\\nIt works!\\n\");\n    \n}\n```\n\nI can try compiling it on my host machine, but that will just fail:\n\n```bash\n$ gcc main.c\nmain.c:3:10: fatal error: sys/random.h: No such file or directory\n    3 | #include \u003csys/random.h\u003e\n      |          ^~~~~~~~~~~~~~\ncompilation terminated.\n```\n\nI can try cross-compiling my code to glibc 2.25+, but then I would not be able to run it on my machine due to the older glibc it has:\n\n```\n$ x86_64-unknown-linux-gnu2.27-gcc main.c -o main\n$ ./main\n./main: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by ./main)\n```\n\nHowever, things change when I use `OBGGCC_BUILTIN_LOADER`:\n\n```bash\n$ export OBGGCC_BUILTIN_LOADER=true\n$ x86_64-unknown-linux-gnu2.27-gcc main.c -o main\n$ ./main\n0x67 0xE4 0xD3 0x9B 0xBD 0xD2 0x59 0x86 0xC0 0xE7 0x79 0xD2 0x2 0x92 0x3C 0x85\nIt works!\n```\n\nThis worked this time because `OBGGCC_BUILTIN_LOADER` changed the default loader for the executable `main` so that at runtime it uses the glibc bundled within OBGGCC instead of relying on the glibc library installed on my system.\n\nWe can check this by inspecting the executable with `readelf`:\n\n```bash\n$ readelf -l main | grep \"interpreter:\"\n    [Requesting program interpreter: /home/runner/obggcc/x86_64-unknown-linux-gnu2.27/lib/ld-linux-x86-64.so.2]\n$ readelf -d main | grep \"RPATH\"\n    Library rpath: [/home/runner/obggcc/x86_64-unknown-linux-gnu2.27/lib]\n```\n\n## Choosing an arbitrary GCC runtime version\n\nBy default, cross-compilation links against the runtime libraries of the GCC version used for the build. For bleeding-edge releases, this gives you access to the latest features the compiler has to offer, but comes with the drawback that you will probably need to bundle the GCC libraries or statically link them with your binary (especially for C++ code) if you want it to run out of the box on systems that use an older version of GCC as the base system compiler.\n\nIf portability takes precedence over new features for you, it is possible to choose an arbitrary GCC runtime version to use during the build.\n\n### Usage\n\nThe extra runtimes are not shipped with ordinary releases by default because they take a lot of storage space. To use them, you need to manually install them using the `gcc-stl-install` tool:\n\n```bash\n$ gcc-stl-install x86_64-unknown-linux-gnu\n```\n\nFor other architectures, replace `x86_64-unknown-linux-gnu` with the corresponding target triplet.\n\nTo make the cross-compiler use them, set the `OBGGCC_STL_VERSION` environment variable to the GCC version you intend the compiled code to be compatible with. Currently, this variable accepts values from `4` to `14`:\n\n```bash\n# Set it to use the GCC 12 runtime\n$ export OBGGCC_STL_VERSION=12\n# Now just use the compiler as you normally would\n$ x86_64-unknown-linux-gnu2.31-g++ [...]\n```\n\nTo make the runtime version match the one used by the distro you are targeting, simply set the version to the one specified in the `gcc_version` field of the [Distributions](#distributions) table.\n\n## Debugging\n\n### AddressSanitizer\n\nAddressSanitizer is available for almost all cross-compilation targets, so you can use it with the usual `-fsanitize=...` flags if needed:\n\n```bash\n$ cat \u003c\u003c asan \u003e main.c\n#include \u003cstddef.h\u003e\n\nint main() {\n    char s =  *((char*) NULL);\n}\nasan\n$ x86_64-unknown-linux-gnu2.3-gcc -fsanitize=address main.c -o main -O0 -g\n$ ./main\nAddressSanitizer:DEADLYSIGNAL\n...\nSUMMARY: AddressSanitizer: SEGV /home/runner/main.c:4 in main\n==19765==ABORTING\n```\n\nIf you are playing around with AddressSanitizer, you might want to set the `OBGGCC_RUNTIME_RPATH` environment variable:\n\n```bash\nexport OBGGCC_RUNTIME_RPATH=true\n```\n\nThis tells the linker to automatically add the `RPATH` of the directory containing the AddressSanitizer libraries to your executable, so you don't have to bother with setting the `LD_LIBRARY_PATH` or adding the rpath manually:\n\n```bash\n$ x86_64-unknown-linux-gnu2.3-gcc -fsanitize=address main.c -o main\n$ ./main\n./main: error while loading shared libraries: libasan.so.8: cannot open shared object file: No such file or directory\n$ export OBGGCC_RUNTIME_RPATH=true\n$ x86_64-unknown-linux-gnu2.3-gcc -fsanitize=address main.c -o main\n$ ./main\n\u003cit works\u003e\n```\n\n## GDB (GNU Debugger)\n\nThere are also bundled binaries of GDB available for use:\n\n```\n$ ls obggcc/bin/*-gdb\nobggcc/bin/aarch64-unknown-linux-gnu-gdb\nobggcc/bin/arm-unknown-linux-gnueabi-gdb\nobggcc/bin/arm-unknown-linux-gnueabihf-gdb\nobggcc/bin/i386-unknown-linux-gnu-gdb\nobggcc/bin/x86_64-unknown-linux-gnu-gdb\n```\n\nNote that we don't provide prebuilt binaries of the gdb-server. If you want to use GDB for cross-debugging, you should build it yourself.\n\n## Building OBGGCC\n\n*Compiling OBGGCC from source is best supported on Linux. We recommend using a Debian/Ubuntu-based distribution for this.*\n\nStart by installing the dependencies with:\n\n```\n$ sudo apt-get install build-essential autoconf libtool jq python3-minimal zsh\n```\n\nThen, clone the repository with:\n\n```\n$ git clone https://github.com/AmanoTeam/obggcc\n$ cd obggcc\n$ git submodule update --init --depth=1\n$ git -C submodules/nz submodule update --init --depth=1\n```\n\nBuild the project with:\n\n```\n$ ./build.sh\n```\n\nThis will fetch the GCC sources and build a cross-compiler for all supported architectures.\n\nBy default, it will install everything to `/var/tmp`, but you can customize the location by setting the `OBGGCC_BUILD_DIRECTORY` environment variable:\n\n```\n$ export OBGGCC_BUILD_DIRECTORY=path/to/directory\n$ ./build.sh\n```\n\nYou can also customize the build parallelism with `OBGGCC_BUILD_PARALLEL_LEVEL`:\n\n```\n$ export OBGGCC_BUILD_PARALLEL_LEVEL=$(nproc)\n$ ./build.sh\n```\n\nThe GCC version can be selected using `OBGGCC_RELEASE`.\n\n```\n$ export OBGGCC_RELEASE=15\n$ ./build.sh\n```\n\nYou can also customize which targets the toolchain will support for cross-compilation using `OBGGCC_TARGETS`. For a minimal build with support for a single architecture and a specific glibc version, you can do something like:\n\n```\n# Build a cross-compiler targeting glibc 2.17 on x86_64.\n$ export OBGGCC_TARGETS='x86_64-unknown-linux-gnu,x86_64-unknown-linux-gnu2.17'\n$ ./build.sh\n```\n\nYou can find the list of supported target triplets [here](#system-architectures) and the list of supported glibc versions [here](#distributions). \n\n## Releases\n\nYou can obtain OBGGCC releases from the [releases](https://github.com/AmanoTeam/obggcc/releases) page.","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Famanoteam%2Fobggcc","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Famanoteam%2Fobggcc","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Famanoteam%2Fobggcc/lists"}