> ldd. Что показывает, то и сообщаю.

А как gcc5 может не линковаться к libc6? oO Это статическая сборка чтоли была? Ну тогда солидный шмат libc6 залинковали прямо в бинарь.

> На gcc5 lame не просил, а на gcc8 тот же lame попросил?

А кто б его знает чем там параметры командлайна компилеру отличались и что за сборка была, статичная и динамичная. Не помню как lame это делает по дефолту, давно билдил. Ща он мне как-то не интересен: сколько mp3 не дрючь, а opus сильно лучше по bitrate-quality. Ну и зачем мне mp3? :)

> ./configure полностью идентичны были.

А там по дефолту статическая или динамическая сборка?

> Там (в lame) больше зависит от ассемблеровских оптимизаций nasm'ом, имхо. Он может
> собираться и без них, но рекомендуется с ними. Ну и оптимизации под процессор, SSE2.

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

>> урезать добрую четверть бинаря НИЧЕГО НЕ ПОТЕРЯВ взамен
> Есть strip, о котором недавно узнал.

Это совершенно ортогональная штука - удаляет дебагинфо и тому подобное. А вон в том случае сдуваются именно код и данные, gcc гоняет некий глобальный анализ всего бинаря и делает довольно веселые глобальные оптимизации, мержа константы и код где это катит. Оно не быстро и RAM жрет но и результат по своему прикольный - минус четверть бинаря без каких либо потуг со стороны програмера и без потерь в чем либо все же выглядит достаточно интересно в ряде случаев.