创建静态库 libtest.a 存在较大问题。
首先，Ada代码极有可能调用Ada运行时系统（RTS）。如果您创建静态库，则必须显式地调用Ada RTS，无论您是否使用 gprbuild，而且这也适用于您的用户。因此，两者都需要进行相应的配置。
gcc main_c.c -ltest
也不
gprbuild -P c_main
足够了；你会遇到类似这样（甚至更糟）的失败情况：
$ gcc main.c -Lada/lib -ltest
Undefined symbols for architecture x86_64:
"_ada__calendar__delays__delay_for", referenced from:
_Hello in libtest.a(hello.o)
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
其次，Ada代码可能（一定！）需要在程序启动时进行详细说明。当
gprbuild 创建库时，它添加了函数
testinit()，您的 C 代码在调用库的任何接口之前
必须调用该函数，并添加
testfinal()函数，以在库的所有使用结束后调用（大多数人不会费心去做）。
解决第一个问题的方法是创建动态库（Windows上是
.dll，Linux和其他Unix系统上是
.so，Mac OS X上是
.dylib）。要做到这一点，您可以使用
for Library_Kind use "dynamic"; 表示。
（请注意，虽然动态库知道它需要哪些其他库，但它可能不知道在哪里找到它们，所以您需要安排它们在加载器的库搜索路径上）。
解决第二个问题的方法是创建 AdaCore 所谓的
独立动态库，并使其自动初始化。
要实现这一点，您需要添加两个属性：
for Library_Interface use (...); 指定您希望在库外部可见的单元名称列表。其作用是仅将命名单元的源文件和 .ali 文件包含在库中；如果唯一的调用方来自 C，则可能只需要命名一个。for Library_Auto_Init use "true"; - 我认为这实际上是默认设置。
我在 Mac OS X（GNAT GPL 2014）上设置了一个小例子。
子目录ada
项目文件，
library project Prj is
for Languages use ("ada");
for Library_Name use "test";
for Library_Kind use "dynamic";
for Library_Interface use ("hello");
for Library_Auto_Init use "true";
for Library_Src_Dir use "include";
for Library_Dir use "lib";
for Source_Dirs use (".");
for Object_Dir use ".build";
end Prj;
你好.ads，
function Hello return Integer;
pragma Export (C, Hello, "Hello");
你好，adb。
with Number;
function Hello return Integer is
begin
delay 0.001;
return Number.Value;
end Hello;
数字.ads,
package Number is
pragma Elaborate_Body;
Value : Integer := 0;
end Number;
和number.adb
package body Number is
begin
Value := 42;
end Number;
上级目录
该项目的文件，
with "ada/prj";
project C_Main is
for Source_Dirs use (".");
for Languages use ("c");
for Main use ("main.c");
for Exec_Dir use ".";
for Object_Dir use ".build";
end C_Main;
和 main.c
#include <stdio.h>
extern int Hello(void);
int main() {
int hello = Hello();
printf("Hello returned %d.\n", hello);
return 0;
}
构建
$ gprbuild -p -P c_main
gcc -c main.c
gcc -c -fPIC number.adb
gcc -c -fPIC hello.adb
gprlib test.lexch
gnatbind -n -o b__test.adb -Ltest -a /Users/simon/tmp/crychair/ada/.build/number.ali ...
gcc -c -x ada -gnatA -gnatws b__test.adb -o b__test.o ...
gcc -dynamiclib -shared-libgcc -o /Users/simon/tmp/crychair/ada/lib/libtest.dylib ... /Users/simon/tmp/crychair/ada/.build/number.o ...
ar cr libc_main.a ...
ranlib -c libc_main.a
gcc main.o -o main
和执行：
$ ./main
Hello returned 42.
要将您的库分发给在另一台计算机上的C用户，而无需安装Ada运行时，您需要打包
libtest.so（或
.dylib或
.dll）和所需的Ada共享库。
在Unix系统上，您可以使用
ldd libtest.so来查找这个信息。您要找的是
libgnat*.so和
libgnarl*.so。您应该能够在编译器的对象搜索路径中找到它们（通常是
gnatls -v输出的“Object Search Path”部分的最后一行）。通常会有符号链接：
libgnat.so -> libgnat.1.so
libgnat.1.so -> libgnat.1.0.0.so
libgnat.1.0.0.so (the real thing)
将共享库和符号链接放在一个目录中，例如
product/ 目录下的
libtest.so 文件，然后您的用户应该能够使用以下方式进行链接。
gcc main.c -o main -Lproduct -ltest
或者可能
gcc main.c -o main -Lproduct -ltest -lgnat -lgnarl
根据您的操作系统，生成的可执行文件可能无法在运行时找到共享库。
解决方法之一是将库放置在加载器已经查找的位置，例如/usr/local/lib（这种情况下，您不需要-Lproduct）。
另一种方法是通过设置环境变量（Linux上的LD_LIBRARY_PATH，Mac OS X上的DYLD_LIBRARY_PATH）告诉加载器要查找的位置。
第三种方式是告诉链接器将路径保存在可执行文件中：
gcc main.c -o main -Lproduct -ltest -lgnat -lgnarl -Wl,-rpath,$PWD/product
该软件能在Mac OS X上使用，很可能也能在Linux上使用。
library project prj is来确认它是一个库项目。 - Simon Wright