error:requires unsupported dynamic reloc R_ARM_REL32； recompile with -fPIC

最新推荐文章于 2024-06-23 12:02:42 发布
原创 最新推荐文章于 2024-06-23 12:02:42 发布 · 1.8k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#cmake

本文解决在ARMv7项目编译过程中遇到的错误：requiresunsupporteddynamicrelocR_ARM_REL32;recompilewith-fPIC。通过在CMakeLists.txt中为CMAKE_C_FLAGS和CMAKE_CXX_FLAGS添加-fPIC选项，成功解决了该问题。

问题：
       在编译armv7项目过程中，报错error:requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC；
解决方案：
       更改cmakelist.txt脚本，将set(CMAKE_C_FLAGS)与set(CMAKE_CXX_FLAGS)分别添加编译选项 -fPIC

【QT6】56:1: error: Parse error at “__attribute__“ 问题原因和解决办法
q2nAmor
06-06 1835
QT6 采坑
关于eigen库报错:error: static assertion failed: YOU_PERFORMED_AN_INVALID_TRANSFORMATION_CONVERSION
weixin_46658421的博客
03-25 2728
错误图如上： 原因应该是eigen库在更新时API的迁移问题(API migration)， 我找到了相应的文件，如下图 通过查找资料得知这是因为Affine3d和Isometry3d数据类型不匹配的问题，有可能是在版本更新的时候API发生了迁移(migration)名字改变或者功能改变。解决方式如下图 改过之后保存，再次编译，OK成功! 参考链接：https://github.com/ros/geometry2/pull/335 https://github.com/ros/ge..
error: qrc_qml.obj: requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC解决办法
weixin_33738578的博客
09-14 949
使用qtcreator加androidndk编译项目时报错： error: qrc_qml.obj: requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC error: undefined reference to '__dso_handle' 解决方案，建一个头文件，代码如下，包含到项目里: #defin...
requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC
aa112901a的博客
08-16 2790
地址无关代码，在64位下编译动态库的时候，经常会遇到下面的错误 /usr/bin/ld: /tmp/ccQ1dkqh.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC 提示说需要-fPIC编译，然后在链接动态库的...
有关 -fPIC 选项的编译问题
一个软件工程师的技术笔记
04-01 1023
嵌入式 Linux 上基于 makefile 的编译，执行编译出现如下错误： error: test/fake_blemgr_test.o: requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC 这个问题涉及到生成位置无关代码的机制，在我这里的情况是，对于 -fPIC 选项的使用，需要放置在 -fpie 选项的后面位置，才能生效，就不会再出现上述编译错误。 CFLAGS += -O2 -pie -march=
ndk-r20b 编译 armv7报错 error:requires unsupported dynamic reloc R_ARM_REL32； recompile with -fPIC
icesnowjank的专栏
12-14 882
解决方案： ./configure --with-pic ... 编译过程中添加--with-pic选项就可以了。
arm linux gcc fpic,插件 – 需要不支持的动态重定位R_ARM_REL32;用-fPIC重新编译
weixin_39550258的博客
05-13 568
我正在通过yocto 1.6构建一个gst-plugin.我是linaro 4.9交叉工具链的32位和64位.当我使用64位工具链构建插件时,它成功了(我得到了插件.so文件)而如果我使用32位工具链构建相同的源,我得到了以下错误/home/build-directory/tmp/sysroots/x86_64-linux/usr/libexec/cortexa8hf-vfp-neon-rdk-l...
【已解决】RuntimeError: cuDNN error: CUDNN_STATUS_INTERNAL_ERROR Caught RuntimeError in replica 2 on devi
BetrayFree的博客
03-11 1万+
这可能是由于各种原因引起的，如CUDA/cuDNN不兼容的版本、内存分配问题或硬件问题。如果上述步骤都无法解决问题，您可能需要从CUDA/cuDNN论坛或支持渠道寻求进一步的帮助，因为问题可能特定于您的环境或配置。显然这样是解决不了任何问题的，因为我在跑其他程序的时候就没有问题，所以上面这些问题肯定是没有出现的。再接着再看上一个错误，给出的答复是这样的，但同样也不知道怎么解决。：检查您的代码，特别是与错误相关的部分。：在代码中添加适当的日志记录，以便更好地理解程序的执行流程和问题发生的位置。
解决 Inconsistency detected by ld.so: ../sysdeps/x86_64/dl-machine.h: 541: elf_machine_rela_relative
m0_49519917的博客
06-23 2161
完整报错 Inconsistency detected by ld.so: ../sysdeps/x86_64/dl-machine.h: 541: elf_machine_rela_relative: Assertion `ELFW(R_TYPE) (reloc->r_info) == R_X86_64_RELATIVE' failed!此处NAMEHERE替换上图中的libcublas，后续重复步骤2和3，几次之后就好了。进到python排查了一下，发现是torch包崩坏了。1. 重装torch。
CCLD libeXosip2.la /home/st/arm-rockchip830-linux-uclibcgnueabihf/bin/../lib/gcc/arm-rockchip830-linux-uclibcgnueabihf/8.3.0/../../../../arm-rockchip830-linux-uclibcgnueabihf/bin/ld.bfd: /opt/RV1106/dependlibs/libosip2.a(ict.o): relocation R_ARM_MOVW_ABS_NC against `osip_free_func' can not be used when making a shared object; recompile with -fPIC /home/st/arm-rockchip830-linux-uclibcgnueabihf/bin/../lib/gcc/arm-rockchip830-linux-uclibcgnueabihf/8.3.0/../../../../arm-rockchip830-linux-uclibcgnueabihf/bin/ld.bfd: /opt/RV1106/dependlibs/libosip2.a(nict.o): relocation R_ARM_MOVW_ABS_NC against `osip_free_func' can not be used when making a shared object; recompile with -fPIC /home/st/arm-rockchip830-linux-uclibcgnueabihf/bin/../lib/gcc/arm-rockchip830-linux-uclibcgnueabihf/8.3.0/../../../../arm-rockchip830-linux-uclibcgnueabihf/bin/ld.bfd: /opt/RV1106/dependlibs/libosip2.a(osip.o): relocation R_ARM_MOVW_ABS_NC against `osip_malloc_func' can not be used when making a shared object; recompile with -fPIC
最新发布
12-13
注意：引用[3]中提到的错误`requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC`也说明了重新编译使用`-fPIC`的重要性。 因此，我们优先使用方法一，如果不行再尝试方法二、三、四。 另外...
Android Studio NDK编译报错requires unsupported dynamic reloc R_ARM_REL32； recompile with -fPIC
lancewoo的博客
08-02 1883
报错信息： [78/82] Building CXX object lidarapp/LASlib_output_dir/CMakeFiles/LASlib.dir/E_/work/projects/LivoxLiDAR/lastools/src/main/cpp/LASzip/src/lasquadtree.cpp.o [79/82] Building CXX object lidarapp/LASlib_output_dir/CMakeFiles/LASlib.dir/E_/work/project
unsupported dynamic reloc R_ARM_REL32 AND hidden symbol '__dso_handle' is not defined
weixin_30905133的博客
11-26 479
项目里编译codec src\makefiles\android\codec\Makefileline 25 原本用 4.6 不会报错-L/data/android/android-ndk/sources/cxx-stl/gnu-libstdc++/4.6/libs/armeabi-v7a \改成-L/data/android/android-ndk/sources/cxx-stl/gnu-lib...
Ubuntu16 编译源码出错 unsupported reloc 43
简单
06-21 693
http://www.bubuko.com/infodetail-1973508.html http://www.7zhang.com/index/cms/read/id/366914.html cp /usr/bin/ld.gold prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.11-4.6/x86_64-linux/bin/l
编译程序报错error: OpenSSL has unsupported dynamic loading
aischang
09-04 1682
在编译应用程序使用openssl动态库，发现报错： error: OpenSSL has unsupported dynamic loading 解决方案： 主要是缺少libssl.so和libcrypto.so 两个动态库， ssh -V查看当前openssl的版本 使用ln 软连接的方式进行链接一下 命令 ln -s 源文件，目的文件 ...
tre编译中的-shared和-fPIC
入凡尘笔录
01-13 7874
接着昨天的工作，绝大部分问题已经解决，现在拖到最后解决，摆在眼前的问题是： 1、makefile中LDFLAGS有参数-shared，导致报错 /usr/bin/ld: md5c.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; reco
arm平台编译动态库报 relocation R_ARM_MOVW_ABS_NC 错误解决
热门推荐
阿然的专栏
11-21 2万+
编译一个能在 arm 平台上用的动态库，结果报错如下： relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC ./obj/xxx.o: could not read symbols: Bad value collect2: error: ld returned 1 exit status 其实错误信息已经给出解决办法了，加
eclipse编译linux arm动态库
whysnlc的专栏
01-10 893
0.交叉编译链的安装和配置： 详见：https://blog.csdn.net/markton1990/article/details/86073551 以使用arm-linux-gnueabihf-gcc为例。 1.动态库/静态库/可执行程序的切换 1.1 C/C++ Build->Build Artifact，在artifact type处，可以设置是生成可执行文件，静态库，动态...
编译报错R_ARM_THM_MOVW_ABS_NC against `a local symbol
csdn66_2016的博客
01-03 7665
我们在编译动态库的时候，会遇到如下错误： /opt/gcc-linaro-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/ld: adb.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symb
main.c(5): error C267: 'LED3_show_string': requires ANSI-style prototype
11-19
<think> 我们正在解决的是main.c文件第5行出现的error C267错误，错误信息为"'LED3_show_string': requires ANSI-style prototype"。 这个错误通常发生在使用Keil C51编译器（或类似的传统C编译器）时，表示函数在使用前没有进行正确的函数原型声明。 根据错误信息，我们可以推断： 1. 函数`LED3_show_string`在第5行被调用，但编译器在此之前没有看到该函数的原型声明（即ANSI风格的函数声明）。 2. 在C语言中，函数在使用前必须声明，尤其是当函数的定义出现在调用之后时，或者函数定义在另一个文件中时，必须提供函数原型。 解决方案步骤： 步骤1：检查函数声明 在main.c文件的开头（通常在包含头文件之后），添加函数`LED3_show_string`的原型声明。例如： void LED3_show_string(char *str); // 根据实际参数和返回类型修改 注意：函数原型必须与函数定义完全一致（包括返回类型、参数类型和数量）。 步骤2：检查头文件 如果函数`LED3_show_string`是在另一个源文件中定义的，那么通常应该在头文件中声明它，然后在main.c中包含该头文件。例如： 在led_display.h中声明： extern void LED3_show_string(char *str); 在main.c中包含头文件： #include "led_display.h" 步骤3：检查函数定义 确认函数定义是否符合ANSI C标准（即带有完整的参数类型声明）。例如： 错误定义（K&R风格，已过时）： void LED3_show_string(str) char *str; { // 函数体 } 正确定义（ANSI风格）： void LED3_show_string(char *str) { // 函数体 } 步骤4：检查函数调用 确保调用函数时传递的参数类型和数量与声明一致。例如，如果函数声明为： void LED3_show_string(char *str); 那么调用时应该传递一个char指针（或字符数组），如： LED3_show_string("Hello"); 步骤5：检查函数名拼写 确保函数声明、定义和调用中的函数名拼写完全一致（包括大小写）。在C语言中，函数名是区分大小写的。 步骤6：如果函数定义在其他文件，检查文件是否被正确包含和编译 确保包含函数定义的源文件已经被添加到工程中，并且被正确编译。 错误原因分析： 在传统的C编译器中，如果函数在使用前没有被声明，编译器会假设函数返回int类型，并且参数类型由调用时传入的参数类型决定（即采用默认的K&R风格）。但是，如果函数实际返回非int类型或者参数不匹配，就会导致错误。而ANSI C要求使用函数原型来明确函数签名，以避免此类问题。 因此，错误C267就是编译器在要求我们提供一个ANSI风格的函数原型声明。 示例代码： 假设在main.c中，第5行调用了`LED3_show_string`，那么我们应该在main.c的顶部添加声明： ```c // main.c #include <reg52.h> // 或其他头文件 // 添加函数声明 void LED3_show_string(char *str); void main() { // ... // 第5行： LED3_show_string("Welcome"); // 示例调用 // ... } ``` 如果函数定义在另一个文件（如led_display.c）中，那么最好在头文件（led_display.h）中声明，然后在main.c中包含该头文件。 如果函数定义在main.c的后面，那么只需要在调用之前声明即可。 注意事项： 1. 使用头文件来共享函数声明是更好的做法，可以避免重复声明。 2. 确保函数声明和定义的返回类型、参数列表完全一致。 如果按照以上步骤检查并修正，应该可以解决error C267错误。 流程图： ```mermaid graph TD A[错误C267：requires ANSI-style prototype] --> B{检查函数声明} B -->|未声明| C[在调用前添加函数原型声明] B -->|已声明| D{检查声明与定义是否一致} D -->|不一致| E[修改声明或定义使其一致] D -->|一致| F{检查函数调用参数} F -->|参数不匹配| G[修改调用或函数声明] F -->|参数匹配| H{检查函数定义是否为ANSI风格} H -->|是K&R风格| I[修改定义成ANSI风格] H -->|是ANSI风格| J[检查函数名拼写和大小写] J -->|不一致| K[修正函数名] J -->|一致| L[检查工程配置，确保所有文件被正确编译] ``` 相关问题： 1. C语言中函数原型的作用是什么？ 2. K&R风格的函数定义与ANSI风格有什么区别？ 3. 如何在Keil C51中配置编译器以显示更多警告信息？ </think> ### 解决 `main.c` 第 5 行 error C267 错误（'LED3_show_string': requires ANSI-style prototype）的方法 该错误表示编译器在调用 `LED3_show_string` 函数时未找到符合 ANSI C 标准的函数原型声明。以下是系统化的解决方案： #### 1. **添加函数原型声明**（核心解决方案） 在调用函数前添加 ANSI 风格原型声明： ```c /* main.c 开头添加声明 */ void LED3_show_string(char *str); // ANSI风格原型 int main() { // 第5行调用位置 LED3_show_string("Hello"); // ✅ 现在编译器能识别 } ``` > **原理**：C编译器需要提前知道函数的参数类型和返回值[^1] #### 2. **检查函数定义格式** 确保函数定义使用 ANSI 标准格式（非过时的 K&R 风格）： ```c // ✅ 正确的ANSI风格定义 void LED3_show_string(char *str) { // 函数实现 } // ❌ 错误的K&R风格（触发C267错误） void LED3_show_string(str) char *str; { // 函数实现 } ``` #### 3. **检查头文件包含** 如果函数在其他文件中定义： ```c /* main.c */ #include "LED_driver.h" // 确保包含声明原型的头文件 int main() { LED3_show_string("Test"); // 调用 } /* LED_driver.h */ extern void LED3_show_string(char *str); // 跨文件声明 ``` #### 4. **验证参数一致性** 错误示例及修正： ```c // 声明 void LED3_show_string(uint8_t *str); // 调用 LED3_show_string("Text"); // ❌ 错误：char* vs uint8_t* // ✅ 修正方案：统一类型 void LED3_show_string(char *str); // 修改声明 ``` #### 错误诊断流程图 ```mermaid graph TD A[Error C267] --> B{是否已声明函数？} B -->|否| C[添加ANSI原型声明] B -->|是| D{声明是否为ANSI风格？} D -->|否| E[修改为ANSI格式声明] D -->|是| F{参数类型是否匹配？} F -->|否| G[统一声明与调用的参数类型] F -->|是| H{是否跨文件调用？} H -->|是| I[检查头文件包含和extern声明] H -->|否| J[检查函数名拼写和大小写] ``` #### 5. **工程配置检查** - 确保所有源文件添加到工程 - 在Keil中检查编译选项： ``` Project → Options for Target → C51 → 勾选"Require Prototypes" ``` - 头文件路径设置： ``` Options → C/C++ → Include Paths 添加头文件目录 ``` > **根本原因**：该错误常见于传统8051项目，因编译器默认使用ANSI C89标准，要求函数使用前必须声明完整原型。现代编译器如GCC通常仅给出警告，但Keil C51会视为致命错误[^2]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值