Go 1.5 中使用 -linkshared 链接共享构建的包时，因工具链错误生成空 -l 参数导致 GCC 链接失败，本质是 go build 在解析共享依赖时未正确提取库名所致。
go 1.5 中使用 `-linkshared` 链接共享构建的包时，因工具链错误生成空 `-l` 参数导致 gcc 链接失败，本质是 `go build` 在解析共享依赖时未正确提取库名所致。
Go 1.5 引入了实验性共享库支持（via -buildmode=shared 和 -linkshared），旨在复用已编译的 .so 文件以加速构建和减少二进制体积。然而，该功能在初始版本中存在关键缺陷：当主程序导入一个通过 go build -buildmode=shared 构建并安装的包（如 worker）后，执行 go build -linkshared 时，链接器会调用 GCC 并传入形如 -l 的无效参数——即 -l 后缺少实际库名（如 -lworker），从而触发 gcc: error: missing argument to ‘-l’ 错误。
该问题源于 Go 工具链在生成链接命令时，未能从已安装的共享包元数据中正确提取库标识符。具体表现为：go install -buildmode=shared 会将动态库写入 $GOROOT/pkg/<arch>_shared/ 或 $GOPATH/pkg/<arch>_shared/ 目录，并生成对应 .shlibs 描述文件；而后续 -linkshared 构建过程在读取这些描述信息时发生解析异常，最终向 GCC 传递了空 -l 标志。
复现示例：
# 1. 构建并安装共享包 worker go build -buildmode=shared -linkshared -o $GOPATH/pkg/linux_amd64_shared/worker.so worker # 2. 在依赖 worker 的项目中构建（失败） go build -linkshared # → gcc: error: missing argument to ‘-l’
根本原因验证：
启用 -x 可观察真实调用命令：
go build -x -linkshared 2>&1 | grep 'gcc.*-l' # 输出类似：/usr/bin/gcc ... -l -Wl,-E ...
可见 -l 后无任何库名，证实为工具链生成逻辑缺陷。
解决方案与注意事项：
- ✅ 升级 Go 版本：该问题已在 Go 1.6 中修复（issue #12236）。强烈建议升级至 Go 1.6+，避免使用 Go 1.5 的共享模式。
- ⚠️ 临时规避（不推荐）：若必须使用 Go 1.5，可尝试手动补全 .shlibs 文件中的库名字段，或改用 gccgo 编译器（但需注意 gccgo 与 gc 工具链 ABI 不兼容，且 -compiler=gccgo 本身在 Go 1.5 中亦不稳定）。
- ❌ 禁用 -linkshared：生产环境应避免在 Go 1.5 中启用共享链接，因其不仅存在此链接错误，还伴随符号冲突、版本不一致等未修复风险。
总结：Go 1.5 的 -linkshared 是一个未完成的实验特性，其链接失败并非用户配置错误，而是工具链内部逻辑缺陷。教程式实践应以稳定版本为准——共享构建功能自 Go 1.6 起才具备基本可用性，后续版本（如 Go 1.10+）进一步优化了共享库管理和跨平台支持。
