GNU/Linux >> Tutoriales Linux >  >> Linux

Aprendiendo a compilar cosas desde la fuente (en Unix/Linux/OSX)

Solución 1:

Pido disculpas por responder todo directamente, pero no conozco ningún tutorial útil, preguntas frecuentes, etc. Básicamente, lo que sigue son 8 años de hacer aplicaciones de escritorio (que ayudo a distribuir), frustración y búsqueda en Google:

1. ¿Cómo averiguo qué argumentos debo pasar a ./configure?

Practica de verdad. Autotools es bastante fácil ya que es consistente. Pero hay muchas cosas por ahí que usan cmake o scripts de compilación personalizados. En general, no debería tener que pasar nada para configurar, debería averiguar si su sistema puede construir foo-tool o no.

Las herramientas Configure y GNU buscan dependencias en /, /usr y /usr/local. Si instala algo en otro lugar (lo que dificulta las cosas si la dependencia fue instalada por MacPorts o Fink), tendrá que pasar un indicador para configurar o modificar el entorno del shell para ayudar a las herramientas GNU a encontrar estas dependencias.

2. Cómo funcionan las bibliotecas compartidas en OS X/Linux:dónde viven en el sistema de archivos, cómo ./configure &&make las encuentra, qué sucede realmente cuando están vinculadas contra

En Linux, deben instalarse en una ruta que el enlazador dinámico pueda encontrar, esto está definido por el LD_LIBRARY_PATH variable de entorno y el contenido de /etc/ld.conf. En Mac es lo mismo para la mayoría del software de código abierto casi siempre (a menos que sea un Proyecto Xcode). Excepto que la variable env es DYLD_LIBRARY_PATH en su lugar.

Hay una ruta predeterminada en la que el enlazador busca bibliotecas. Es /lib:/usr/lib:/usr/local/lib

Puede complementar esto usando la variable CPATH, o CFLAGS o cualquier número de otras variables de entorno realmente (convenientemente complicado). Sugiero CFLAGS así:

exportar CFLAGS="$CFLAGS -L/nueva/ruta"

El parámetro -L se agrega a la ruta del vínculo.

Las cosas modernas usan la herramienta pkg-config. Las cosas modernas que instala también instalan un archivo .pc que describe la biblioteca y dónde está y cómo vincularla. Esto puede hacer la vida más fácil. Pero no viene con OS X 10.5, así que también tendrás que instalarlo. Además, muchas dependencias básicas no lo admiten.

El acto de vincular es simplemente "resolver esta función en tiempo de ejecución", en realidad es una gran tabla de cadenas.

3. ¿Cuáles son las diferencias reales entre una biblioteca compartida y una enlazada estáticamente? ¿Por qué no puedo vincular todo estáticamente (la memoria RAM y el espacio en disco son baratos en estos días) y, por lo tanto, evitar extraños conflictos de versiones de la biblioteca?

Cuando se vincula a un archivo de biblioteca estática, el código se convierte en parte de su aplicación. Sería como si hubiera un archivo .c gigante para esa biblioteca y lo compilaras en tu aplicación.

Las bibliotecas dinámicas tienen el mismo código, pero cuando se ejecuta la aplicación, el código se carga en la aplicación en tiempo de ejecución (explicación simplificada).

Puede vincular estáticamente a todo, sin embargo, lamentablemente, casi ningún sistema de compilación lo hace fácil. Tendría que editar los archivos del sistema de compilación manualmente (por ejemplo, Makefile.am o CMakeLists.txt). Sin embargo, probablemente valga la pena aprender esto si instala regularmente cosas que requieren diferentes versiones de bibliotecas y le resulta difícil instalar dependencias en paralelo.

El truco es cambiar la línea de enlace de -lfoo a -l/path/to/static/foo.a

Probablemente puedas encontrar y reemplazar. Luego verifique que la herramienta no se vincule a .so o dylib usando ldd foo o otool -L foo

Otro problema es que no todas las bibliotecas se compilan en bibliotecas estáticas. Muchos hacen. Pero entonces MacPorts o Debian pueden haber decidido no enviarlo.

4. ¿Cómo puedo saber qué bibliotecas tengo instaladas y qué versiones?

Si tiene archivos pkg-config para esas bibliotecas, es fácil:

