我正在尝试在Ubuntu中为我的树莓派板交叉编译库bcm2835-1.42。 下载库并使用以下命令进行交叉编译： wget http：www.airspayce.com/mikem/bcm2835/bcm2835-1.42.tar.gz tar -xvf bcm2835-1.42.tar.gz cd bcm2835-1.42 ./configure -host = arm -prefix = $（DEVELROOT）CC = arm-linux-gnueabihf-gcc-4.8 ar = arm-linux-gnueabihf-ar-4.8 使 当我使源代码我坚持以下错误消息。 /tmp/ccxDzazg.s：汇编信息： /tmp/ccxDzazg.s:299错误：无效屏障types – dmb ldr r0,[r0] dmb' /tmp/ccxDzazg.s:365: Error: invalid barrier type — dmb str r1，[r0] dmb' /tmp/ccxDzazg.s:453错误：无效屏障types – dmb ldr r0,[r0] dmb' /tmp/ccxDzazg.s:480: Error: invalid barrier type — dmb str r1，[r6] […]
我正在研究一个程序的内存布局。 我正在使用gdb来检查一个小端（intel x86_64）Linux（32位）机器中的堆栈。 但是，我不能理解这个处理器和gdb的大端和小端的概念。 我的示例程序是： 1 #include<stdio.h> 2 3 int main(int argc, char **argv) { 4 int a = 5; 5 char b[] = "ABCDEFGH"; 6 7 return 0; 8 } [Code – 1] 以下指令序列在gdb中执行。 (gdb) b 7 Breakpoint 1 at 0x8048434: file args.c, line 7. (gdb) r Breakpoint 1, main (argc=1, argv=0xbffff4f4) at args.c:7 […]
我正在写一个简单的应用程序，链接到系统上的libxml2 。 它适用于几乎所有的用户，但是一个用户在从Web上读取特定的XML文件时报告了这个错误： Unsupported encoding ISO8859-1 这个错误通常表明libxml2是build立的–without-iconv 。 有没有什么办法可以明确testing系统上的libxml2dynamic库是否支持iconv？
我在MacOSX（Segmentation fault：11，在gdb“程序接收到的信号SIGSEGV，Segmentation fault”）中收到一个段错误，出现在析构函数中，在这个析构函数中，一个迭代器和内存被删除。 我已经尝试过clang ++，g ++（LLVM的一部分）和homebrew g ++。 迭代器第一次增加时会出现segfault，gdb消息（用clang ++编译） "0x000000010001196d in std::__1::__tree_node_base<void*>* std::__1::__tree_next<std::__1::__tree_node_base<void*>*>(std::__1::__tree_node_base<void*>*) ()" 当在gdb中启动程序的时候，我也会收到警告，提示“warning：Could not open OSO archive file”。 在一个集群linux节点上，用gcc 4.8.1，我没有得到一个段错误。 任何想法可能是错误的，以及如何我可以避免在我的Mac（最好与铛）的段错误？ 我真的不太了解编译器等。 编辑： 我想我发现了这个问题，但是我想了解为什么这个工作在一个平台上而不是另一个平台上。 这是一个最小的例子： class级Word： #ifndef WORD_H #define WORD_H #include <string> #include <map> class Word { public: /*** Constructor ***/ Word(std::string w) : m_word(w) { // Add word to index map, […]
我的进程不在debugging器上运行，而是在发生崩溃时生成核心文件。 更新：崩溃发生由于exception。 从一个throw（），它甚至不在main（）范围内处理。 当我将它附加在debugging器中运行它时，它会正确生成回溯，但是在核心文件中却不会。 问题可能是操作系统在传递控制权终止之前展开堆栈，因此当终止生成SIGABT时，它没有关于先前堆栈的信息。 我得到这个崩溃的压力记忆testing，所以我不可能在gdb下执行这个任务。 该怎么办 ？ 任何步行
所以我在一个旧的CentOS 6.6发行版，并从源代码编译GCC 5.2。 当我安装它时，它创build了libexec下的5.2.0子文件夹，但是二进制文件cc1和cc1 plus是巨大的！ 这是我如何build立它 Using built-in specs. COLLECT_GCC=./gcc COLLECT_LTO_WRAPPER=/usr2/libexec/gcc/i686-redhat-linux-gnu/5.2.0/lto-wrapper Target: i686-redhat-linux-gnu Configured with: ../configure –prefix=/usr2 –disable-multilib –enable-languages=c,c++ –enable-gnu-unique-object –disable-dssi –enable-libstdcxx-threads –enable-libstdcxx-time –enable-shared –enable-__cxa_atexit –disable-libunwind-exceptions –disable-libada –host=i686-redhat-linux-gnu –build=i686-redhat-linux-gnu –target=i686-redhat-linux-gnu –with-default-libstdcxx-abi=gcc4-compatible –with-arch=i686 –enable-linker-build-id –with-system-zlib –with-default-libstdcxx-abi=gcc4-compatible Thread model: posix gcc version 5.2.0 (GCC) 这是发行版4.4.7的ls -rwxr-xr-x 1 root root 8566416 Jul 23 00:19 cc1 -rwxr-xr-x 1 root […]
我将一个线程局部variables添加到几个总是直接链接到可执行文件的对象文件。 这些对象将永远不会包含在共享库中（可以肯定的是，在可预见的将来，这是可以保证的）。 这意味着这些对象不需要-fPIC标志，对吗？ 我们的代码库默认具有所有对象的-fPIC标志。 其中许多都包含在共享库中，因此使用-fPIC是有道理的。 但是，这个标志提出了debugging新线程局部variables的问题，因为GDB在使用-fPIC跨越线程局部variables时崩溃 。 如果我从这些带有新线程局部variables的对象文件中删除-fPIC，我可以正确debugging。 我找不到任何将非PIC对象与可执行文件中的PIC对象混合的权威性声明。 到目前为止，我的testing表明它没问题，但不会感到犹豫，在线讨论通常是“不要混合PIC和非PIC”，这是由于共享库的情况。 在这种情况下，将非PIC对象链接到由PIC对象和库构build的可执行文件中是否安全？ 也许有一个海湾合作委员会文件的权威声明，这是安全的，但我找不到它。 编辑：二进制补丁海湾合作委员会，以避免这个错误是不是在短期内的解决scheme。 在Linux上切换编译器不是一个可行的解决scheme。
场景： 可执行文件在运行时通过dlopen加载共享对象。 共享对象引用了一些实际编译到主可执行文件中的符号（一个函数）。 如果在链接可执行文件时向gcc添加-rdynamic，这工作正常。 -rdynamic导出可执行文件的所有非静态符号。 我的共享对象只需要一些select。 问题：有没有办法实现-rdynamic的效果，但是限制了我所知道的共享对象所需的less数select符号？ 编辑： 至less有两个人误解了这个问题，所以我试图澄清一下： 这个问题是关于从主可执行文件中导出一个符号的。 这个问题不是从dynamic库中导出符号。 这是一个最小的例子： func.h，通用的头文件 #include <stdio.h> void func(void); main.c，主要可执行代码： #include <dlfcn.h> #include "func.h" // this function is later called by plugin void func(void) { printf("func\n"); } int main() { void * plugin_lib = dlopen("./plugin.so", RTLD_NOW); printf("dlopen -> %p, error: %s\n", plugin_lib, dlerror()); // find and call […]
我在centos 6.5上安装了centos 6.5 gcc version 4.4.7 g++ version 4.4.7 当我运行R并尝试安装包 install.packages("fArma") 它给出了以下错误 gcc：/builddir/build/BUILD/R-3.3.0/zlib-1.2.8/target/usr/lib64/libz.a：没有这样的文件或目录 gcc：/builddir/build/BUILD/R-3.3.0/bzip2-1.0.6/target/usr/lib64/libbz2.a：没有这样的文件或目录gcc：/builddir/build/BUILD/R-3.3.0 /xz-5.2.2/target/usr/lib64/liblzma.a：没有这样的文件或目录 gcc：/builddir/build/BUILD/R-3.3.0/pcre-8.38/target/usr/lib64/libpcre.a：没有这样的文件或目录 gcc：/builddir/build/BUILD/R-3.3.0/curl-7.48.0/target/usr/lib64/libcurl.a：没有这样的文件或目录 gcc：/builddir/build/BUILD/R-3.3.0/zlib-1.2.8/target/usr/lib64/libz.a：没有这样的文件或目录 gcc：/builddir/build/BUILD/R-3.3.0/bzip2-1.0.6/target/usr/lib64/libbz2.a：没有这样的文件或目录 gcc：/builddir/build/BUILD/R-3.3.0/xz-5.2.2/target/usr/lib64/liblzma.a：没有这样的文件或目录 gcc：/builddir/build/BUILD/R-3.3.0/pcre-8.38/target/usr/lib64/libpcre.a：没有这样的文件或目录 gcc：/builddir/build/BUILD/R-3.3.0/curl-7.48.0/target/usr/lib64/libcurl.a：没有这样的文件或目录 make：*** [gss.so]错误1 错误：编译包âgssâ。失败 *移除/ usr / lib64 / R / library /gssâ 错误：依赖关系âgssâ不适用于包âBasicsâ *删除“/ usr / lib64 / R / library / fBasics” 错误：依赖关系âBasicsâ不适用于包âArmaâ *移除/ usr / lib64 / R / library /fArmaâ […]
我想用ARM工具链编译一个简单的testing程序。 我的Makefile如下： CC=/project_path/arm-linux-uclibcgnueabi/bin/gcc # the compiler: gcc for C program, define as g++ for C++ # compiler flags: # -g adds debugging information to the executable file # -Wall turns on most, but not all, compiler warnings CFLAGS = -g -Wall # the build target executable: TARGET = test all: $(TARGET) $(TARGET): $(TARGET).c $(CC) $(CFLAGS) […]