Actualmente estoy trabajando en la actualización del sistema de compilación para una gran cantidad de código, que incluye un proyecto de Linux C++. Sería bueno si todos los desarrolladores de aquí pudieran ejecutar una compilación cuando hackean sus propias ideas, por lo que estaba examinando si sería posible construir esto en sistemas Linux vagamente modernos a pesar de que el sistema objetivo sea 2.6.18.GCC/G ++: creación sin símbolos de objetos únicos de GNU para kernels de Linux anteriores
Por 'vagamente moderno' Estoy estimando algo así como GCC 4.5+, algo que una distribución en el último año o dos podría venir con. Actualmente resuelvo el problema libstdC++ compilándolo en forma estática, y cualquier problema glibc se soluciona limpiamente reasignando a las versiones antiguas de los símbolos memcpy (y así sucesivamente) con un poco de código de contenedor. Hasta aquí todo bien.
El único problema que no puedo entender por completo es que ciertos símbolos integrados en el ejecutable de los archivos .o son del tipo 'u', que es un objeto único de GNU, una extensión del estándar ELF que 2.6.18 no parece reconocer en absoluto. Esto significa que el ejecutable no se ejecutará porque no puede encontrar los símbolos, aunque en realidad están presentes (solo del tipo '?' En el objetivo, desde 'nm').
Uno puede deshabilitar el uso de objetos únicos de GNU al compilar G ++, pero no es exactamente la solución más conveniente. No veo ninguna forma de desactivarlo cuando compilo el código (distro gcc/g ++ invariablemente tiene esta opción), y me imagino que la única manera de que el sistema objetivo lo reconozca sería actualizar ld-linux y kernel . Eso es casi seguro que no va a suceder.
¿Existe alguna opción que no haya encontrado para desactivar estos tipos de símbolos? ¿O tal vez hay alguna manera ordenada de evitar esto o algo que me falta? Estoy empezando a sospechar que solo tendrá que compilarse en G ++ 4.1.x, lo que significará una instalación anterior de Linux o compilación desde la fuente.
si se trata de un tipo de símbolo de vinculación dinámica, entonces debería haber un problema con el vinculador dinámico, no con el kernel. ¿Cómo se relaciona esto con el kernel? – Hibou57
Si bien no lo he probado, creo que cambiar el libld sin cambiar el kernel va a ser bastante difícil, si es posible. Por lo tanto, no está directamente relacionado con el kernel, sino más bien con el hecho de que tendría que recompilar ese kernel o simplemente actualizar todo el sistema operativo para que el enlazador reconozca estos otros símbolos, según tengo entendido. – rhickman