Помните, что когда вы используете DKM, вы делаете только частичные ссылки на ваши единицы перевода.
Вот почему у вас могут быть неразрешенные символы в вашем DKM.
Например, если вы используете printf, когда DKM частично связан, он не знает, каков адрес функции printf, поскольку он может меняться между различными изображениями vxWorks.
Когда вы загружаете DKM, динамический загрузчик vxworks просматривает DKM и находит все неразрешенные символы в DKM и сопоставляет их с символами в ядре.
Я подозреваю, что вы столкнулись с тем, что ваш код, вероятно, основан на шаблонах, который не создается, пока время загрузки и часть шаблона не имеют ссылку на класс runtime_error.
Однако, поскольку ваш код явно не создает и не использует класс runtime_error, он отображается в качестве неразрешенного символа для загрузчика. С шаблонами можно справиться в ситуации динамической загрузки.
Компоновщик думает: «Нет проблем, динамический загрузчик позаботится об этом». К сожалению, загрузчик видит этот неразрешенный символ и громко говорит: «Эй ... Я ничего не знаю о runtime_error».
Вот почему в документации говорится (перефразируя): «Для C ++ ваш DKM должен быть автономным (как в реализации всех классов, необходимых и используемых) и не полагаться на другие DKM».
Доступны два решения:
а) делайте так, как вы, и явно используйте недостающий компонент.
б) Статически связать DKM в вашем базовом образе vxWorks (что делает его более не динамичным или загружаемым)
Если бы вы использовали RTP (вместо DKM), у вас не было бы этой конкретной проблемы, поскольку RTP полностью связан, а не частично связан.