ЕМ>Не. В идеале такой компилятор должен получать на вход исключительно исходники (хотя бы обфусцированные). Обладая должной мощью, он мог бы найти все возможные зависимости (вплоть до динамических), по ним построить граф, и максимально его оптимизировать, а все ненужное выкинуть. Тогда, действительно, из десятка библиотек, по сотне мегабайт каждая, можно будет собрать бинарник в пару десятков килобайт, если его функциональность большего не требует.

Турбопаскаль и Дельфи при компоновке успешно выкидывали код неиспользуемых процедур/методов без всяких исходников — для построения графа вполне достаточно того, что в объектных файлах есть ИМЕНА/сигнатуры процедур/методов (и скорее ВСЕХ, чем только вызываемых из них и ими самими — что-то типа таблиц импорта/экспорта в dll, но явно шире).
Скорее всего, стандартные форматы obj/lib такое не позволяют, но у Борланда были свои.

ЕМ>(вплоть до динамических)

А вот с этим — облом! Динамическое компилятору (тем более линкеру) ну никак не проанализировать (без исполнения кода, да и оно не даёт абсолютно никакой гарантии!)

В Дельфи объем экзешников начал "расти как на дрожжах", огорчая минималистов, из-за включения рефлексии, после которой ВСЕ published-методы уже нельзя было выкидывать — а ну как код вызовет их по имени (сформировав само имя динамически e.g. загрузив из файла конфигурации, которого и В ИСХОДНИКАХ-ТО НЕТ или он там другой)
(А рефлексию при использовании VCL не выключить, т.к. она нужна для построения форм по dfm-метаописаниям в ресурсах. Но можно выключить, если обходиться без VCL. Кстати, .NET WinForms строит формы генерируемым кодом без рефлексии — теоретически можно было бы и VCL переписать в таком ключе. Но у кода формостроения объем больше, чем у метаописаний, так что гарантий выигрыша нет!)