工具/软件：TI C/C++编译器
我有一个基于 PA 音频示例的相当大的应用。 它在 K2G 上运行、ARM 和 DSP 都运行 TI-RTOS。 我最近收到了第三方库的更新、这会导致我的 DSP 应用链接失败。 我正在寻求帮助、以了解如何避免这种情况。
故障：
只需将新库添加到链接行中、就会出现几个"错误#10099-D：程序无法放入可用存储器"错误。 我在 config.Bld 中有一个相当复杂的存储器布局。 失败消息告诉我链接器无法放置与 ARM 共享的区域。 我对可能导致这种情况的原因进行了调查，但没有结果。 新库不会(就我所能告诉的内容而言)定义本节中的任何内容。 我已要求供应商提供使用 v8.1构建的库、但这不是唯一的问题。
请注意、我的 config.Bld 有三个部分。 第一部分描述了共享区域。 然后是 ARM 和 DSP 的说明、每个说明都是指共享区域。 排除此库时、所有操作都将起作用。
版本：
我一直在使用8.1版编译器。 此新库是使用 v8.2构建的。 我怀疑存在一些兼容性问题。 我已经尝试使用 v8.2构建我的应用程序、但它无法解决关键问题。 链接仍然失败。 此外、我会收到数十条警告#10278-D 8.2编译器的自述文件将其称为"新编译器"、建议进行一些更改、但我还没有找到具体原因。
我注意到的其他差异：
当我使用 nm6x 转储库内容时、我注意到一个差异、可能会向专家提出一些建议：
工作(较旧)的库有很多这类行：
0x00000000 A｛C816A2B1-EAF8-4575-8BD6-1079DA21DDEF｝
而新的则具有以下内容：
0x00000000 A TI2oI3mLqrt
这表明这种建筑的一些东西是不同的，但除了所有的调试材料，我发现没有吸烟枪。
虽然 Linux 实用程序"readelf"将转储有关 v2.2.2版本的信息、但相同的工具会报告
readelf：错误：m.lib：找不到有效的存档标头
同时、Linux 实用程序 objdump 会处理这两个文件。 每个文件都被报告为"文件格式 ELF32-Little "。
我的系统中的所有其他库都不能被"readelf"读取。
文件"ti-cgt-C6000_8.2.2/closed_fines.html"注意到"CodeGen-3597 ELF 头字段 e_phoff 在不存在程序头时应为0"。 但这并不能解释我的实际链路错误。
