Разрешение круговых зависимостей путем связывания одной и той же библиотеки в два раза?

У нас есть база кода, разбитая на статические библиотеки. К сожалению, библиотеки имеют круговые зависимости; например, libfoo.a зависит от libbar.a и наоборот.

Я знаю, что "правильный" способ справиться с этим - использовать параметры компоновщика --start-group и --end-group, например:

g++ -o myApp -Wl,--start-group -lfoo -lbar -Wl,--end-group

Но в наших существующих Makefiles проблема обычно обрабатывается следующим образом:

g++ -o myApp -lfoo -lbar -lfoo

(Представьте, что это расширено до ~ 20 библиотек со сложными взаимозависимостями.)

Я проходил через наши Makefiles, меняя вторую форму на первый, но теперь мои коллеги спрашивают меня, почему... И кроме "потому что это чище" и смутное ощущение, что другая форма рискованна, У меня нет хорошего ответа.

Итак, можно ли связать одну и ту же библиотеку несколько раз, когда-либо создавая проблему? Например, может ли сбой связи с многократно определенными символами, если один и тот же .o вытягивается дважды? Или есть ли риск, который мы могли бы завершить двумя копиями одного и того же статического объекта, создавая тонкие ошибки?

В принципе, я хочу знать, есть ли возможность сбоев времени или времени выполнения при связывании одной и той же библиотеки несколько раз; и если да, то как их запускать. Спасибо.

Ответ 1

Все, что я могу предложить, - это отсутствие встречного примера. Я никогда раньше не видел первую форму (хотя это явно лучше), и всегда видел, как это разрешилось со второй формой и в результате не наблюдалось проблем.

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

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

Ответ 2

Поскольку это устаревшее приложение, я уверен, что структура библиотек унаследована от какой-либо договоренности, которая, вероятно, не имеет значения, например, используется для создания другого продукта, который вы больше не выполняете.

Даже если все еще остаются структурные причины для унаследованной структуры библиотеки, почти наверняка, было бы приемлемо построить еще одну библиотеку из унаследованной организации. Просто поместите все модули из 20 библиотек в новую библиотеку, liballofthem.a. Тогда каждое отдельное приложение просто g++ -o myApp -lallofthem ...