pkg-config --listar-todos

De lo contrario, a menudo no se puede fácilmente. El dylib puede tener un soname (es decir, foo.0.1.dylib, el soname es 0.1) que es el mismo que la versión de la biblioteca. Sin embargo, esto no es requerido. El soname es una característica de computabilidad binaria, tiene que cambiar la mayor parte del soname si cambia el formato de las funciones en la biblioteca. Entonces puedes obtener, por ejemplo. versión 14.0.5 soname para una biblioteca 2.0. Aunque esto no es común.

Me frustré con este tipo de cosas y desarrollé una solución para esto en Mac, y hablaré de eso a continuación.

5. ¿Cómo puedo instalar más de una versión de una biblioteca sin romper mi sistema normal?

Mi solución a esto está aquí:http://github.com/mxcl/homebrew/

Me gusta instalar desde la fuente y quería una herramienta que lo hiciera fácil, pero con algo de administración de paquetes. Entonces, con Homebrew construyo, por ejemplo. obtenerme de la fuente, pero asegúrese de instalarlo con un prefijo especial:

/usr/local/Bodega/wget/1.1.4

Luego uso la herramienta homebrew para vincular todo eso en /usr/local, por lo que todavía tengo /usr/local/bin/wget y /usr/local/lib/libwget.dylib

Más adelante, si necesito una versión diferente de wget, puedo instalarla en paralelo y simplemente cambiar la versión que está vinculada al árbol /usr/local.

6. Si estoy instalando cosas desde la fuente en un sistema que de otro modo se administra mediante paquetes, ¿cuál es la forma más limpia de hacerlo?

Creo que la forma Homebrew es la más limpia, así que úsala o haz lo equivalente. Instale en /usr/local/pkgs/name/version y enlace simbólico o enlace fijo al resto.

Utilice /usr/local. Todas las herramientas de compilación que existen buscan allí dependencias y encabezados. Tu vida será mucho más fácil.

7. Suponiendo que me las arreglo para compilar algo complicado desde la fuente, ¿cómo puedo empaquetarlo para que otras personas no tengan que pasar por los mismos aros? Particularmente en OS X....

Si no tiene dependencias, puede cargar el directorio de compilación y dárselo a otra persona que luego pueda "hacer la instalación". Sin embargo, solo puede hacer esto de manera confiable para las mismas versiones exactas de OS X. En Linux, probablemente funcionará para Linux similar (por ejemplo, Ubuntu) con la misma versión de Kernel y la versión secundaria de libc.

La razón por la que no es fácil distribuir binarios en Unix es por la compatibilidad binaria. La gente de GNU y todos los demás cambian sus interfaces binarias a menudo.

Básicamente, no distribuya binarios. Las cosas probablemente se romperán de maneras muy extrañas.

En Mac, la mejor opción es hacer un paquete macports. Todo el mundo usa macports. En Linux hay tantos sistemas de construcción y combinaciones diferentes, no creo que haya mejor consejo que escribir una entrada de blog sobre cómo lograste construir x herramienta en una configuración extraña.

Si hace una descripción del paquete (para macports o homebrew), cualquiera puede instalar ese paquete y también resuelve los problemas de dependencia. Sin embargo, esto a menudo no es fácil, y tampoco es fácil incluir su receta de macports en el árbol principal de macports. Además, macports no admite tipos de instalación exóticos, ofrecen una opción para todos los paquetes.

Uno de mis objetivos futuros con Homebrew es hacer posible hacer clic en un enlace en un sitio web (por ejemplo, homebrew://blah) y descargará ese script de Ruby, instalará las bases para ese paquete y luego compilará la aplicación. Pero sí, aún no lo he hecho, pero no demasiado complicado teniendo en cuenta el diseño que elegí.

8. ¿Cuáles son las herramientas de línea de comandos que necesito dominar para ser bueno en estas cosas? Cosas como otool, pkg-config, etc.

otool realmente solo es útil después. Le dice a qué se vincula el binario construido. Cuando está averiguando las dependencias de una herramienta que tiene que construir, es inútil. Lo mismo ocurre con pkg-config, ya que habrá instalado la dependencia antes de poder usarla.

Mi cadena de herramientas es leer los archivos README e INSTALL y configurar --help. Mire la salida de la compilación para verificar que esté sana. Analice los errores de compilación. Tal vez en el futuro, pregunte en serverfault :)

