Я планирую скомпилировать статическую библиотеку (mylib.a) с помощью gcc 4.7.1. Я хочу воспользоваться преимуществами C ++ 11, поэтому используется -std = c ++ 11. Платформа, на которой я компилирую эту библиотеку — x86_64 SLES 11 с glibc-2.8.
Затем я хочу связать эту статическую библиотеку на устаревшей платформе с унаследованным кодом, поэтому я должен использовать gcc 4.1.2 для компоновки и компиляции унаследованного кода. Поэтому в заголовках моей библиотеки я не буду использовать какой-либо специфический для C ++ 11 код. Также я буду ссылаться на libstdc ++. A из gcc.4.7.1. Платформа, на которой я хочу связать mylib.a, libstdc ++. A (gcc4.7.1) и устаревшие объектные файлы, — это x86_64 SLES 10 с glibc-2.4.
Я перепробовал весь этот беспорядок с каким-то фиктивным кодом C ++ 11 (std :: async ()) в mylib.a, и это сработало. Я думаю, что это возможно только из-за требований ELF. Я правильно думаю, или ELF не имеет к этому никакого отношения? Каких ошибок мне следует ожидать, если mylib.a будет содержать действительно сложную логику?
Linux имеет двоичный интерфейс приложений C ++ (ABI), который был вокруг некоторое время. Это означает, что соглашения о вызовах и распределение имен между компиляторами в Linux исправлены. Поэтому, пока библиотеки совместимы, вы должны иметь возможность компиляции с разными компиляторами (или разными версиями одного и того же компилятора) и иметь код, который корректно и надежно связывает воедино.
Не совсем требования ELF как таковой…
GCC гарантирует бинарную совместимость вплоть до некоторой древней версии 3. Пока libstdc ++, на который вы ссылаетесь, имеет новые библиотечные функции, нет никаких причин, по которым вы не можете их использовать. Вам просто нужно держаться подальше от новых функций языка и библиотеки в коде, скомпилированном с GCC 4.1.2.