La compilación del código en un archivo de objeto debe realizarse independientemente de la posición si el archivo está destinado a ser cargado como biblioteca compartida (.so), porque la dirección virtual base en la que se carga el archivo de objeto compartido en diferentes procesos puede ser diferente.¿El código de 32 bits x86 debe compilarse especialmente en PIC para los archivos de bibliotecas compartidas?
Ahora no encontré errores cuando intenté cargar un archivo .so compilado y enlazado sin la opción -fpic GCC en equipos 32bit x86, mientras falla en equipos bit 64 bit x86.
sitios web al azar que he encontrado dicen que no necesito -fpic de 32 bits ya que el código compilado sin -fpic obras de coincidencia de acuerdo con el X86 de 32 bits ABI también cuando se utiliza de una manera independiente de la posición. Pero aún encontré un software que incluye versiones separadas de bibliotecas en sus versiones de 32 bits: una para PIC y otra para no PIC. Por ejemplo, el compilador de inteligencia se envía con libirc.a y libirc_pic.a, este último se compila para el modo de posición independiente (si se quiere vincular ese archivo .a en un archivo).
Me pregunto cuál es la diferencia exacta entre usar -fpic y no utilizarlo para el código de 32 bits, y por qué algunos paquetes, como el compilador de inteligencia, todavía se entregan con versiones separadas de bibliotecas?
¿Intentó la compilación de código no-fp usando TLS? ¿O cargar varias librerías que no sean pic con rangos de memoria superpuestos? Las librerías estáticas separadas son para enlazar los programas estáticamente (libirc.a; no pic es un poco más rápido) y en las bibliotecas .so estáticamente (_pic.a versión). – osgx
Consulte http://stackoverflow.com/questions/3146744/difference-in-position-independent-code-x86-vs-x86-64 – AProgrammer