Solución 2:

Este es un gran tema, así que comencemos con las bibliotecas compartidas en Linux (ELF en Linux y Mach-O en OS X), Ulrich Drepper tiene una buena introducción a la escritura de DSO (objetos compartidos dinámicos) que cubre parte de la historia de las bibliotecas compartidas en Linux disponibles. aquí incluyendo por qué son importantes

Ulrich también describe por qué los enlaces estáticos se consideran dañinos. Uno de los puntos clave aquí son las actualizaciones de seguridad. Los desbordamientos de búfer en una biblioteca común (p. ej., zlib) que está ampliamente vinculada estáticamente pueden causar una gran sobrecarga para las distribuciones; esto ocurrió con zlib 1.1.3 (aviso de Red Hat)

ELFO

La página del manual del enlazador ld.so

man ld.so 

explica las rutas básicas y los archivos involucrados en la vinculación dinámica en tiempo de ejecución. En los sistemas Linux modernos, verá rutas adicionales agregadas a través de /etc/ld.so.conf.d/ agregadas generalmente a través de una inclusión global en /etc/ld.so.conf.

Si desea ver lo que está disponible dinámicamente a través de su configuración ld.so, puede ejecutar

ldconfig -v -N -X

Leer el instructivo de DSO debería brindarle un buen nivel básico de conocimiento para luego comprender cómo se aplican esos principios a Mach-O en OS X.

Mach-O

En OS X, el formato binario es Mach-O. La documentación del sistema local para el enlazador es

man dyld

La documentación del formato Mach está disponible en Apple

Herramientas de compilación de UNIX

El común configure , make , make install El proceso generalmente lo proporciona GNU autotools, que tiene un libro en línea que cubre parte de la historia de la división de configuración/compilación y la cadena de herramientas de GNU. Autoconf usa pruebas para determinar la disponibilidad de funciones en el sistema de compilación de destino, usa el lenguaje de macros M4 para impulsar esto. Automake es básicamente un método de creación de plantillas para Makefiles, la plantilla generalmente se llama Makefile.am que genera un Makefile.en el que la salida de autoconf (el script de configuración) se convierte en un Makefile.

El programa GNU hello actúa como un buen ejemplo para comprender la cadena de herramientas de GNU, y el manual incluye documentación de herramientas automáticas.

Solución 3:

¡Simón! Se como te sientes; También luché con esta parte de aprender Linux. Basado en mis propias experiencias, escribí un tutorial sobre algunos de los elementos que aborda (¡principalmente como referencia para mí!):http://easyaspy.blogspot.com/2008/12/buildinginstalling-application-from.html. Creo que apreciará mi nota sobre cuán simples son las aplicaciones de Python para construir/instalar. :)

¡Espero que esto ayude! Y feliz compilación.

Tim Jones

Creación/Instalación de una aplicación desde la fuente en Ubuntu Linux

Si bien los repositorios de Ubuntu están repletos de excelentes aplicaciones, en un momento u otro seguramente se encontrará con esa herramienta "imprescindible" que no está en los repositorios (o no tiene un paquete Debian) o necesita un versión más nueva que en los repositorios. ¿A qué te dedicas? Bueno, ¡tienes que construir la aplicación desde la fuente! No te preocupes, en realidad no es tan complicado como parece. ¡Aquí hay algunos consejos, basados ​​en mis experiencias de pasar de ser un aficionado de rango! (Si bien estoy usando Ubuntu para este ejemplo, los conceptos generales deberían ser aplicables a la mayoría de las distribuciones de Unix/Linux, como Fedora e incluso a la plataforma Cygwin en Windows).

El proceso básico de creación (compilación) de la mayoría de las aplicaciones desde el código fuente sigue esta secuencia:configurar --> compilar --> instalar. Los comandos típicos de Unix/Linux para hacer estas cosas son:config --> make --> make install . En algunos casos, incluso encontrará páginas web que muestran que todos estos se pueden combinar en un solo comando:

$ config && make && make install

Por supuesto, este comando asume que no hay problemas en ninguno de estos pasos. ¡Aquí es donde entra la diversión!

Cómo empezar

