静态链接 LAPACK

发布于 2024-12-01 05:25:37 字数 542 浏览 1 评论 0原文

我正在尝试发布一些软件，目前正在编写构建过程的脚本。我被困在我从未想过会做的事情上，在 x86_64 linux 上静态链接 LAPACK。在配置期间，AC_SEARCH_LIB([main],[lapack]) 可以工作，但 lapack 单元的编译不起作用，例如 undefiend reference to 'dsyev_' --no lapack /blas 例行公事被忽视。

我已经确认我已经安装了这些库，甚至自己使用适当的选项编译了它们，以使它们静态化并获得相同的结果。

下面是我几年前第一次使用 LAPACK 时使用的一个示例，它是动态运行的，但不是静态运行的： http:// astebin.com/cMm3wcwF

我用来编译的两种方法如下，

gcc -llapack -o eigen eigen.c
gcc -static -llapack -o eigen eigen.c

原文

I'm attempting to do a release of some software and am currently working through a script for the build process. I'm stuck on something I never thought I would be, statically linking LAPACK on x86_64 linux. During configuration AC_SEARCH_LIB([main],[lapack]) works, but compilation of the lapack units do not work, for example undefiend reference to 'dsyev_' --no lapack/blas routine goes unnoticed.

I've confirmed I have the libraries installed and even compiled them myself with the appropriate options to make them static with the same results.

Here is an example I had used in my first experience with LAPACK a few years ago that works dynamically, but not statically: http://pastebin.com/cMm3wcwF

The two methods I'm using to compile are the following,

gcc -llapack -o eigen eigen.c
gcc -static -llapack -o eigen eigen.c

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

述情 2024-12-08 05:25:37

您的链接顺序错误。在需要库的代码之后而不是之前链接库。像这样：

gcc -o eigen eigen.c -llapack 
gcc -static -o eigen eigen.c -llapack

这应该可以解决链接问题。

为了回答随后的问题为什么它有效，GNU ld 文档这样说：

在命令中的哪个位置写入此选项会有所不同；这
链接器按顺序搜索并处理库和目标文件
它们是指定的。因此，foo.o -lz bar.o' 在之后搜索库z'
文件 foo.o 但在 bar.o 之前。如果 bar.o 引用 `z' 中的函数，
这些功能可能无法加载。
......
通常这样找到的文件是库文件——归档文件
其成员是目标文件。链接器通过以下方式处理存档文件
扫描它以查找定义迄今为止具有的符号的成员
已被引用但未定义。但如果找到的文件是
普通目标文件，它以通常的方式链接。

IE。链接器将遍历一个文件来查找未解析的符号，并且它按照您提供的顺序跟踪文件（即“从左到右”）。如果在读取文件时尚未指定依赖关系，则链接器将无法满足依赖关系。链接列表中的每个对象仅被解析一次。

另请注意，在链接共享库或目标文件时检测到循环依赖性的情况下，GNU ld 可以进行重新排序。但静态库仅解析一次未知符号。

Your linking order is wrong. Link libraries after the code that requires them, not before. Like this:

gcc -o eigen eigen.c -llapack 
gcc -static -o eigen eigen.c -llapack

That should resolve the linkage problems.

To answer the subsequent question why this works, the GNU ld documentation say this:

It makes a difference where in the command you write this option; the
linker searches and processes libraries and object files in the order
they are specified. Thus, foo.o -lz bar.o' searches libraryz' after
file foo.o but before bar.o. If bar.o refers to functions in `z',
those functions may not be loaded.
........
Normally the files found this way are library files—archive files
whose members are object files. The linker handles an archive file by
scanning through it for members which define symbols that have so far
been referenced but not defined. But if the file that is found is an
ordinary object file, it is linked in the usual fashion.

ie. the linker is going to make one pass through a file looking for unresolved symbols, and it follows files in the order you provide them (ie. "left to right"). If you have not yet specified a dependency when a file is read, the linker will not be able to satisfy the dependency. Every object in the link list is parsed only once.

Note also that GNU ld can do reordering in cases where circular dependencies are detected when linking shared libraries or object files. But static libraries are only parsed for unknown symbols once.

回复收藏 0 原文

~没有更多了~