首页 文章

交叉编译c for raspberry pi std错误

提问于
浏览
3

我需要交叉编译Raspberry Pi(armV6)的C / C代码 . 我按照http://hertaville.com/2012/09/28/development-environment-raspberry-pi-cross-compiler/上的说明操作,然后在我的主机(Ubuntu 14.04)上运行了 .

所以我的项目 Build 在我的主机之后,对所需的库有些恼火,我很开心 . 但是当我将程序转移到我的Raspberry Pi时,我收到以下错误:

{ProjectName}: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by {ProjectName})
{ProjectName}: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.19' not found (required by {ProjectName})

所以我怀疑交叉编译器正在使用我的主机的libstd .so而不是交叉编译器的一部分,但我不知道如何修复它 .

我正在使用gcc-linaro-arm-linux-gnueabihf-raspbian / arm-linux-gnueabihf-g交叉编译器 .

我尝试工作的程序是由其他人直接在pi上编写的,它构建,编译和运行完美 .

我的makefile看起来像这样:

CC=arm-linux-gnueabihf-g++
IFLAGS=-pthread -I./headers -lwiringPi -lortp -llinphone 
LIBB = -I/home/david/rpi/rootfs/usr/lib/arm-linux-gnueabihf/
CFLAGS=-Wall -std=c++0x
LDFLAGS=-Wall
SOURCES=$(wildcard src/*cpp)
OBJECTS=$(addprefix obj/,$(notdir $(SOURCES:.cpp=.o)))
EXECUTABLE=bin/wackytalky

all: $(SOURCES) LINK_EXEC

debug: CFLAGS += -g
debug: $(SOURCES) LINK_EXEC

LINK_EXEC: $(OBJECTS)
    $(CC) $(LDFLAGS) -o $(EXECUTABLE) $^ $(LIBB) $(IFLAGS)

obj/%.o: src/%.cpp
    $(CC) $(CFLAGS) -o $@ -c $< $(IFLAGS)

clean:
    rm $(EXECUTABLE) obj/*.o

2 回答

  • -1

    你必须将libstdc和其他人复制到你的respary pi . 如果您使用较新的编译器生成需要较新lib的可执行文件,则此lib必须存在于目标上 . 静态链接不是一个有用的选项 . 只需将新库复制到目标上的相应路径即可 .

    所以我怀疑交叉编译器正在使用我的主机的libstd .so而不是交叉编译器的一部分,但我不知道如何解决它 .

    不,我不相信这一点 . 如果您的编译器配置正确,它将使用正确的库 . 如果它试图使用x86库,则不会收到错误版本的消息,因为动态链接器根本无法使用x86库 .

    对于downvoters :-):你可以在目标上有多个版本,所以这样做没问题,详见ldconfig . 您也可以在本地或任何其他路径中使用lib而不会出现问题,为此您可以使用LD_LIBRARY_PATH . 是的,我没有写过你应该删除旧版本 . Linux不是Windows,因此添加的库不会破坏系统 . Linux没有像dll of win of win这样的问题......

    根据您的特殊要求,我使用两个不同的编译器构建一个程序并从ldd获取:

    gcc 4.9:

    linux-vdso.so.1 =>  (0x00007fff4b7fe000)
    librt.so.1 => /lib64/librt.so.1 (0x00000030f2200000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00000030f1200000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030f0e00000)
    libstdc++.so.6 => /opt/linux-gnu_4.9-20140105/lib64/libstdc++.so.6 (0x00007fa4aadc4000)
    libm.so.6 => /lib64/libm.so.6 (0x00000030f1600000)
    libgcc_s.so.1 => /opt/linux-gnu_4.9-20140105/lib64/libgcc_s.so.1 (0x00007fa4aabad000)
    libc.so.6 => /lib64/libc.so.6 (0x00000030f0a00000)
    

    gcc 4.8.2:

    linux-vdso.so.1 =>  (0x00007fff4b7fe000)
    librt.so.1 => /lib64/librt.so.1 (0x00000030f2200000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00000030f1200000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030f0e00000)
    libstdc++.so.6 => /opt/linux-gnu_4.8.2/lib64/libstdc++.so.6 (0x00007fa4aadc4000)
    libm.so.6 => /lib64/libm.so.6 (0x00000030f1600000)
    libgcc_s.so.1 => /opt/linux-gnu_4.8.2/lib64/libgcc_s.so.1 (0x00007fa4aabad000)
    libc.so.6 => /lib64/libc.so.6 (0x00000030f0a00000)
    

    如您所见:一个库的两个版本一个系统,完全没有问题 .

    在OS上的不同lib上的更多信息在这里看:

    How do applications resolve to different versions of shared libraries at run time?

    如果它无法在您的系统上运行,请随时再次询问 .

  • 2

    我和你昨天有同样的问题(确切地说) . 我没有时间跟进Pi端,所以我只修改了我的交叉编译选项(我使用eclipse)并将 -static-libstdc++ 添加到链接器命令 . 这静态链接在Ubuntu端的代码中,因此Pi端的.so问题永远不会出现 .

    显然它会产生更大的可执行文件 .

相关问题