Si nunca antes ha compilado una aplicación desde el código fuente en su sistema, probablemente necesitará configurarla con algunas herramientas generales de desarrollo, como el gcc paquete de compilación, algunos archivos de encabezado comunes (piense en esto como un código que ya ha sido escrito por otra persona que usa el programa que está instalando) y la herramienta make. Afortunadamente, en Ubuntu existe un metapaquete llamado build-essential que se instalará de esto. Para instalarlo (¡o simplemente asegúrese de que ya lo tiene!), ejecute este comando en la terminal:

$ sudo apt-get install build-essential

Ahora que tiene la configuración básica, descargue los archivos fuente de la aplicación y guárdelos en un directorio para el que tenga permisos de lectura/escritura, como su directorio "inicio". Por lo general, estos estarán en un archivo comprimido con la extensión de archivo de .tar.gz o .tar.bz2 . El .tar simplemente significa que es un "archivo de cinta", que es una agrupación de archivos que conserva su estructura de directorio relativa. El .gz significa gzip (GNU zip), que es un formato de compresión popular de Unix/Linux. Del mismo modo, el .bz2 significa bzip2, que es un formato de compresión más nuevo que proporciona mayor compresión (tamaño de archivo comprimido más pequeño) que gzip.

Una vez que haya descargado el archivo fuente, abra una ventana de terminal (Terminal del sistema en el menú de Ubuntu) y cambie al directorio donde guardó su archivo. (Usaré ~/download en este ejemplo. Aquí, '~' es un acceso directo a su directorio "inicio".) Utilice el comando tar para extraer los archivos del archivo comprimido descargado:

Si su archivo es un archivo gzip (por ejemplo, termina con .tar.gz ), use el comando:

            $ tar -zxvf filename.tar.gz

Si su archivo es un archivo bzip2 (por ejemplo, termina con .tar.bz2 ), use el comando:

            $ tar -jxvf filename.tar.gz

Sugerencia:Si no desea tener que recordar todos los conmutadores de la línea de comandos para extraer archivos, le recomiendo obtener una (o ambas) de estas utilidades:dtrx (¡mi favorita!) o deco (más popular). Con cualquiera de estas utilidades, solo ingresa el nombre de la utilidad (dtrx o deco) y el nombre del archivo, hace todo lo demás. Ambos "saben" cómo manejar la mayoría de los formatos de archivo con los que es probable que se encuentre y tienen un gran manejo de errores.

Al compilar desde el código fuente, es probable que encuentre dos tipos de errores comunes:

  1. Los errores de configuración ocurren cuando ejecuta el script de configuración (generalmente llamado config o configure) para crear un archivo MAKE específico para su configuración.
  2. Los errores del compilador ocurren cuando ejecuta el comando make (después de que se haya generado el archivo MAKE) y el compilador no puede encontrar el código que necesita.

Examinaremos cada uno de estos y discutiremos cómo resolverlos.

Errores de configuración y configuración

Después de haber extraído el archivo de almacenamiento del código fuente, en la terminal, debe cambiar al directorio que contiene los archivos extraídos. Normalmente, este nombre de directorio será el mismo que el nombre del archivo (sin el .tar.gz o .tar.bz2 extensión). Sin embargo, a veces el nombre del directorio es solo el nombre de la aplicación, sin ninguna información de versión.

En el directorio de origen, busque un README archivo y/o un INSTALL archivo (o algo con nombres similares). Estos archivos suelen contener información útil sobre cómo crear/compilar la aplicación e instalarla, incluida información sobre las dependencias. Las "dependencias" son solo un nombre elegante para otros componentes o bibliotecas que se requieren para compilar correctamente.

Después de leer el README y/o INSTALL (y, con suerte, miró cualquier documentación en línea relevante para la aplicación), busque un archivo ejecutable (que tenga el permiso "x" establecido en el archivo) llamado config o configure . A veces, el archivo puede tener una extensión, como .sh (por ejemplo, config.sh ). Suele ser un script de shell que ejecuta otras utilidades para confirmar que tiene un entorno "sano" para compilar. En otras palabras, comprobará que tienes instalado todo lo que necesitas.

Sugerencia:si se trata de una aplicación basada en Python, en lugar de un archivo de configuración, debe encontrar un archivo llamado setup.py Las aplicaciones .Python suelen ser muy sencillas de instalar. Para instalar esta aplicación, como raíz (por ejemplo, coloque sudo delante del siguiente comando en Ubuntu), ejecute este comando:

    $ python setup.py install

