# Gprbuild and link options

**URL:** https://forum.ada-lang.io/t/gprbuild-and-link-options/3755
**Category:** General
**Created:** [August 15, 2025, 8:17pm UTC](https://forum.ada-lang.io/t/gprbuild-and-link-options/3755 "2025-08-15T20:17:17Z")
**Posts on this page:** 1
**Showing post:** 1

<div class="post-metadata">

### Author: ![pmunts](https://forum.ada-lang.io/user_avatar/forum.ada-lang.io/pmunts/32/562_2.png) [@pmunts](https://forum.ada-lang.io/u/pmunts)
#### Post date: [August 15, 2025, 8:17pm UTC](https://forum.ada-lang.io/t/gprbuild-and-link-options/3755/1 "2025-08-15T20:17:17Z")

</div>

I’ve been grappling with link options automatically generated when building with **`gprbuild`**. All of this occurs using a cross-toolchain for Linux AArch64 targets, so **`gnatlink`** , **`default.gpr`** and **`default.cgpr`** are invariant.

I first noticed a problem when I tried to cross-compile an Ada program calling subprograms from **`libnng.so`** on a Debian 12 development machine, using the native **`gprbuild`**. It failed to link. The final link command, which was helpfully included in the error output, failed because it included a **`-static`** link option. A lot of third party Linux libraries fail to link statically, so no surprise there. The problem is that my cross-compiled Ada programs are always supposed to be linked dynamically.

I instrumented the build with **`strace`** and it seems that the erroneous **`-static`** link option is being generated by **`gnatbind`**. Which is weird because:

My main build server is still Debian 11. The cross-toolchain packages are bit-for-bit exactly the same on all of my various Debian 11 and Debian 12 machines. I tried compiling the same program on the Debian 11 machine, using the Debian 11 native **`gprbuild`** (now with **`-v`** to see what is going on), and the same cross-toolchain, **`.gpr`** and **`.cgpr`** files, and the build succeeded. I did notice **`-static-libgcc`** (which should be **`-shared-libgcc`** ) in the link options.

So then I uninstalled the Debian 12 native **`gprbuild`** and (painfully) copied the Debian 11 native **`gprbuild`** and its dependencies to the Debian 12 machine and tried again. The result was **`-static-libgcc`** , which indicates that the different outcomes depend on **`gprbuild`** rather than **`gnatbind`** , which is part of the cross-toolchain and invariant across all this testing.

Next I tried using Alire **`gprbuild`** versions 22.0.1 and 25.0.1. The four different versions of **`gprbuild`** I tried on the same Debian 12 build machine using the same cross-toolchain produced wildly varying sets of link options ( **`-static`** , **`-static-libgcc`** , **`-shared-libgcc`** or nothing at all, as well as dynamic **`-lgnat`** / **`-lgnarl`** vs static **`libgnat.a`** / **`libgnarl.a`** ). What I want is **`-shared-libgcc`** , **`libgnat.a`** , and **`libgnarl.a`**. Only one combination of **`gprbuild`** and Debian produces what I want: Alire **`gprbuild`** 22.0.1 on Debian 12.

What I need to figure out is how to coerce what I want from the other combinations, especially since Alire **`gprbuild`** version 22.0.1 is not available for the 64-bit Raspberry Pi. Can somebody explain how the link options are generated and aggregated when building with **`gprbuild`**?

---

_[View the full topic](https://forum.ada-lang.io/t/gprbuild-and-link-options/3755)._