【问题标题】:Cross Compilation error can't load library 'libc.so.6'交叉编译错误无法加载库“libc.so.6”
【发布时间】:2014-04-29 09:17:38
【问题描述】:

我正在尝试实现一个将在 i386 控制器上运行的动态库 (liblog.so)。

当我在Host Machine (Ubuntu Machine) 中编译它时,它会成功编译并生成.so 文件。 liblog.so 是目标机器中/usr/lib 下的文件。

merom@arunkumar:~/freedcs/freedcs-code1/Controller/src/Controller$ ldd log_client
    linux-gate.so.1 =>  (0xb7707000)
    libnative.so.3 => not found
    libxenomai.so.0 => not found
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb76cd000)
    librt.so.0 => not found
    liblog.so => /usr/lib/liblog.so (0xb76c9000)
    libcrypto.so.1.0.0 => /lib/i386-linux-gnu/libcrypto.so.1.0.0 (0xb751e000)
    libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0 (0xb74c7000)
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb74a9000)
    libc.so.0 => not found
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb72f5000)
    /lib/ld-uClibc.so.0 => /lib/ld-linux.so.2 (0xb7708000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb72f0000)
    libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb72d7000)
merom@arunkumar:~/freedcs/freedcs-code1/Controller/src/Controller$ 

在主机上输出。

目标机器的输出:

libnative.so.3 => /usr/lib/libnative.so.3 (0xb78d9000)
libxenomai.so.0 => /usr/lib/libxenomai.so.0 (0xb78d4000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb78c1000)
librt.so.0 => /lib/librt.so.0 (0xb78bd000)
liblog.so => /lib/liblog.so (0xb78b9000)
libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0xb7793000)
libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0xb7752000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7748000)
libc.so.0 => /lib/libc.so.0 (0xb770a000)
libdl.so.0 => /lib/libdl.so.0 (0xb7706000)
libc.so.6 => not found
ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb78e2000)

当我将它发送到目标机器(目前在 VMware 中)时,当我运行 .\log_client 时,它会显示 can't load library 'libc.so.6' 是的,我编译了 log_client 并与 liblog.so 链接

编译命令

生成liblog.so

../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -c log.c -o liblog.o

../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -L../../../../build/i386/buildroot-2011.11/output/target/usr/lib -lxenomai -lpthread -lrt -shared -o liblog.so liblog.o -rdynamic -lcrypto -lssl

生成log_client

cp liblog.so ../../../../build/i386/buildroot-2011.11/output/target/usr/lib

../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -c log_client.c

../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -L../../../../build/i386/buildroot-2011.11/output/target/usr/lib -lxenomai -lpthread -lrt -o log_client log_client.o -llog -rdynamic -lcrypto -lssl

我正在对正在运行的其他代码使用相同的过程,尽管该代码不使用此自定义库 (liblog.so),但也有警告,但我没有在此处发布。 请帮助我,我很沮丧!

------------已编辑---------

file 输出

$ file liblog.so 
liblog.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

$ file log_client 
log_client: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

------------更新---------

有人建议我在编译文件时使用--sysroot,但即使这样也没有帮助我。同样的错误出来。 :(

我已将sysroot 路径放入目标机器的 GCC 的 sysroot 路径

生成liblog.so

../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -c log.c -o liblog.o --sysroot=/home/merom/freedcs/build/i386/buildroot-2011.11/output/host/usr/i686-unknown-linux-uclibc/sysroot/

../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -L../../../../build/i386/buildroot-2011.11/output/target/usr/lib -lxenomai -lpthread -lrt -shared -o liblog.so liblog.o -rdynamic -lcrypto -lssl --sysroot=/home/merom/freedcs/build/i386/buildroot-2011.11/output/host/usr/i686-unknown-linux-uclibc/sysroot/

生成log_client

cp liblog.so ../../../../build/i386/buildroot-2011.11/output/target/usr/lib

../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -c log_client.c --sysroot=/home/merom/freedcs/build/i386/buildroot-2011.11/output/host/usr/i686-unknown-linux-uclibc/sysroot/

../../../../build/i386/buildroot-2011.11/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -Wcast-align -g -W -Wall -L../../../../build/i386/buildroot-2011.11/output/target/usr/lib -lxenomai -lpthread -lrt -o log_client log_client.o -llog -rdynamic -lcrypto -lssl --sysroot=/home/merom/freedcs/build/i386/buildroot-2011.11/output/host/usr/i686-unknown-linux-uclibc/sysroot/

更新

运行 objdump 后这是输出。

objdump -x log_client | grep NEEDED
NEEDED               libnative.so.3
NEEDED               libxenomai.so.0
NEEDED               libpthread.so.0
NEEDED               librt.so.0
NEEDED               liblog.so
NEEDED               libcrypto.so.1.0.0
NEEDED               libssl.so.1.0.0
NEEDED               libgcc_s.so.1
NEEDED               libc.so.0



objdump -x liblog.so | grep NEEDED
NEEDED               libnative.so.3
NEEDED               libxenomai.so.0
NEEDED               libpthread.so.0
NEEDED               librt.so.0
NEEDED               libcrypto.so.1.0.0
NEEDED               libssl.so.1.0.0
NEEDED               libgcc_s.so.1
NEEDED               libc.so.0

【问题讨论】:

  • 检查主机和目标机器是否是32位的
  • 我的目标操作系统和 CPU 是 32 位,但主机是 64 位,它的操作系统是 32(Ubuntu)
  • 所以在目标机器上自己制作 .so 文件,因为目标机器不能加载 64 位 .so 文件,因为它是 32 位的。
  • @Merom: IMO=在我看来。命令ldd 递归列出所有依赖项,您可以使用此命令:objdump -x <file> | grep NEEDED 来查看每个库的各个依赖项,直到找到依赖于libc.so.6 和/或libc.so.0 的依赖项。可能会有你的问题。
  • @rodrigo 需要的文件是 libc.so.0 而不是 libc.so.6 那么为什么会显示错误。

标签: linux embedded-linux libc uclibc uclinux


【解决方案1】:

我对可执行文件有同样的问题。我尝试过的每个工具——ldd、objdump、readelf、strings——都表明依赖于 libc.so.0,而不是 .6。事实证明,它的一个依赖库依赖于 .6。所以我去解决了这个问题,现在一切正常。

库的版本不对,因为是使用错误的交叉编译器编译的(我用错了),所以我重新编译并重新上传。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2017-10-23
    • 2013-12-09
    • 1970-01-01
    • 1970-01-01
    • 2014-02-03
    • 2019-01-18
    • 1970-01-01
    • 2018-12-08
    相关资源
    最近更新 更多