Eso debería ser todo lo que necesitas hacer. Puede omitir el resto de este tutorial y continuar directamente con el uso y disfrute de su aplicación.

Ejecute el script de configuración en la terminal. Por lo general, puede (¡y debe!) ejecutar su script de configuración con su cuenta de usuario normal.

$ ./config

El script mostrará algunos mensajes para darle una idea de lo que está haciendo. A menudo, la secuencia de comandos le dará una indicación de si tuvo éxito o falló y, si falló, alguna información sobre la causa de la falla. Si no recibe ningún mensaje de error, por lo general puede suponer que todo salió bien.

Si no encuentra ninguna secuencia de comandos que parezca una secuencia de comandos de configuración, normalmente significa que la aplicación es muy simple y es independiente de la plataforma. Esto significa que simplemente puede saltar al paso de construcción/compilación a continuación, porque el Makefile proporcionado debería funcionar en cualquier sistema.

Un ejemplo

En este tutorial, usaré el lector de RSS basado en texto llamado Newsbeuter como ejemplo de los tipos de errores que puede encontrar al crear su aplicación. Para Newsbeuter, el nombre del script de configuración es config.sh . En mi sistema, cuando ejecuto config.sh , ocurren los siguientes errores:

[email protected]:~/download/newsbeuter-1.3$ ./config.sh
Checking for package sqlite3... not found

You need package sqlite3 in order to compile this program.
Please make sure it is installed.

Tras investigar un poco, descubrí que, de hecho, el sqlite3 se instaló la aplicación. Sin embargo, dado que estoy tratando de compilar desde el código fuente, este es un consejo de lo que config.sh lo que realmente está buscando son las bibliotecas de desarrollo (encabezados) para sqlite3 . En Ubuntu, la mayoría de los paquetes tienen un paquete homólogo de desarrollo asociado que termina en -dev . (Otras plataformas, como Fedora, a menudo usan un sufijo de paquete de -devel para los paquetes de desarrollo).

Para encontrar el paquete apropiado para el sqlite3 paquete de desarrollo, podemos usar el apt-cache utilidad en Ubuntu (y, de manera similar, el yum utilidad en Fedora):

[email protected]:~/download/newsbeuter-1.3$ sudo apt-cache search sqlite

Este comando devuelve una lista bastante grande de resultados, por lo que tenemos que hacer un poco de trabajo de detección para determinar cuál es el paquete apropiado. En este caso, el paquete apropiado resulta ser libsqlite3-dev . Note que a veces el paquete que estamos buscando tendrá el lib prefijo, en lugar del mismo nombre de paquete más -dev . Esto se debe a que a veces solo buscamos una biblioteca compartida que pueda ser utilizada por muchas aplicaciones diferentes. Para instalar libsqlite3-dev , ejecuta el típico comando apt-get install en la terminal:

[email protected]:~/download/newsbeuter-1.3$ sudo apt-get install libsqlite3-dev

Ahora, tenemos que ejecutar config.sh de nuevo para asegurarnos de que hemos resuelto este problema de dependencia y que no tenemos más problemas de dependencia. (Si bien no lo mostraré aquí, en el caso de Newsbeuter, también tuve que instalar el libcurl4-openssl-dev paquete, también). Además, si instala un paquete de desarrollo (como libsqlite3-dev ) y el paquete de aplicación asociado (por ejemplo, sqlite3 ) aún no está instalado, la mayoría de los sistemas instalarán automáticamente el paquete de aplicación asociado al mismo tiempo.

Cuando la configuración se ejecute correctamente, el resultado será que creará uno o más archivos make. Estos archivos normalmente se denominan Makefile (¡recuerde que las mayúsculas y minúsculas del nombre de archivo son importantes en Unix/Linux!). Si el paquete de compilación incluye subdirectorios, como src , etc., cada uno de estos subdirectorios contendrá un Makefile , también.

Errores de creación y compilación

