Когда вы строите свой код, вы можете выбрать, чтобы построить его положение в зависимости или положение независимо , это не имеет никакого отношения к статической сборке (хотя вы не можете построить независимую позицию статический бинарный). Позиционно-зависимые двоичные файлы (с учетом одинаковых исходных кодов, флагов компилятора и сборки) всегда будут генерировать одинаковые адреса, но, как я скажу ниже, я не буду полагаться на них в выпуске.
Это обеспечивается опциями GCC -fPIE (позиционно-независимый исполняемый файл), -fPIC (позиционно-независимый код), * 1009 *. Исполняемые файлы ELF могут быть скомпонованы как позиция зависимая или независимая , но общие объекты (библиотеки) будут всегда создаваться как позиция независимая как Вы должны иметь возможность загружать их в случайном месте, предоставленном вам ОС. Со страницы MAN в GCC:
-fPIC
If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the global offset table.
-fpie
-fPIE
These options are similar to -fpic and -fPIC, but generated position independent code can be only linked into executables. Usually these options are used when -pie GCC option will be used during linking.
-pie
Produce a position independent executable on targets which support it. For predictable results, you must also specify the same set of options that were used to generate code (-fpie, -fPIE, or model suboptions) when you specify this option.
При загрузке общего объекта PIC вы не можете предполагать, что он будет находиться в одном и том же месте при каждом запуске, поскольку на него может влиять ASLR, управляемый ядром.
В любом случае, я не считаю хорошей практикой использовать адреса памяти в качестве uuids для классов, поскольку они могут измениться, даже в большей степени, если эти классы шаблонов реализованы как часть общего объекта.