运行时库本质上是动态库吗? [英] Are runtime libraries inherently dynamic libraries?

问题描述

我正在为带有OpenMP并行化程序的系统进行交叉编译，但是当我在目标上运行时，出现错误:

I am cross compiling for a system with an OpenMP parallelized program, but when I run on the target, I get the error:

无法加载库'libgomp.so.1'

can't load library 'libgomp.so.1'

环顾四周后，我发现它是一个OpenMP运行时库.是否有将其库静态链接到编译器主机上的方法，或者它是否需要存在于目标计算机上?如果它可以静态链接，那么是什么使运行时库与动态库不同?如果环境正确，可以静态或动态链接任何库吗?

After looking around, I see that it's an OpenMP runtime library. Is there any was to statically link the library it on the compiler host machine, or does it need to be present on the target machine? If it can be statically linked, then what makes a runtime library different from a dynamic library? Could one statically or dynamically link any library, provided the environment was correct?

推荐答案

您可以通过提供某些链接器选项来选择性地静态链接某些库.对于libgomp，它将类似于:

You can selectively statically link certain libraries by providing certain linker options. For libgomp it would be something like:

gcc -o executable foo.o bar.o -Wl,-static -lgomp -Wl,-Bdynamic -lpthread -lother -llibs

-Wl,-static和-Wl,-Bdynamic之间列出的任何库都将静态链接. -fopenmp不应出现在链接命令中，因为它会扩展为在用户提供的选项后附加的链接器标志，因此应明确列出libpthread.这也意味着，即使简单的OpenMP程序也必须在两个单独的步骤中进行编译和链接，以使静态链接正常工作.

Any library listed between -Wl,-static and -Wl,-Bdynamic will be linked in statically. -fopenmp should not be present in the linking command as it expands to linker flags that get appended after the user supplied options, and therefore libpthread should be listed explicitly. It also means that even simple OpenMP programs have to be compiled and linked in two separate steps for static linking to work.

示例:

// foo.c
#include <stdio.h>
#include <omp.h>

int main(void)
{
   #pragma omp parallel
   printf("Hello world from thread %d\n", omp_get_thread_num());
   return 0;
}

传统编译:

$ gcc -fopenmp -o foo foo.c
$ ldd foo
     linux-vdso.so.1 =>  (0x00007ffff5661000)
     libgomp.so.1 => /usr/lib64/libgomp.so.1 (0x0000003bcfa00000)
     libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003bc2600000)
     libc.so.6 => /lib64/libc.so.6 (0x0000003bc1e00000)
     librt.so.1 => /lib64/librt.so.1 (0x0000003bc3200000)
     /lib64/ld-linux-x86-64.so.2 (0x0000003bc1a00000)

程序与libgomp的DSO版本链接.

The program is linked against the DSO version of libgomp.

完全静态链接:

$ gcc -fopenmp -static -o foo foo.c
$ ldd foo
     not a dynamic executable

使用-static，所有库都静态链接到可执行文件中.

With -static all libraries are linked in statically into the executable.

仅静态链接libgomp:

$ gcc -fopenmp -c foo.c
$ gcc -o foo foo.o -Wl,-static -lgomp -Wl,-Bdynamic -lpthread
$ ldd foo
     linux-vdso.so.1 =>  (0x00007ffdaaf61000)
     libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003bc2600000)
     libc.so.6 => /lib64/libc.so.6 (0x0000003bc1e00000)
     /lib64/ld-linux-x86-64.so.2 (0x0000003bc1a00000)

在这种情况下，保持静态链接对象的正确顺序很重要.如果将foo.o放在-lgomp之后，则会导致链接错误:

It is important to maintain the correct order of statically linked objects in that case. If foo.o is placed after -lgomp, a link error results:

$ gcc -o foo -Wl,-static -lgomp -Wl,-Bdynamic foo.o -lpthread
foo.o: In function `main':
foo.c:(.text+0x14): undefined reference to `GOMP_parallel_start'
foo.c:(.text+0x23): undefined reference to `GOMP_parallel_end'
foo.o: In function `main.omp_fn.0':
foo.c:(.text+0x3b): undefined reference to `omp_get_thread_num'
collect2: ld returned 1 exit status

任何由包含OpenMP构造的源代码生成的目标文件都应放置在之前 -lgomp.

Any object file resulting from source code that contains OpenMP constructs should be placed before -lgomp.

这篇关于运行时库本质上是动态库吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！