gcc игнорирует регистр имен символов при связывании

Программное обеспечение, над которым я работаю, поставляется с NETLIB BLAS/LAPACK, встроенным в его исходные коды, с использованием имен символов, состоящих только из строчных букв, но теперь, перенося приложение на Windows, я обнаружил, что Intel MKL и несколько других реализаций BLAS/LAPACK для этой платформы используют все символы верхнего регистра. имена. Есть ли способ сказать компилятору/компоновщику gnu игнорировать регистр при сопоставлении имен символов?

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

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

person Cetin Sert    schedule 14.02.2010    source источник


Ответы (3)


Разница, которую вы видите, связана с соглашениями о вызовах Fortran: в Fortran регистр символов не важен, и поэтому у каждого компилятора есть способ перевести имена символов Fortran в имена символов ассемблера: компиляторы GNU обычно переводят все в нижний регистр, Intel в Windows идет для верхнего регистра.

Если вы работаете с кодом Fortran, вы можете использовать параметр -fsymbol-case-upper в старом компиляторе g77 (в новом компиляторе gfortran этого нет). В противном случае нет простого ответа для C, кроме:

  • используя #define
  • используя интерфейсы C для BLAS и LAPACK.
person F'x    schedule 16.02.2010

Я думаю, у тебя могут быть неприятности. В разделе 6.4.2.1 спецификации C говорится, что «строчные и прописные буквы различны» в отношении идентификаторов. Это означает, что с точки зрения вашего компилятора и компоновщика _DGEQP3 и _dgeqp3 являются разными символами. Вы, вероятно, можете добавить некоторые операторы #define в заголовок для конкретной платформы, чтобы выровнять все для вас.

Эта ошибка возникла из-за того, что вы связываетесь с библиотекой Windows, а не с тем, что вы использовали до этого?

person Carl Norum    schedule 14.02.2010
comment
Компиляция пакетов NETLIB BLAS или LAPACK с помощью mingw gfortran, как мы делали до сих пор, приводит к именам символов, таким как dgeqp3 (нижний регистр, последнее подчеркивание), но теперь я хочу использовать другие компиляторы и библиотеки для Windows и большинство реализаций BLAS LAPACK, распространяемых в двоичной форме, имеют имена символов, такие как _DGEQP3 (верхний регистр, без подчеркивания в конце), а некоторые даже имеют _dgeqp3 (строчные буквы, без подчеркивания в конце). У нас уже есть операторы #define для покрытия конечных символов подчеркивания, и если я не смогу найти способ обойти эту проблему с учетом регистра, я думаю, нам придется соответствующим образом их дополнить. - person Cetin Sert; 14.02.2010
comment
@Cetin, иногда так крошится печенье. Удачи! - person Carl Norum; 14.02.2010

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";

кажется, есть способ ввести псевдонимы символов во время компоновки, используя --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 ~
$

Также должен быть способ дать компоновщику различные сценарии для обработки большого количества таких определений символов. Таким образом, я мог бы сделать частью процесса сборки автоматическое создание скриптов компоновщика, которые создают сопоставления между различными случаями.

person Cetin Sert    schedule 14.02.2010