Ahora, estamos listos para compilar la aplicación. Esto a menudo se denomina construcción y el nombre se toma prestado del proceso del mundo real de construir algo. Las diversas "piezas" de la aplicación, que suelen ser varios archivos de código fuente, se combinan para formar la aplicación general. La utilidad make administra el proceso de compilación y llama a otras aplicaciones, como el compilador y el enlazador, para que realmente hagan el trabajo. En la mayoría de los casos, simplemente ejecuta make (con su cuenta de usuario habitual) desde el directorio donde ejecutó la configuración. (En algunos casos, como compilar aplicaciones escritas con la biblioteca Qt, deberá ejecutar otra aplicación "envoltura" como qmake en su lugar. Nuevamente, siempre verifique el README y/o INSTALL documentos para más detalles).

Al igual que con el script de configuración anterior, cuando ejecuta make (o una utilidad similar) en la terminal, mostrará algunos mensajes sobre lo que se está ejecutando y cualquier advertencia y error. Por lo general, puede ignorar las advertencias, ya que son principalmente para los desarrolladores de la aplicación y les dicen que hay algunas prácticas estándar que se están violando. Por lo general, estas advertencias no afectan la función de la aplicación. Por otro lado, se deben tratar los errores del compilador. Con Newsbeuter, cuando ejecuté make, las cosas fueron bien durante un tiempo, pero luego recibí un error:

[email protected]:~/download/newsbeuter-1.3$ make
...
c++ -ggdb -I/sw/include -I./include -I./stfl -I./filter -I. -I./xmlrss -Wall -Wextra -DLOCALEDIR=\"/usr/local/share/locale\" -o src/configparser.o -c src/configparser.cpp
c++ -ggdb -I/sw/include -I./include -I./stfl -I./filter -I. -I./xmlrss -Wall -Wextra -DLOCALEDIR=\"/usr/local/share/locale\" -o src/colormanager.o -c src/colormanager.cpp
In file included from ./include/pb_view.h:5,
from src/colormanager.cpp:4:
./include/stflpp.h:5:18: error: stfl.h: No such file or directory
In file included from ./include/pb_view.h:5,
from src/colormanager.cpp:4:
./include/stflpp.h:33: error: ISO C++ forbids declaration of \u2018stfl_form\u2019 with no type
./include/stflpp.h:33: error: expected \u2018;\u2019 before \u2018*\u2019 token
./include/stflpp.h:34: error: ISO C++ forbids declaration of \u2018stfl_ipool\u2019 with no type
./include/stflpp.h:34: error: expected \u2018;\u2019 before \u2018*\u2019 token
make: *** [src/colormanager.o] Error 1

El proceso de creación se detendrá tan pronto como se encuentre el primer error. El manejo de los errores del compilador a veces puede ser un asunto complicado. Tienes que mirar los errores para encontrar algunas pistas sobre el problema. Por lo general, el problema es que algunos archivos de encabezado, que generalmente tienen una extensión de .h o .hpp , están perdidos. En el caso del error anterior, está (¡o debería estar!) claro que el problema es que stfl.h No se puede encontrar el archivo de encabezado. Como muestra este ejemplo, desea mirar las primeras líneas del mensaje de error y avanzar hasta encontrar la causa subyacente del problema.

Después de mirar la documentación de Newsbeuter (que debería haber hecho antes de comenzar, ¡pero esta parte del tutorial no sería muy significativa!), Descubrí que requiere una biblioteca de terceros llamada STFL. Entonces, ¿qué hacemos en este caso? Bueno, esencialmente repetimos exactamente el mismo proceso para la biblioteca requerida:obtenga la biblioteca y ejecute el proceso de configuración, compilación e instalación para ella y, luego, reanude la compilación de la aplicación deseada. Por ejemplo, en el caso de STFL, tuve que instalar el libncursesw5-dev paquete para que se construya correctamente. (Por lo general, no es necesario volver a realizar el paso de configuración en nuestra aplicación original después de instalar otra aplicación requerida, pero tampoco está de más).

Después de instalar con éxito el kit de herramientas STFL, el proceso de creación de Newsbeuter se ejecutó correctamente. El proceso de creación generalmente continúa donde lo deja (en el punto del error). Por lo tanto, no se volverán a compilar los archivos que ya se hayan compilado correctamente. Si desea volver a compilar todo, puede ejecutar make clean all para eliminar cualquier objeto compilado y luego ejecutar make nuevamente.

Instalando

