-l在arm none eabi gcc中的用法
Usage of -l for arm-none-eabi-gcc
我正试图使用arm-none eabi gcc离线编译一些mbed代码,当我试图将mbed文件夹移到目录外时遇到了麻烦。生成文件中的命令是
arm-none-eabi-gcc -mcpu=cortex-m0plus -mthumb -Wl,--gc-sections --specs=nano.specs -u _printf_float -u _scanf_float -T../libraries//mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM/MKL25Z4.ld -L./mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM -o Example.elf main.o ../libraries//mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM/retarget.o ../libraries//mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM/board.o ../libraries//mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM/cmsis_nvic.o ../libraries//mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM/mbed_overrides.o ../libraries//mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM/system_MKL25Z4.o ../libraries//mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM/startup_MKL25Z4.o -lmbed -lstdc++ -lsupc++ -lm -lc -lgcc -lnosys -lmbed -lstdc++ -lsupc++ -lm -lc -lgcc -lnosys
名为mbed的文件夹包含基本mbed编程所需的所有头文件和.o文件。然而,当我试图将mbed文件夹移动到另一个文件夹并相对寻址时,我会收到一个错误:
cannot find -l../libraries/mbed
为-l选项提供相对路径是错误的吗?如果是,我该如何解决这个问题?
使用gcc的-L
选项来指示要查找库的位置。参见手册:
链接器在标准目录列表中搜索库,该库实际上是一个名为
liblibrary.a
的文件。然后链接器使用这个文件,就好像它是按名称精确指定的一样。
搜索的目录包括几个标准系统目录以及您使用-L
指定的任何目录。
我能够让它工作起来。问题是-L没有采用相对路径。新命令看起来像这样:
arm-none-eabi-gcc -mcpu=cortex-m0plus -mthumb -Wl,--gc-sections --specs=nano.specs -u _printf_float -u _scanf_float -T/<path-to-folder>/workspace/mbed/libraries//mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM/MKL25Z4.ld -o Example.elf main.o /<path-to-folder>/workspace/mbed/libraries//mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM/retarget.o /<path-to-folder>/workspace/mbed/libraries//mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM/board.o /<path-to-folder>/workspace/mbed/libraries//mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM/cmsis_nvic.o /<path-to-folder>/workspace/mbed/libraries//mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM/mbed_overrides.o /<path-to-folder>/workspace/mbed/libraries//mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM/system_MKL25Z4.o /<path-to-folder>/workspace/mbed/libraries//mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM/startup_MKL25Z4.o -L/<path-to-folder>/workspace/mbed/libraries/mbed/TARGET_KL25Z/TOOLCHAIN_GCC_ARM -L/<path-to-folder>/workspace/mbed/libraries/mbed -lmbed -lstdc++ -lsupc++ -lm -lc -lgcc -lnosys
我不太清楚为什么相对路径不起作用。我的一个朋友认为这可能是因为".."在某种意义上是一种象征性的联系。
相关文章:
- CMake项目Boost库错误:Boost/config/compiler/gcc.hpp:165:10:致命错误:cs
- 奇怪的结构&GCC&clang(void*返回类型)
- GCC本机矩阵运算库
- PowerPC ppc64le上的Gcc Woverloaded虚拟错误
- gcc和c++17的过载解析失败
- 数据成员SFINAE的C++17测试:gcc vs clang
- GCC对可能有效的代码抛出init list生存期警告
- 如何解决gcc编译器优化导致的centos双编译器设置中的分段错误
- 这个指针在c++中的用法
- 使用 GCC 卸载的 OpenMP 卸载失败,并出现"Ptx assembly aborted due to errors"
- 为什么与常规GCC不同,即使有"学究性错误",MinGW-GCC也能容忍丢失的返回类型
- 使用gcc从静态链接的文件中查找可选符号
- 普通环路未使用gcc 4.8.5自动矢量化
- 有了gcc,是否可以链接库,但前提是它存在
- 在clang++预处理器中确定gcc工具链版本
- 为什么 gcc 编译这个而 msvc 没有
- Clang vs GCC:枚举用法中的单冒号
- const成员初始化之前的用法是GCC和Clang的这种预期行为
- ./lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a 的用法是什么
- -l在arm none eabi gcc中的用法