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

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

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

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

источник

2010-02-14 Cetin Sert

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

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

с использованием #define «s
используя интерфейсы C для BLAS и LAPACK.

источник

2010-02-16 20:25:53

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

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

источник

2010-02-14 02:18:22

Компиляция Netlib BLAS или LaPack пакеты с MinGW gfortran, как мы делали до сих пор, результаты в именах символов, как ___dgeqp3___ (в нижнем регистре, окончательное подчеркивание), но теперь я хочу использовать другие компиляторы и библиотеки в Windows, и большинство BLAS Реализации LAPACK, распределенные в двоичной форме, имеют имена символов, такие как _DGEQP3 (верхний регистр, окончательный знак подчеркивания), а некоторые даже имеют _dgeqp3 (нижний регистр, без окончательного подчеркивания). У нас уже есть #define заявления, чтобы охватить окончательные подчеркивания, и если я не могу найти способ обойти эту проблему с чувствительностью к регистру, я думаю, нам придется их дополнять соответствующим образом. –

@ Цетин, иногда это то, как печенье рушится. Удачи! –

дц

#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); 
}

ес

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

там, кажется, способ введения символа псевдонимы на время компоновки с помощью --defsym:

[email protected] ~ 
$ gcc -D UPPER -D SUFFIX -c t.c e.c 

[email protected] ~ 
$ gcc -o t t.o e.o -Wl,--defsym=_DAXPY=_xaxpy 

[email protected] ~ 
$ ./t 
USln 
[email protected] ~ 
$

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

источник

2010-02-14 18:51:24

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

ответ

Смежные вопросы