c++ - tutorial - framework django python
¿Riesgos de diferentes versiones de GCC en el enlace/tiempo de ejecución? (1)
Estoy usando el compilador C ++ de Intel, que en Linux se basa en libc.so y libstdc ++ suministrados por GNU.
Aquí está mi problema. Para tener acceso a algunas de las funciones más nuevas de C ++ 11, necesito usar libstdc ++ que se envía con GCC 4.7 o superior. Pero estoy atascado usando CentOS 6.4.
En CentOS 6.4, la versión nativa de GCC es 4.4. Pero al usar una cosa de RedHat llamada "SCL" y un paquete llamado "devtoolset-1.1", puedo instalar GCC 4.7 en "/ opt".
Configuré las cosas para usar GCC 4.7 de la manera mencionada anteriormente, puedo usar las funciones más nuevas de C ++ 11.
Entonces, aquí está mi pregunta: si un usuario ejecuta mi programa solo con las versiones GCC 4.4 de libc.so / libstdc ++. En la ruta de la biblioteca, existe el riesgo de que mi programa tenga errores debido a una discrepancia entre las versiones 4.4 y 4.7. de esas bibliotecas?
Si hay un problema potencial, ¿puedo solucionarlo mediante la vinculación estática en las versiones de libc y libstdc ++ de GCC 4.7? ¿O es que me estoy preparando para otros problemas si / cuando otras bibliotecas que carga dinámicamente mi código recogen el libc / libstdc ++ más antiguo suministrado por el paquete GCC 4.4 de todo el sistema?
Como Praetorian señaló en los comentarios a continuación, el uso de devtoolset realmente resuelve el problema que originalmente describí en esta respuesta. He corregido la respuesta.
¿Existe el riesgo de que mi programa tenga errores debido a una falta de coincidencia entre las versiones 4.4 y 4.7 de esas bibliotecas?
Sí. La vinculación con una versión más reciente de libstdc ++. Por lo tanto, y luego tratar de ejecutarse en contra de una versión anterior, no es compatible al 100%. Si cualquier objeto en su programa o las bibliotecas que utiliza se compila con GCC 4.7 y se vincula a libstdc ++. Por lo tanto, a partir de 4.7 , debe usar libstdc ++. A partir de 4.7 (o más reciente) en tiempo de ejecución. Probablemente ni siquiera se ejecute, pero si lo hace, puede haber errores silenciosos debido a incompatibilidades. Pero eso no es un problema en su caso, porque no está enlazando con libstdc ++ de GCC 4.7. Por lo tanto, vea más abajo.
¿Puedo solucionarlo enlazando estáticamente en las versiones de libc y libstdc ++ de GCC 4.7?
1) Solo necesitarías hacer eso para libstdc ++, porque no existe tal cosa como la "versión de libc de GCC 4.7". Glibc es un proyecto completamente separado de GCC. Cuando está utilizando GCC 4.7 no está usando una libc diferente, todavía está usando la libc del sistema de CentOS 6.4. (Dejando de lado, tenga en cuenta que la vinculación estática de glibc es fuertemente desaconsejada por los mantenedores de glibc, y algunas características de glibc no funcionarán cuando esté enlazada estáticamente).
2) La vinculación estática de libstdc ++ solucionaría el problema, pero no es necesario, porque eso es lo que Red Hat Developer Toolset (devtoolset) hace por usted de todos modos. El punto central de devtoolset es que le permite usar un GCC más reciente y un libstdc ++ más nuevo, pero sin crear dependencias en tiempo de ejecución en la biblioteca libstdc ++ más nueva. Los ejecutables compilados solo necesitan la versión del sistema de libstdc ++. Por lo tanto, siempre está presente en RHEL / CentOS, incluso en sistemas sin el conjunto de componentes instalado. (Lo que hace devtoolset es empaquetar todas las nuevas características de libstdc ++ en una biblioteca estática, llamada libstdc++_nonshared.a para que todas las piezas no libstdc++_nonshared.a presentes en el sistema libstdc ++. Así que se vincula estáticamente, y todo lo demás vendrá del sistema libstdc ++ .asi que).
Si no estuviera usando devtoolset, entonces otra opción en lugar de vincular estáticamente libstdc ++ sería enviar la versión más nueva de libstdc ++. Así que asegúrese de que se encuentre primero (por ejemplo, vinculando su código con un RPATH que haga referencia a la versión más reciente de libstdc ++. ). Pero con devtoolset eso no es necesario.
¿O es que me estoy preparando para otros problemas si / cuando otras bibliotecas que carga dinámicamente mi código recogen el libc / libstdc ++ más antiguo suministrado por el paquete GCC 4.4 de todo el sistema?
No habrá tales problemas cuando use devtoolset, porque siempre está usando libstdc ++ más antiguo, por lo que nunca hay un conflicto.