Si enlace estáticamente un ejecutable en ubuntu, ¿hay alguna posibilidad de que ese ejecutable no funcione en otra distribución como mint os? o fedora? Sé que los tipos de procesadores se ven afectados, pero aparte de eso, ¿hay algo más de lo que tenga que preocuparme? Lo siento si esta es una pregunta tonta. Gracias por cualquier ayuda¿Funcionará la vinculación estática en una distribución de Unix pero no en otra?
Si vincula estáticamente un programa en una computadora y luego lo mueve a otra computadora en la que el sistema funciona básicamente de la misma manera, entonces debería funcionar bien. Ese es el punto de la vinculación estática; que no hay otros archivos en los que el programa dependa, es completamente autónomo, de modo que, siempre que se ejecute, se ejecutará de la misma manera que en su sistema "host".
Esto contrasta con la vinculación dinámica, en la que el programa incorpora elementos de otros archivos (bibliotecas) en tiempo de ejecución. Si mueve un programa vinculado dinámicamente a otro sistema donde las bibliotecas de las que depende son diferentes (o inexistentes), no funcionará.
Esta es la respuesta incorrecta, especialmente en Linux. Si esta respuesta "gana", entonces stackoverflow no tiene sentido :-( –
-1: Hay más que arquitectura de computadora en juego. –
Me equivoqué al escribir "arquitectura" tenía en mente algo más que arquitectura de chips. Lo reformulé para hacerlo un poco mejor. –
En la mayoría de los casos, su ejecutable funcionará perfectamente. Siempre que su ejecutable no dependa de que algo inusual esté presente para que funcione, no habrá ningún problema. (Y, si depende de que algo inusual esté presente, entonces tendrá el mismo problema incluso si vincula dinámicamente.)
El enlace estático es generalmente más seguro que el enlace dinámico para la compatibilidad entre diferentes entornos UNIX, siempre y cuando la misma CPU está en uso.
Para tener un error binario enlazado estáticamente, asumiendo nuevamente la misma arquitectura de procesador, tendría que hacer algo como un enlace en un sistema utilizando el formato binario a.out e intentar ejecutarlo en un sistema que ejecute ELF, en En ese caso, la versión enlazada dinámicamente fallaría igual de mal.
Entonces, ¿por qué las personas no vinculan sistemáticamente estáticamente? Dos razones:
Hay algunos casos de esquina, pero en su mayor parte, debe estar en buen estado con enlaces estáticos. El que viene a la mente es libnss. Esta biblioteca en particular es esencialmente imposible de vincular estáticamente, debido a la forma en que hace su trabajo (permisos, autenticación, tareas de seguridad). Mientras que las versiones de glibc sean similares, sin embargo, deberías estar bien en este tema.
Si su programa necesita trabajar con funciones sutiles del kernel, como los administradores de volúmenes, tiene muy pocas posibilidades de que su programa funcione, estáticamente vinculado, en todas las distribuciones, porque las interfaces del kernel pueden cambiar ligeramente.
La mayoría de las aplicaciones típicas, del tipo que tiene sentido discutir sobre la portabilidad, como servicios de red, aplicaciones de interfaz gráfica de usuario, herramientas de lenguaje (como compiladores/intérpretes) no tendrán problemas con esto.
Los glibc más nuevos le avisarán si enlaza estáticamente cualquiera de las funciones "problemáticas". Para encontrar la lista completa, puede hacer "stings -ausr/lib/libc.a | grep" en forma estática aplicaciones vinculadas '. Esto me da 73 funciones en Fedora 9. NO ignore esta advertencia, o se bloqueará y quemará. –
Por el contrario. Sean cuales sean las posibilidades de que funcione un binario en distribuciones o incluso sistemas operativos, esas posibilidades se maximizan mediante enlaces estáticos. El enlace estático hace que un ejecutable sea autónomo en términos de bibliotecas. Todavía puede salir mal si intenta leer un archivo que no está allí en otro sistema.
Para incluso mejores posibilidades de portabilidad, intente vincular con dielibc o alguna otra libc. An article at Linux Journal menciona algunos candidatos. Es menos probable que una libc más pequeña y simple dependa de elementos en el sistema de archivos que difieran de la distribución a la distribución.
+1 para señalar que usar una libc más pequeña es a menudo una buena opción. Particularmente si usa una Muchas instalaciones, ya que glibc es bastante grande, obtendrás enormes binarios. –
Me gustaría, por las razones mencionadas anteriormente, evitar el enlace estático de algo a menos que absolutamente debe.
Dicho esto, debería funcionar en cualquier otro kernel similar de la misma arquitectura (es decir, si vincula estáticamente en una máquina que ejecuta Linux 2.4.x, el cargador VDSO será diferente en Linux 2.6, siendo VDSO virtual objeto compartido dinámico, un objeto compartido que el kernel expone a cada proceso que contiene código de cargador).
Otros peligros incluyen cosas en/etc no estar donde se podría pensar, los registros de estar en diferentes lugares, utilidades del sistema ausencia o diferente (Ubuntu usa update-rc.d, RHEL usa chkconfig), etc.
A veces, simplemente no tiene otra opción. Estaba escribiendo un programa que hablaba con la interfaz cmdlib basada en cadenas de LVM2 a favor de usar execv() .. bajo y he aquí, el 30% de las distribuciones que necesitaba para soportar NO incluía esa biblioteca y no ofrecía ninguna forma de obtenerla. Entonces, tuve que vincularme con el objeto estático cuando producía paquetes binarios.
Si está utilizando glibc, puede estar seguro de que cosas como getpwnam() y amigos seguirán funcionando .. sólo asegúrese de ver cualquier ruta no modificables (mejor aún, que sean configurables en tiempo de ejecución)
Mientras pueda garantizar que solo se ejecutará en una versión similar del SO en hardware similar, su programa funcionará correctamente si está enlazado estáticamente. por lo tanto, si compila para un 2.6 Linux y enlaza estáticamente, estará en condiciones de ejecutar (casi) todas las 2.6 distribuciones de Linux.
Tenga en cuenta que no puede vincular estáticamente algunas partes de GLIBC, por lo que si las usa tendrá que vincular dinámicamente de todos modos. Desde la memoria, las partes de los elementos de servicio de nombres (nss) requerían enlaces dinámicos cuando lo estaba investigando.
No se puede vincular estáticamente un programa para (por ejemplo) Linux y luego esperar que se ejecute en BSD o Windows. BSD y Unix no presentan ni manejan sus llamadas al sistema de la misma forma que lo hace Linux. Digo una pequeña mentira porque los BSD tienen una capa de emulación de Linux que se puede habilitar, pero de fábrica no funcionará.
No, no funcionará. La vinculación estática para la independencia de la distribución es un concepto de las antiguas edades de Unix y no se recomienda. Por el hecho de que no puede tantas bibliotecas no están disponibles como bibliotecas estáticas de todos modos.
Siga el camino de la Base estándar de Linux, esta es su única oportunidad de obtener la mayor portabilidad de distribución cruzada posible.
El LSB también funciona bien si programa FreeBSD y Solaris.
Hay dos preguntas de compatibilidad en cuestión aquí: versiones de la biblioteca e inventario de la biblioteca.
No dice qué bibliotecas está utilizando.
Si no tiene opciones '-l', entonces la única 'biblioteca' es glibc, que sirve como interfaz para el kernel. Las versiones Glibc son compatibles hacia arriba. Si enlaza en un sistema glibc 2.x puede ejecutar en un glibc 2.y, para y> x. Los desarrolladores se comprometen firmemente con esto.
Si tiene opciones -l, la vinculación estática siempre es segura. Si está vinculado dinámicamente, debe asegurarse de que (1) la biblioteca esté presente en el sistema de destino y (2) tenga una versión compatible. Su Kilometraje podría variar en cuanto a si la distribución objetivo tiene lo que necesita.
Buena pregunta. Algo en lo que pensé hoy. – TheHippo
Por "unix", ¿está seguro de que no quiso decir "linux"? – bk1e