У меня есть исполняемый файл в Ada, скомпилированный с помощью gprbuild. Исполняемый файл использует некоторую простую функцию (например, sin e cos). Этот исполняемый файл работает в приложении, привязанном к POS (операционной системе разделов), разработанной с помощью vxwork. После перекомпиляции всего процесса появляется множество ошибок объявления нескольких функций между POS_API.o и исполняемым файлом ada (hello.o). Эти функции (sin, cos,...) находятся в одной библиотеке. К сожалению, самое простое решение для разыменования всей этой функции в POS не разрешено (связано с дизайном). Любые предложения о том, как скомпилировать или продолжить? Есть ли возможность скомпилировать без конкретной библиотеки или какой-либо функции, чтобы избежать ошибки множественных ссылок?
@SimonWright Когда я использовал версии VxWorks 5.1.1, 5.4 и 5.5, был способ загрузить .o в память и вызвать пользовательские функции C прямо из командной строки. Я не знаю, было ли это артефактом пользовательской сборки ОС (нам пришлось изменить код C только для того, чтобы добавить жесткий диск в нашу систему... так что это возможно) или что-то еще.
Вы следите за этот ответ? (на что вы, кстати, не ответили: толку было?) Если да, то посмотрю еще
Я точно выполнил этот предыдущий шаг. Проблема заключается в том, как изменить исполняемый файл, чтобы избежать множественных ссылок. Есть ли какой-либо атрибут, который можно использовать в компоновщике пакетов для отключения двойной ссылки? Мне удалось добавить POS_api.o в компоновщик (среда GPS) и получить ту же ошибку.





Боюсь, это не совсем ответ: в основном потому, что прошло более десяти лет с тех пор, как я работал с VxWorks и Ada, и все стало немного туманно. Кроме того, это немного долго для комментария к вашему вопросу
Как я его использовал, VxWorks поставляется с целым набором программного обеспечения, которое вы настраиваете для хранения только тех компонентов, которые вам нужны в вашем ядре: в этом случае это, предположительно, будет включать математический пакет, такие функции, как sin(), а также функции ОС, такие как taskSpawn().
Процесс сборки Ada/VxWorks, который мы использовали, создает частично связанный объектный файл со ссылками на sin(), taskSpawn() неразрешенными (я не могу вспомнить, как это достигается; если используется GNU ld, может быть, переключатель -r или --relocatable?). Когда VxWorks загружает этот объектный файл поверх сконфигурированного ядра, неразрешенные ссылки разрешаются, и все готово.
Теперь я не знаю, что делает ваш POS_API. Это скин поверх настроенного ядра VxWorks? Загружает ли он саму вашу программу на Аде? Если это сама программа VxWorks, почему она экспортирует sin()?
Я подозреваю, что проблема связана с тем, как вы связали свой исполняемый файл. Может быть, вы могли бы показать нам свой файл GPR? Иначе я просто свистну в темноте.
Есть ли документация VxWorks о том, как решить ту же проблему с C? Я очень удивлен, обнаружив исполняемый в файле
.o, но я давно не пользовался VxWorks (5.4) и тогда такого быть не могло. Возможно, вам нужно собрать библиотеку из исходного кода Ады, а не из исполняемого файла.