许多应用程序使用自定义链接器命令文件（简称 LCF）来控制代码和数据在目标存储器中的放置。例如，您可能希望将特定文件中的特定数据对象放入目标存储器中的特定位置。这很容易实现，只需使用可用的 LCF 语法来引用所需的目标文件或库。但是，许多开发人员在尝试执行此操作时会遇到一个问题：从 LCF 内部访问先前在链接器的命令行调用中指定的目标文件或库时，链接器会生成“file not found”（文件未找到）错误。大多数情况下，发生此错误的原因是用于访问链接器命令行上文件的语法与用于访问 LCF 中相同文件的语法不一致。

让我们考虑一个简单的示例。假设一个应用程序需要在名为“DDR”的存储器区域中定义名为“app_coeffs”的常量表。此外，假设在位于目标文件 app_coeffs.c.obj 的 .data 段中定义“app_coeffs”数据对象。然后，app_coeffs.c.obj 文件包含在目标文件库 app_data.lib 中。在 LCF 中，可按如下方式控制“app_coeffs”数据对象的放置：

SECTIONS
{
   ...
   .coeffs: { app_data.lib<app_coeffs.c.obj>(.data) } > DDR
   ...
}

现在假设 app_data.lib 对象库位于一个名为“lib”的子目录中（相对于构建应用程序的位置）。为了从构建命令行访问 app_data.lib，可组合使用 –i 和 –l 选项来设置链接器可用于查找 app_data.lib 库的目录搜索路径：

%> armcl <compile options/files> -z -i ./lib -l app_data.lib mylnk.cmd <link options/files>

-i 选项将 lib 子目录添加到目录搜索路径，-l 选项指示链接器查看目录搜索路径中的目录以查找 app_data.lib 库。但是，如果不更新 mylnk.cmd 中对 app_data.lib 的引用，则链接器将无法找到 app_data.lib 库并会生成“file not found”（文件未找到）错误。原因是当链接器在 SECTIONS 指令中遇到对 app_data.lib 的引用时，引用前没有 -l 选项。因此，链接器会尝试打开当前工作目录中的 app_data.lib。

本质上，链接器有几种不同的打开文件的方式：

• 如果指定了路径，链接器将在指定位置查找文件。对于绝对路径，链接器将尝试打开指定目录中的文件。对于相对路径，链接器将进入从当前工作目录开始的指定路径，并尝试在该位置打开文件。
• 如果没有指定路径，链接器将尝试打开当前工作目录中的文件。
• 如果 -l 选项位于文件引用之前，则链接器将尝试在目录搜索路径下的目录之一中查找并打开所引用的文件。通过 –i 选项和环境变量（如 C_DIR 和 ）设置目录搜索路径。

只要在命令行上和所有适用的 LCF 中以一致的方式引用某个文件，链接器就能够找到并打开您的目标文件和库。

回到前面的示例，可在 mylnk.cmd 中对 app_data.lib 的引用前面插入一个 -l 选项，从而确保链接器在构建应用程序时会找到并打开 app_data.lib 库：

SECTIONS
{
   ...
   .coeffs: { -l app_data.lib<app_coeffs.c.obj>(.data) } > DDR
   ...
}

从 LCF 中引用文件时使用 –l 选项的另一个好处是，如果所引用文件的位置发生变化，则可修改目录搜索路径以合并文件的新位置（例如，在命令行中使用 –i 选项），而无需修改 LCF。