海思编译链编译出现__aeabi_unwind_cpp_pr1重定义怎么回事

1.用arm-hisiv100nptl-linux-gcc编译代码,结果发现报错,__aeabi_unwind_cpp_pr1重定义,在librt.a先定义,使用的海思芯片是hi3520d。

2.本来以为是编译链冲突所致,工具链删了又装,只保留一个,还是不行,装的是toolchain_hisi_linux_nptl_install.tgz

3.后来发现在Hi3520_SDK_1.0.5.0中也有工具链,还有三种,分别是hisiv100,hisiv200,hisiv100nptl,就使用SDK包osdrv中的toolchain的hisiv100nptl,运行其目录下的cross.install文件,安装arm-hisiv100nptl-linux-gcc编译器。

4.装完发现程序就编译正确,运行OK了。

5.说明海思的编译链冲突也许是不存在的,说是很多编译链安装时候会用软连接导致删除不干净,因此很多人采取一个编译链一个虚拟机的方式,防止编译工具链冲突。

6.此处说明toolchain_hisi_linux_nptl_install.tgz也许本身就有问题,建议使用hisi官方提供的SDK中的cross.install来安装编译工具链。

时间: 2024-10-26 21:17:41

海思编译链编译出现__aeabi_unwind_cpp_pr1重定义怎么回事的相关文章

[问题记录]libpomelo编译报错:ssize_t重定义

1. 时间:2015/01/16 描述:添加libpomelo到cocos2dx项目,报错如下图所示: 解决: 修改代码,源代码: #if !defined(_SSIZE_T_) && !defined(_SSIZE_T_DEFINED) typedef intptr_t ssize_t; # define _SSIZE_T_ # define _SSIZE_T_DEFINED #endif 修改后: #if !defined(__SSIZE_T) && !defined(

BOOST_ASIO_ERROR_CATEGORY_NOEXCEPT 宏重定义

场景说明 LIVE555工程使用boost库编译出错问题说明 错误提示           LIVE555调用boost1.58库的时候,出现如下的编译错误: "BOOST_ASIO_ERROR_CATEGORY_NOEXCEPT": 宏重定义 参见"BOOST_ASIO_ERROR_CATEGORY_NOEXCEPT"的前一个定义 error C3861: "GetAcceptExSockaddrs": 找不到标识符error C2065: &

FAAC1.28 在海思HI3520D/HI3515A平台linux中的编译 优化

FAAC1.28的下载地址:http://www.audiocoding.com/downloads.html 如何编译: 1../configure --host=arm-hisiv100nptl-linux --prefix=/home/ssy/lib 2.make 3.make install 优化 在不修改源码的情况下,faac的内存占用非常高,每路音频在13M左右.如果多路音频的话,内存将很快耗尽. 搜索MAX_CHANNELS的定义,默认是6 和64,全部改成1(一般都是单声道).

海思android4.4 SDK编译Latin输入法

原来的HiSTBAndroidV500R001C01SPC020\device\hisilicon\bigfish\packages\apps\HiLatinIME\Android.mk内容例如以下: #include $(call all-subdir-makefiles) 使用mm命令没法编译到子文件夹去,后来看到https://android.googlesource.com/platform/packages/inputmethods/LatinIME/+/e245b27a4e520c9

嵌入式交叉工具链编译

读者可能会有疑问,为什么要用交叉编译器?交叉编译通俗地讲就是在一种平台上编译出能运行在体系结构不同的另一种平台上的程序,比如在PC平台 (X86 CPU)上编译出能运行在以ARM为内核的CPU平台上的程序,编译得到的程序在X86 CPU平台上是不能运行的,必须放到ARM CPU平台上才能运行,虽然两个平台用的都是Linux系统.这种方法在异平台移植和嵌入式开发时非常有用.相对与交叉编译,平常做的编译叫本地编译,也 就是在当前平台编译,编译得到的程序也是在本地执行.用来编译这种跨平台程序的编译器就

关于T-SQL重编译那点事,WITH RECOMPILE和OPTION(RECOMPILE)区别仅仅是存储过程级重编译和SQL语句级重编译吗

本文出处:http://www.cnblogs.com/wy123/p/6262800.html   在考虑重编译T-SQL(或者存储过程)的时候,有两种方式可以实现强制重编译(前提是忽略导致重编译的其他因素的情况下,比如重建索引,更新统计信息等等), 一是基于WITH RECOMPILE的存储过程级别重编译,另外一种是基于OPTION(RECOMPILE)的语句级重编译. 之前了解的比较浅,仅仅认为是前者就是编译整个存储过程中的所有的语句,后者是重编译存储过程中的某一个语句,也没有追究到底是不

浅谈编译过程和符号表重定位问题

对于代码的编译问题千头万绪从何说起呢,首先来说一下计算机是如何处理应用程序的,实质上应用程序是通过操作系统来应用机器指令操控硬件设施完成各种任务的,就从编译的环节开始谈起吧,众所周知,程序开发人员所写的代码实际上计算机是没有办法去认识的,那么就必须通过编译将其转换为计算机可以认识的机器指令,在有操作系统根据具体指令从硬件上分配内存处理程序段.以下从预编译,编译,汇编,链接,来简单的说一下程序的编译过程. 2.1编译预处理 在这个阶段主要是宏定义的展开,以及头文件的递归处理,即展开所有的以#开头的

c++写一个类后编译发现class重定义

c++写一个类后编译发现class重定义 这种问题经常都是头文件互相包含导致的 在h文件开头加上 #pragma once 这样这个头文件只编译一次 避免了这个问题

WITH RECOMPILE和OPTION(RECOMPILE)区别仅仅是存储过程级重编译和SQL语句级重编译

在考虑重编译T-SQL(或者存储过程)的时候,有两种方式可以实现强制重编译(前提是忽略导致重编译的其他因素的情况下,比如重建索引,更新统计信息等等), 一是基于WITH RECOMPILE的存储过程级别重编译,另外一种是基于OPTION(RECOMPILE)的语句级重编译. 之前了解的比较浅,仅仅认为是前者就是编译整个存储过程中的所有的语句,后者是重编译存储过程中的某一个语句,也没有追究到底是不是仅仅只有这么一点区别. 事实上在某些特定情况下,两者的区别并非仅仅是存储过程级重编译和语句级重编译的