Как упоминалось в других ответах SO, я использую механизм обертывания GNU ld для перехвата вызовов на malloc
в Linux (см. Пример here). Используемый флаг компоновщика - -Wl,--wrap=malloc
и соответствующий void __wrap_malloc(size_t)
. Это хорошо работает в тестовом приложении, где весь блок компиляции связан с одним и тем же двоичным кодом.неразрешенный символ __real_malloc при динамической загрузке библиотеки, которая скомпилирована с помощью --wrap = malloc
Теперь мне нужно изменить динамически связанную библиотеку, которая загружается в основную программу через dlopen()
. Связывание библиотеки преуспевает, но загрузка ее в основную программу завершается с undefined symbol: __real_malloc
.
Запуск nm
в библиотеке показывает, что __wrap_malloc
определен, но __real_malloc
нет. Но в соответствии с man ld
и this Ответ на вопрос malloc
должен быть заменен на __wrap_malloc
, а __real_malloc
должен указывать на malloc
при использовании этой техники.
В тестовом приложении я вижу, что __real_malloc
не определено в скомпилированных объектных файлах, но разрешен после соединения с исполняемым файлом.
Итак, почему символ разрешен в тестовом приложении, но не в динамической библиотеке? В обоих случаях выполняется заключительный этап ссылки, который должен разрешить этот символ. Или требуется добавить другую библиотеку во время этапа ссылки динамической библиотеки, чтобы получить разрешение __real_malloc
?
На всякий случай, невозможно изменить целевое приложение, которое загружает динамическую библиотеку через dlopen
.
Спасибо за пример и извините за возвращение так поздно. После добавления 'extern 'C'' деклараций к функциям, изменение включает в эквивалент 'C++' и компиляцию файлов с помощью 'g ++', это работает для этого примера. К сожалению, проект, над которым я работаю, намного сложнее. Так что это проблема в процессе сборки. Может быть, я обновлю вопрос, если у меня появятся подробности об этой проблеме. – MKroehnert