Una vez que el proceso de compilación se completa con éxito, está listo para instalar la aplicación. En la mayoría de los casos, para instalar la aplicación en las áreas comunes del sistema de archivos (por ejemplo, /usr/bin o /usr/share/bin , etc.), deberá ejecutar la instalación como root. La instalación es realmente el paso más simple de todo el proceso. Para instalar, en la terminal ejecuta:

$ make install

Verifique la salida de este proceso para ver si hay errores. Si todo fue exitoso, debería poder ejecutar el nombre del comando en la terminal y se iniciará. (Agregue &al final de la línea de comando, si es una aplicación GUI, o no podrá usar la sesión de terminal hasta que la aplicación termine de ejecutarse).

Cuando crea una aplicación desde la fuente, normalmente no agregará un icono o un acceso directo a los menús de la GUI en Ubuntu. Deberá agregar esto manualmente.

Y ese es básicamente el proceso, aunque potencialmente iterativo, para construir e instalar una aplicación desde la fuente en Ubuntu. ¡Después de haber hecho esto unas pocas veces, se convertirá en una segunda naturaleza para ti!

Solución 4:

Bueno, ./configure --help le dará mucha información, para los archivos de configuración generados por GNU autotools. La mayor parte se reduce a --con/--sin para habilitar funciones (estas pueden tomar un parámetro adicional, como "compartido" para decir dónde encontrar la biblioteca).

Otros importantes son --prefix (que por defecto es /usr/local/ la mayor parte del tiempo) para decir dónde instalar (si está creando paquetes, por lo general lo desea como --prefix=/usr o quizás --prefix =/opt/SuPaquete).

En Linux, /lib, /usr/lib y /usr/local/lib generalmente se buscan en mi gcc y se incluyen en la configuración predeterminada de ldconfig. A menos que tenga una buena razón, aquí es donde quiere sus bibliotecas. Sin embargo, /etc/ld.so.conf puede enumerar entradas adicionales.

configure y haga que los encuentre simplemente intentando ejecutar "gcc -l" y viendo si falla. Puede agregar "-L" a su parámetro CFLAGS para agregar rutas adicionales para buscar.

Puede tener varias versiones instaladas, y el software vinculado a una versión anterior permanecerá vinculado a ella (ejecute ldd para averiguar el enlace en Linux), pero las compilaciones nuevas generalmente apuntan a la última versión de una biblioteca dinámica en su sistema.

La mayoría del software asume bibliotecas dinámicas, especialmente si usa libtool, por lo que es posible que las aplicaciones no triviales no se construyan correctamente de forma estática.

ls -l es su mejor apuesta para encontrar bibliotecas instaladas.

Y ahí es donde me quedo sin información; cómo jugar bien con paquetes:no lo sé. Cuando es posible, trato de envolver las cosas en un paquete para evitar el problema.

Solución 5:

Para responder un poco a su pregunta, encontré una buena manera el otro día para ver qué bibliotecas ha instalado y las versiones (esto es en Linux Debian, por lo que también debería funcionar con otras versiones).

dpkg --list

Debería obtener una lista realmente larga con un resultado como este

ii  libssl0.9.8    0.9.8c-4etch5  SSL shared libraries
ii  libssp0        4.1.1-21       GCC stack smashing protection library
ii  libstdc++5     3.3.6-15       The GNU Standard C++ Library v3
ii  libstdc++5-3.3 3.3.6-15       The GNU Standard C++ Library v3 (development
ii  libstdc++6     4.1.1-21       The GNU Standard C++ Library v3

Linux
  1. Guía de instrucciones para instalar PHP5 desde la fuente en Linux

  2. Instale Apache 2 desde la fuente en Linux

  3. Cómo compilar e instalar software desde el código fuente en Linux

  4. ¿Es posible compilar una distribución de Darwin desde la fuente, como se puede compilar una distribución de Linux?

  5. ¿Cuál es la fuente de la mentalidad de compilarlo usted mismo en Linux?

Cómo instalar un programa desde la fuente en Linux

Conceptos básicos de la compilación de software a partir del código fuente en Linux

Cómo instalar software desde la fuente en Linux

Cómo compilar PHP7.0/PHP7.1 desde la fuente en Arch Linux

Linux frente a Unix

Cómo compilar el kernel de Linux desde el origen para crear un kernel personalizado