必须将库路径和库名正确传入且顺序为先目标文件后库：gcc main.c -L. -lmath_utils -o main；链接器从左到右解析，依赖库须在使用它的目标文件之后，否则失败。
gcc 链接静态库时，必须显式指定静态库路径和库名，且顺序不能错——库必须放在目标文件之后，否则会链接失败。
静态库文件名必须带 .a 后缀，且命名要符合 lib<name>.a 规范
比如你要链接的库叫 myutil，那它的静态库文件名必须是 libmyutil.a。如果实际文件是 myutil.a 或 myutil.lib，gcc 会直接忽略或报错 cannot find -lmyutil。
-
gcc main.o -L./libs -lmyutil -o app→ 正确（假设./libs/libmyutil.a存在） -
gcc main.o -lmyutil -L./libs -o app→ 错误（-L必须在-l前生效） -
gcc main.o ./libs/myutil.a -o app→ 可行但绕过-l机制，不推荐（失去自动符号解析优势）
-L 和 -l 的作用与常见错误
-L 告诉链接器去哪找库目录，-l 告诉它要链接哪个库（自动补 lib 前缀和 .a 后缀）。两者配合才有意义。
- 只写
-lmyutil不加-L→ 默认只查系统路径（如/usr/lib），找不到就报错 -
-L./libs但库不在该目录下 → 报cannot find -lmyutil，不是“找不到文件”，而是“没找到匹配的libmyutil.a” - 多个
-L时，按从左到右顺序搜索，第一个命中即停
如何确认静态库是否真被链接进可执行文件
链接完成后，用 file 和 nm 检查比看输出更可靠：
-
file app→ 输出含statically linked才是真的全静态；若含dynamically linked，说明你链接的是动态库，或某些依赖仍走动态 -
nm -C app | grep 'myutil_function'→ 能看到符号且类型为T（text）或D（data），说明已静态合并 -
ldd app→ 对纯静态可执行文件会提示not a dynamic executable；如果列出一堆libc.so等，说明仍有动态依赖
最容易被忽略的一点：即使你用了 -static，GCC 仍可能跳过某些第三方静态库（比如没装 libxxx-static 包），转而链接动态版本。真正控制单个库是否静态，靠的是 -L+-l 显式指向 .a 文件，而不是依赖 -static 全局开关。
