Я унаследовал часть программного обеспечения, которое имеет некоторые проблемы. Я считаю, что проблемы связаны с версией libc, которая компонуется статически.
Я строю это на машине с Windows XP, ориентируясь на машину x86 QNX Neutrino 6.3.2.
Ранее программное обеспечение, созданное с помощью GCC 2.95.3 (ну, технически, это QCC от QNX, которое обертывает и вызывает GCC). Кто-то добавил функцию и пришлось портировать его для сборки с GCC 3.3.5, потому что в этом нуждалась новая функция.
Теперь программа моя. Мне нужно внести некоторые дополнения, но я заметил странное поведение. Немного покопавшись, я обнаружил, что есть статические ссылки как на libc для 2.95.3, так и для 3.3.5. Согласно веб-сайту QNX, :
GCC 2.95.3 (начиная с 6.2.1 или 6.3) и GCC 3.3.5 используют разные C++ ABI и имеют разное изменение имени. В результате вы не можете связать двоичные файлы C++ (объекты, исполняемые файлы, библиотеки), созданные с помощью GCC 2.95.3, с двоичными файлами, созданными с помощью GCC 3.3.5.
Это критическое изменение ABI, поэтому я явно обеспокоен. Я написал небольшой тест для этого
#include <stdio.h>
int main()
{
FILE *stream_ptr = popen("fakename","r"); /// use libc
return 0;
}
и построил его с 3.3.5:
QCC -V3.3.5,gcc_ntox86 small.cpp -o small.out
затем использовал строки, чтобы увидеть, что было статически связано для этой программы
strings -a small.out | grep GCC
GCC: (GNU) 3.3.5 (qnx-nto)
GCC: (GNU) 3.3.5 (qnx-nto)
GCC: (GNU) 2.95.3
GCC: (GNU) 3.3.5 (qnx-nto)
Как видите, libc для GCC 2.95.3 линкуется статически.
Мой первый вопрос: Как я могу сделать эту ссылку с версией 3.3.5 libc?
Мой второй вопрос: Почему он связан с 2.95.3 в первую очередь?
Что я делаю неправильно/упускаю? Любые предложения приветствуются.
(В проекте, вероятно, есть еще 60 вещей, связанных с объектами версии 2.95.3, и мне нужно исправить их все, поэтому реализация popen() и 59 его ближайших друзей — не лучшая идея. ...)
Спасибо,
Карл
ОБНОВЛЕНИЕ:
Так что я еще не понял, как это исправить, но немного предыстории для QNX 6.3.2, чтобы людям, которые наткнутся на это позже, не пришлось разбираться с трудностями:
Вы можете использовать параметр verbose для компоновщика ld --verbose и заставить его выдать все, что он делает. Обратите внимание, что я получил следующий вывод, когда сделал это:
attempt to open C:/QNX632/host/win32/x86/usr/lib/gcc-lib/i386-pc-nto-qnx6.3.0/3.3.5//libc.a failed
attempt to open C:/QNX632/target/qnx6/x86/lib/gcc/3.3.5/libc.a failed
attempt to open C:/QNX632/target/qnx6/usr/i386-pc-nto-qnx6.3.0/lib//libc.a failed
attempt to open C:/QNX632/target/qnx6/usr/lib/libc.a failed
attempt to open C:/QNX632/target/qnx6/x86/lib//libc.a succeeded
Как видно, компоновщик пытается открыть версию 3.3.5 libc.a, но ее там просто нет. Я просмотрел компьютеры 3 других коллег, и версии 3.3.5 libc.a там нет. Я не уверен, как это работает даже при критическом изменении ABI, но я подозреваю, что некоторая неуклюжесть в этом проекте связана с этим несоответствием.
Хотя это отвечает на мои первоначальные вопросы,
1) Вы не можете связать его с несуществующими файлами libc.a,
2) Он выбирает версию 2.95.3, потому что версии 3.3.5 там нет,
вызывает новые вопросы:
3) Почему QNX не поставляет версию libc.a 3.3.5 с этой версией Momentics? (или, если да, то где они ее прячут, потому что я ее пропустил.)
4) Существуют ли какие-либо жизнеспособные обходные пути? Мне удалось собрать все, кроме двух самых важных серверов в проекте, без использования libc, но пока я не исправлю последние два, я все еще ищет решение.
Обновление до обновления:
Работая с людьми из QNX, они создали мне неподдерживаемую, непроверенную инженерную версию libc.a, libm.a и libsocket.a с GCC 3.3.5, и с тех пор все было хорошо.
