Проста перевірка на наявність невирішених символів у спільних бібліотеках?

Question 1

Я пишу досить велику бібліотеку спільних об'єктів C ++ і зіткнувся з невеликою проблемою, яка завдає налагодження біль:

Якщо я визначаю функцію / метод у файлі заголовка та забуваю створити для нього заглушку (під час розробки), оскільки я будую спільну бібліотеку об'єктів, а не виконуваний файл, під час компіляції не виникає помилок, які повідомляють мені, що я маю забули реалізувати цю функцію. Єдиний спосіб виявити, що щось не так, - це час виконання, коли врешті-решт додаток, що посилається на цю бібліотеку, падає з помилкою "невизначений символ".

Я шукаю простий спосіб перевірити, чи є у мене всі символи, які мені потрібні під час компіляції, можливо, щось, що я можу додати до свого Makefile.

Одне з рішень, яке я придумав, - це запустити скомпільовану бібліотеку, nm -C -Uщоб отримати детальний список усіх невизначених посилань. Проблема полягає в тому, що це також призводить до переліку всіх посилань, які є в інших бібліотеках, таких як GLibC, що, звичайно, буде пов’язано з цією бібліотекою при складанні остаточної програми. Можна було б використовувати вивід nmto grepчерез усі мої файли заголовків і перевірити, чи відповідає якесь із імен .. але це здається божевільним. Напевно, це не рідкість, і є кращий спосіб її вирішення?

Question 2

Ознайомтесь з опцією компонувальника -z defs/ --no-undefined. Створюючи спільний об'єкт, це призведе до збою посилання, якщо є невирішені символи.

Якщо ви використовуєте gcc для виклику лінкера, ви будете використовувати -Wlопцію компілятора, щоб передати параметр лінкеру:

gcc -shared ... -Wl,-z,defs

Як приклад, розглянемо такий файл:

#include <stdio.h>

void forgot_to_define(FILE *fp);

void doit(const char *filename)
{
    FILE *fp = fopen(filename, "r");
    if (fp != NULL)
    {
        forgot_to_define(fp);
        fclose(fp);
    }
}

Тепер, якщо ви вбудуєте це у спільний об’єкт, це вдасться:

> gcc -shared -fPIC -o libsilly.so silly.c && echo succeeded || echo failed
succeeded

Але якщо ви додасте -z defs, посилання не вдасться повідомити про ваш відсутній символ:

> gcc -shared -fPIC -o libsilly.so silly.c -Wl,-z,defs && echo succeeded || echo failed
/tmp/cccIwwbn.o: In function `doit':
silly.c:(.text+0x2c): undefined reference to `forgot_to_define'
collect2: ld returned 1 exit status
failed

Question 3

У Linux (який, здається, ви використовуєте) ldd -r a.outповинен дати вам саме ту відповідь, яку ви шукаєте.

ОНОВЛЕННЯ: тривіальний спосіб створення, a.outщодо якого слід перевірити:

 echo "int main() { return 0; }" | g++ -xc++ - ./libMySharedLib.so
 ldd -r ./a.out

Question 4

А як щодо тестового набору? Ви створюєте фіктивні виконувані файли, які посилаються на потрібні вам символи. Якщо зв’язування не вдається, це означає, що інтерфейс вашої бібліотеки неповний.

Question 5

У мене колись була така сама проблема. Я розробляв модель компонентів на C ++, і, звичайно, компоненти повинні завантажуватися під час виконання динамічно. На думку приходять три рішення, які я застосовував:

Виділіть трохи часу, щоб визначити систему складання, яка здатна статично компілюватись. Ви втратите трохи часу на його розробку, але це заощадить вам багато часу, щоб вловити ці надокучливі помилки виконання.
Згрупуйте свої функції у відомі та добре зрозумілі розділи, щоб ви могли згрупувати функції / заглушки, щоб переконатися, що кожна відповідна функція має свою заглушку. Якщо ви витратите час на те, щоб це добре документувати, ви можете написати, можливо, скрипт, який перевіряє визначення (наприклад, за допомогою коментарів до кисню) та перевіряє відповідний файл .cpp для нього.
Виконайте кілька тестових виконуваних файлів, які завантажують один і той же набір бібліотек, і вкажіть прапор RTLD_NOW, який потрібно відкрити (якщо ви перебуваєте у * NIX). Вони сигналізуватимуть про відсутні символи.

Сподіваюся, що це допомагає.