Здравствуйте!

Обращаюсь с просьбой посодействовать по следующему вопросу.
Существует файл статической библиотеки <filename.a> и header-файл <filename.h>, где объявлены типы и функции.
Исходный код библиотеки разработчик предпочел скрыть и предоставил .a -файл, скомпилированый в IAR.

Моя же задача - правильно сцепить данную библиотеку с моим проектом, компилируемым с помощью GCC. Однако, линковщик предупреждает о возможных ошибках в работе программы из-за несовместимости типов wchar_t. Мне удалось выяснить что в среде Windows этот символьный тип имеет размер в 2 байта, а в Linux - целых 4.

Возникло два вопроса.

1) Нужно ли обращать внимание на этот warning? Ведь размер wchar_t в стандартных библиотеках компилятора GCC больше, чем в рассматриваемой. И в первом приближении кажется, что потери данных произойти не может (исключая случай с переполнением возвращаемых в код библиотеки переменных).

2) Если ответ на первый вопрос - нужно. В подпрограмме ReadELF можно просматривать имена функций библиотеки. А можно ли каким-нибудь образом узнать типы входных и выходных параметров этих функций? Ведь линковщик как-то понимает, что это ни что иное, как wchar_t!

Большое спасибо!

дак если есть <filename.h>, там же имена и параметры передаваемые/возвращаемые указаны. насчёт 2/4 байта - результаты могут быть плачевные, если в функциях идёт дополнительное преобразование типов.

В .h объявлены (увы) только пользовательские функции... Среди них ни одна не равна и не имеет в качестве аргумента wchar_t...

Да.
Если допустить, что четырехбайтный wchar_t это unsigned long int, а двухбайтный- unsigned int, то мой вопрос можно записать так:



p.s. Про такое, как флаг -fshort wchar и макрос __WCHAR_MAX__ я читал, но задействие сих может окончится печально при работе других стандартных библиотек...

А может быть, кто-то имеет достаточный опыт, чтобы ответить на вопрос, или высказать соображения: возможно ли вообще использовать библиотеку, скомпилированную в IAR для проекта, компилируемого GCC?
Или, быть может, по каким-то причинам, это заведомо невозможно?

Может было бы и возможно если оба компилятора удовлетворяли одному abi-eabi.
Мне думается, что вряд-ли это так...

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

Моё мнение, что компиляторы не особо что-то кому-то должны. Они просто соответствую и говорят об этом либо нет, что тоже вполне возможно.