Question

我正在尝试为ARM处理器交叉编译一些库，特别是：

DirectFB，依赖于libpng，依赖于zlib。

Libpng与zlib链接，但由于构建系统上的路径与目标系统上的路径不匹配，因此在编译DirectFB期间，ld无法找到libpng链接的zlib。

我已将问题简化为以下示例： testb依赖于libb，这取决于liba。

构建liba：

gcc -Wall -fPIC -c a.c
gcc -shared -Wl,-soname,liba.so.1 -o liba.so.1.0 a.o

ln -fs liba.so.1.0 liba.so.1
ln -fs liba.so.1 liba.so

建立了testa：

gcc -Wall -I. -L. testa.c -la -o testa
LD_LIBRARY_PATH=. ./testa
a: 0

构建libb：

gcc -Wall -fPIC -I. -L. -c b.c -la
gcc -shared -Wl,-soname,libb.so.1 -o libb.so.1.0 b.o

ln -fs libb.so.1.0 libb.so.1
ln -fs libb.so.1 libb.so

到目前为止，这么好。但是，构建testb失败了：

gcc -Wall -I. -L. testb.c -lb -o testb

结果：

./libb.so: undefined reference to `a'
collect2: ld returned 1 exit status
make: *** [testb] Error 1

所以ld在liba中找不到a的定义，即使libb与liba链接，并且两者都在当前目录中，并且使用“-L”传递。

使用-v运行gcc会导致：

gcc -v -Wall -I. -L. testb.c -lb -o testb
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5.1' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) 
COLLECT_GCC_OPTIONS='-v' '-Wall' '-I.' '-L.' '-o' 'testb' '-mtune=generic' '-march=i486'
 /usr/lib/gcc/i486-linux-gnu/4.4.3/cc1 -quiet -v -I. testb.c -D_FORTIFY_SOURCE=2 -quiet -dumpbase testb.c -mtune=generic -march=i486 -auxbase testb -Wall -version -fstack-protector -o /tmp/ccqAkMFb.s
GNU C (Ubuntu 4.4.3-4ubuntu5.1) version 4.4.3 (i486-linux-gnu)
    compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128244
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 .
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.4.3/include
 /usr/lib/gcc/i486-linux-gnu/4.4.3/include-fixed
 /usr/include
End of search list.
GNU C (Ubuntu 4.4.3-4ubuntu5.1) version 4.4.3 (i486-linux-gnu)
    compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128244
Compiler executable checksum: 2349e080d2b2f3f970047e63bbe98cb2
COLLECT_GCC_OPTIONS='-v' '-Wall' '-I.' '-L.' '-o' 'testb' '-mtune=generic' '-march=i486'
 as -V -Qy -o /tmp/ccc6ux7S.o /tmp/ccqAkMFb.s
GNU assembler version 2.20.1 (i486-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.20.1-system.20100303
COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../:/lib/:/usr/lib/:/usr/lib/i486-linux-gnu/
COLLECT_GCC_OPTIONS='-v' '-Wall' '-I.' '-L.' '-o' 'testb' '-mtune=generic' '-march=i486'
 /usr/lib/gcc/i486-linux-gnu/4.4.3/collect2 --build-id --eh-frame-hdr -m elf_i386 --hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o testb -z relro /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/crt1.o /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.4.3/crtbegin.o -L. -L/usr/lib/gcc/i486-linux-gnu/4.4.3 -L/usr/lib/gcc/i486-linux-gnu/4.4.3 -L/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.4.3/../../.. -L/usr/lib/i486-linux-gnu /tmp/ccc6ux7S.o -lb -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i486-linux-gnu/4.4.3/crtend.o /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/crtn.o
./libb.so: undefined reference to `a'
collect2: ld returned 1 exit status
make: *** [testb] Error 1

将LD_LIBRARY_PATH和/或LIBRARY_PATH设置为当前目录无法解决问题。

使用-la进行编译，但它不是必需的，因为libb与liba链接。例如，在本机构建环境中链接libpng时（正确的路径，ld.so.conf中的库路径）不需要-lz。

另外，设置额外的lib来链接是一件痛苦的事，因为我必须为依赖于依赖另一个lib的lib的每个编译修补Makefile。

总之，如何在编译期间告诉ld在哪里查找依赖的共享库？

我的问题与这两个类似： Cross-linking for ARM/QNX fails with indirect/transitive dependencies How to resolve shared library linking during compilation( GCC )?

两者都没有提出一个不需要添加-la的解决方案，在我看来这不是必需的。

使用的文件：

交流转换器：

int a() {
    return 0;
}

liba.h：

#ifndef LIBA_H
#define LIBA_H

    int a();

#endif

testa.c：

#include <stdio.h>
#include <liba.h>

int main() {
    printf("a: %d\r\n", a());
    return 0;
}

b.c：

#include <liba.h>

int b() {
    return a();
}

libb.h：

#ifndef LIBB_H
#define LIBB_H

    int b();

#endif

testb.c：

#include <stdio.h>
#include <libb.h>

int main() {
    printf("b: %d\r\n", b());
    return 0;
}

生成文件：

# Makefile for shared library test

all:

liba:
    gcc -Wall -fPIC -c a.c
    gcc -shared -Wl,-soname,liba.so.1 -o liba.so.1.0 a.o

    ln -fs liba.so.1.0 liba.so.1
    ln -fs liba.so.1 liba.so

testa: liba
    gcc -Wall -I. -L. testa.c -la -o testa

runtesta: testa
    LD_LIBRARY_PATH=. ./testa

libb: liba
    gcc -Wall -fPIC -I. -L. -c b.c -la
    gcc -shared -Wl,-soname,libb.so.1 -o libb.so.1.0 b.o

    ln -fs libb.so.1.0 libb.so.1
    ln -fs libb.so.1 libb.so

testb: libb
    gcc -v -Wall -I. -L. testb.c -lb -o testb

runtestb: testb
    LD_LIBRARY_PATH=. ./testb

clean:
    # clean up
    rm -rf *.o
    rm -rf liba.s*
    rm -rf libb.s*
    rm -rf testa testb

Answer 1

你必须将-la添加到lb的链接阶段（下面的第二行是必不可少的）：

$ gcc -Wall -fPIC -I. -L. -c b.c -la
$ gcc -L. -shared -o libb.so b.o -la
$ LD_LIBRARY_PATH=. gcc -Wall -I. -L. testb.c -lb -o testb
$ LD_LIBRARY_PATH=. ./testb
b: 0

另外-la在编译时并不是真的需要，我之所以离开它只是因为它在你原来的例子中。取而代之的是第一行

$ gcc -Wall -fPIC -I. -L. -c b.c

就够了。

通用规则是 - 链接器是需要库的人，而不是编译器。

告诉ld在编译期间在哪里寻找依赖的共享库

1 个答案: