Когда линковщик предаёт: как одинаковые символы из разных библиотек ломают ваше приложение

При линковке приложения с двумя статическими библиотеками, в которых определён один и тот же символ, возникает классическая и потенциально фатальная проблема — двойное определение символа. Вроде бы всё просто: multiple definition — ошибка, надо переименовать. Но не тут-то было.

Разберёмся, как устроен линковщик, почему конфликты могут не проявляться сразу, и как на проде всё может пойти не так. Ну и конечно, как эту проблему исправить, не трогая архитектуру проекта.

Исходники: два public-файла и одна общая зависимость.

// pri.h int pri_foo(int);  // pri.c #include "pri.h" int pri_foo(int a) { return a * 10; }  // pub_foo.h int pub_foo(int);  // pub_foo.c #include "pub_foo.h" #include "pri.h" int pub_foo(int a) { return pri_foo(a + 11); }  // pub_boo.h int pub_boo(int);  // pub_boo.c #include "pub_boo.h" #include "pri.h" int pub_boo(int a) { return pri_foo(a + 22); } 

Собираем и смотрим символы.

gcc -c pri.c -o pri.o gcc -c pub_foo.c -o pub_foo.o gcc -c pub_boo.c -o pub_boo.o nm *.o ======================================= pri.o:       T pri_foo pub_foo.o:   U pri_foo, T pub_foo pub_boo.o:   U pri_foo, T pub_boo

Ничего необычного: pri_foo глобальный, вызывается из обоих public-файлов.

Собираем библиотеки с дублированием pri.o .

ar rcs libpub_foo.a pub_foo.o pri.o ar rcs libpub_boo.a pub_boo.o pri.o nm *.a ======================================= libpub_boo.a: pub_boo.o:   U pri_foo, T pub_boo pri.o:       T pri_foo libpub_foo.a: pub_foo.o:   U pri_foo, T pub_foo pri.o:       T pri_foo

В обеих статических библиотеках теперь содержится реализация pri_foo. Казалось бы — жди конфликтов при линковке.

// main.c #include "pub_foo.h" #include "pub_boo.h" #include <stdio.h>  int main() {     printf("%d\n", pub_foo(0));     printf("%d\n", pub_boo(0)); }

gcc main.c -L. -lpub_foo -lpub_boo -o test ./test ======================================= 110 220

…И это неверно. Хотя, как говорится, ответ вроде бы верный.

Почему? Потому что линковщик ld просто берёт первую встретившуюся реализацию pri_foo, удовлетворяет U, и вторую выбрасывает без предупреждений.

Порядок флагов -lpub_foo -lpub_boo определяет, какая версия pri_foo попадёт в бинарь, другая в «забвение».

А если pri_fooбудет иметь две разные реализации в каждой библиотеке?

// pri_for_foo.c #include "pri.h" int pri_foo(int a) { return a * 1000; }  // pri_for_boo.c #include "pri.h" int pri_foo(int a) { return a * 100; }

Собираем по той же схеме:

gcc -c pri_for_foo.c pub_foo.c gcc -c pri_for_boo.c pub_boo.c ar rcs libpub_foo.a pub_foo.o pri_for_foo.o ar rcs libpub_boo.a pub_boo.o pri_for_boo.o nm *.a ======================================= libpub_boo.a: pub_boo.o:       U pri_foo, T pub_boo pri_for_foo.o:   T pri_foo libpub_foo.a: pub_foo.o:       U pri_foo, T pub_foo pri_for_boo.o:   T pri_foo

Ну и чего мы ждём от тестового приложения?
11 * 1000 = 11000
22 * 100 = 2200

И что же мы увидим?

gcc main.c -L. -lpub_boo -lpub_foo -o test && ./test # Вывод: 1100, 2200

Как видно, теперь ответ неверный. Могу показать фокус.

gcc main.c -L. -lpub_foo -lpub_boo -o test && ./test # Вывод: 11000, 22000

Катастрофа: результат зависит от порядка флагов линковки. Это — полноценное неопределённое поведение. В больших проектах с зависимостями это приведёт к краху, отладке в ночи и душевным травмам.

И если вам кажется что с вами этого произойти не может, то напомню что любая не static функция из .c файла попадает в список внешних символов. Или, например, ваша библиотека статически линкует универсальные модули, и если разные версии этих модулей встретятся при линковке конечного приложения, то вы в ловушке.

Можно ли найти решение в динамической линковке? Определённо, но контроль и версионность символов в них отдельная тема.

Можно ли решить проблему в нашем примере? Да, но для этого понадобится два дополнительных шага при сборке. По сути необходимо разрешить символ pri_fooна стадии сборки самой библиотеки и скрыть символ pri_foo. Следите за руками!

Берём наши существующие объектные файл и объединяем их в один .o

> ld -r pri_for_boo.o pub_boo.o -o boo_combo.o > ld -r pri_for_foo.o pub_foo.o -o foo_combo.o nm foo_combo.o boo_combo.o ======================================= boo_combo.o:   T pri_foo, T pub_boo foo_combo.o:   T pri_foo, T pub_foo

Внешняя зависимость U pri_fooушла, теперь с чистой совестью символ pri_fooможно делать локальным.

objcopy boo_combo.o --localize-symbol pri_foo objcopy foo_combo.o --localize-symbol pri_foo nm foo_combo.o boo_combo.o ======================================= boo_combo.o:   t pri_foo, T pub_boo foo_combo.o:   t pri_foo, T pub_foo

Поменялось не многое, но по сути мы сделали символ pri_foo почти static. Почему почти? Потому что он всё ещё тут и удалить его не получится. Красивая картинка, когда nm показывает ТОЛЬКО публичное API библиотеки, не выходит. И удалить символ полностью мне пока не удалось. Если есть идеи, буду рад почитать в комментариях!

Однако что же будет теперь с выводом приложения?

> ar rcs libpub_foo.a foo_combo.o; ar rcs libpub_boo.a boo_combo.o > gcc main.c -L. -lpub_foo -lpub_boo -o test > ./test 11000 2200 > gcc main.c -L. -lpub_boo -lpub_foo -o test > ./test 11000 2200

Порядок линковки не важен, всё на месте.

Мораль: разработчику Си-библиотек приходится контролировать не только публичное API библиотеки, но и следить, чтобы приватное не просачивалось в глобальный namespace. Также большим плюсом считаю, что дёрнуть приватную функцию из библиотеки, просто угадав прототип, уже не выйдет.