Localizer - это простой экспериментальный инструмент, который пытается обнаружить символы, которые могли бы локализоваться в их модуле, то есть помечать как static или перемещенные в Anon. Пространство имен.
Локализация символов полезна, поскольку она обеспечивает оптимизацию и предотвращает загрязнение интерфейса.
Инструмент работает, перехватывая вызовы на линкер и анализируя импорт и экспорт символов.
Запустите свой сценарий сборки в рамках сценария find-locals.py :
$ make clean
$ find-locals.py make -j10 all
Если вы хотите игнорировать символы, которые присутствуют в заголовках, сделайте
$ find-locals.py --ignore-header-symbols $PWD make ...
Во многих случаях символы экспортируются таким образом, чтобы их можно было использовать в модульных тестах, чтобы вам также потребовалось создание тестов:
$ find-locals.py 'make -j10 && make -j10 check'
Для получения дополнительных вариантов запустите find-locals.py -h .
Бегать
$ test/run_tests.sh
По дизайну инструмент не может обнаружить условное использование символов, которые скрыты под #ifdef s.
Иногда компилятор также достаточно умный, чтобы оптимизировать вызовы функций, даже если они присутствуют в тексте (например, пропагандируя постоянные аргументы в статические функции). По этой причине рекомендуется запустить инструмент по неоптимизированной сборке, чтобы отключить функцию, внедряющую и клонирование. Для проектов с поддержкой AutoTools просто делают
$ ./configure CFLAGS='-g -O0' CXXFLAGS='-g -O0'
Наконец, нет необходимости сообщать об неиспользованных методах C ++, так как нет никакого способа локализовать их. Но я все еще делаю это, потому что их нельзя отличить от символов в пространствах имен, которые могут быть локализованы (перемещая их в Anon. Пространства имен).
Для поддержки межкомпиляции вам может потребоваться добавить символику к соответствующему перекрестному линке в bin/ каталоге, например,
$ ln -s ld aarch64-linux-gnu-ld