gcc 在链接时忽略符号名称的大小写

发布于 2024-08-21 15:02:18 字数 293 浏览 3 评论 0原文

我正在开发的一个软件使用全小写符号名称将 NETLIB BLAS/LAPACK 嵌入到其源代码中,但现在将应用程序移植到 Windows 时我发现 Intel MKL 和该平台的其他几个 BLAS/LAPACK 实现使用全大写符号名称。有没有办法告诉 gnu 编译器/链接器在匹配符号名称时忽略大小写?

.
.
.
undefined reference to `_dgeqp3'
.
.
.

$ nm /lib/LAPACK.lib | grep -i " T _dgeqp3"
00000000 T _DGEQP3

A software I am working on ships with NETLIB BLAS/LAPACK embedded into its sources using all-lowercase symbol names but now while porting the application to windows I discovered that Intel MKL and several other BLAS/LAPACK implementations for this platform use all-uppercase symbol names. Is there a way to tell the gnu compiler/linker to ignore case while matching symbol names?

.
.
.
undefined reference to `_dgeqp3'
.
.
.

$ nm /lib/LAPACK.lib | grep -i " T _dgeqp3"
00000000 T _DGEQP3

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

扫码二维码加入Web技术交流群

发布评论

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

评论(3

木落 2024-08-28 15:02:18

您看到的差异是由于 Fortran 调用约定造成的:在 Fortran 中,符号大小写并不重要,因此每个编译器都有一种方法将 Fortran 符号名称转换为汇编程序符号名称:GNU 编译器通常将全部转换为小写,Windows 上的 Intel 则如此为大写。

如果您使用 Fortran 代码,则可以在较旧的 g77 编译器(较新的 gfortran编译器没有这个)。否则,C 没有简单的答案,除了:

  • 使用 #define
  • 使用 BLAS 和 LAPACK 的 C 接口。

The difference you're seeing is due to Fortran calling conventions: in Fortran, symbol case is unimportant, and thus every compiler has a way to translate Fortran symbol names into assembler symbol names: GNU compilers usually translate all to lowercase, Intel on Windows goes for uppercase.

If you're working with Fortran code, you can use the -fsymbol-case-upper option on the older g77 compiler (the newer gfortran compiler doesn't have this). Otherwise, no simple answer for C, except:

  • using #define's
  • using the C interfaces to BLAS and LAPACK.
┊风居住的梦幻卍 2024-08-28 15:02:18

我想你可能遇到麻烦了。 C 规范第 6.4.2.1 节规定关于标识符“小写字母和大写字母是不同的”。这意味着就编译器和链接器而言,_DGEQP3_dgeqp3 是不同的符号。您可以在特定于平台的标头中添加一些 #define 语句来为您排列内容。

是否是因为您链接的是 Windows 库,而不是您之前使用的任何库,导致此错误出现?

I think you might be in for some trouble. Section 6.4.2.1 of the C spec says "Lowercase and uppercase letters are distinct" with respect to identifiers. That means that as far as your compiler and linker are concerned, _DGEQP3 and _dgeqp3 are different symbols. You can probably add some #define statements in a platform-specific header to line things up for you.

Is it because you're linking against a windows library rather than whatever you were using before that this bug showed up?

百变从容 2024-08-28 15:02:18

tc

#define __CONCAT(x,y) x##y

#ifdef SUFFIX
#define __SUFFIX(x) __CONCAT(x,_)
#else
#define __SUFFIX(x) x
#endif

#ifdef UPPER
#define __c(U,l) __SUFFIX(U)
#else
#define __c(U,l) __SUFFIX(l)
#endif

#define xaxpy __c(XAXPY, xaxpy)

#include <stdio.h>

char* xaxpy;
char* DAXPY;

int main()
{
    printf(xaxpy);
    printf(DAXPY);
}

ec

char* xaxpy  = "ln";
char* xaxpy_ = "ls";
char* XAXPY  = "UN";
char* XAXPY_ = "US";

似乎有一种方法可以在链接时使用 --defsym 引入符号别名:

Cetin@BAKA-CHAN ~
$ gcc -D UPPER -D SUFFIX -c t.c e.c

Cetin@BAKA-CHAN ~
$ gcc -o t t.o e.o -Wl,--defsym=_DAXPY=_xaxpy

Cetin@BAKA-CHAN ~
$ ./t
USln
Cetin@BAKA-CHAN ~
$

还必须有一种方法可以为链接器提供不同的脚本来处理大量此类符号定义。因此,我可以将其作为构建过程的一部分来自动创建链接器脚本,以在不同情况之间创建映射。

t.c

#define __CONCAT(x,y) x##y

#ifdef SUFFIX
#define __SUFFIX(x) __CONCAT(x,_)
#else
#define __SUFFIX(x) x
#endif

#ifdef UPPER
#define __c(U,l) __SUFFIX(U)
#else
#define __c(U,l) __SUFFIX(l)
#endif

#define xaxpy __c(XAXPY, xaxpy)

#include <stdio.h>

char* xaxpy;
char* DAXPY;

int main()
{
    printf(xaxpy);
    printf(DAXPY);
}

e.c

char* xaxpy  = "ln";
char* xaxpy_ = "ls";
char* XAXPY  = "UN";
char* XAXPY_ = "US";

there seems to be a way to introduce symbol aliases at link-time using --defsym:

Cetin@BAKA-CHAN ~
$ gcc -D UPPER -D SUFFIX -c t.c e.c

Cetin@BAKA-CHAN ~
$ gcc -o t t.o e.o -Wl,--defsym=_DAXPY=_xaxpy

Cetin@BAKA-CHAN ~
$ ./t
USln
Cetin@BAKA-CHAN ~
$

There must also be a way to give the linker different scripts to handle a large number of such symbol definitions. So I could make it part of the build process to automatically create linker scripts that create mappings between different cases.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文