Saltar al contenido

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

Buscamos en diferentes foros y así tener para ti la respuesta para tu duda, si tienes alguna duda deja tu pregunta y te contestaremos con mucho gusto, porque estamos para ayudarte.

Solución:

Solución 1:

Me disculpo por responder todo directamente, pero no conozco tutoriales útiles, 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 realmente. Autotools es bastante fácil ya que es consistente. Pero hay muchas cosas que usan cmake o scripts de compilación personalizados. Generalmente, 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 cualquier otro lugar (lo que hace que las cosas sean dolorosas si la dependencia fue instalada por MacPorts o Fink), tendrá que pasar una bandera 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, casi siempre ocurre lo mismo con la mayoría del software de código abierto (a menos que sea un proyecto de Xcode). Excepto que la variable env es DYLD_LIBRARY_PATH en lugar de.

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

Puede complementar esto usando la variable CPATH, o CFLAGS o cualquier otra variable de entorno realmente (convenientemente complicada). Sugiero CFLAGS así:

exportar CFLAGS = “$ CFLAGS -L / nuevo / ruta”

El parámetro -L se agrega a la ruta del enlace.

Las cosas modernas usan la herramienta pkg-config. Las cosas modernas que instalas 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 tendrás que instalarlo también. Además, muchos departamentos básicos no lo admiten.

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

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

Cuando se vincula a un archivo de biblioteca estático, 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 consiste en cambiar la línea de enlace de -lfoo a -l / ruta / a / static / foo.a

Probablemente pueda 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 –list-all

De lo contrario, a menudo no es fácil. 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, tienes que resaltar la mayor parte del soname si cambias el formato de las funciones en la biblioteca. Entonces puedes conseguir, por ejemplo. soname versión 14.0.5 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 lo hablaré 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. wget yo mismo de la fuente, pero asegúrese de instalar con un prefijo especial:

/usr/local/Cellar/wget/1.1.4

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

Más tarde, si necesito una versión diferente de wget, puedo instalarlo 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 otra manera 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 el equivalente. Instale en / usr / local / pkgs / name / version y enlace simbólico o enlace duro al resto en.

Utilice / usr / local. Cada herramienta de compilación que existe busca allí dependencias y encabezados. Tu vida sera mucho más fácil.

7. Suponiendo que me las arregle 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 pueda hacer “make install”. 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 menor de libc.

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

Básicamente, no distribuyas binarios. Es probable que las cosas se rompan de formas muy extrañas.

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

Si crea una descripción de 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á los departamentos para ese paquete y luego creará la aplicación. Pero sí, aún no está hecho, pero no es 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ás averiguando las dependencias de una herramienta que tienes que construir, es inútil. Lo mismo ocurre con pkg-config, ya que ya habrá instalado la dependencia antes de poder usarla.

Mi cadena de herramientas es, lea los archivos README e INSTALL, y haga un configure –help. Mire el resultado de la compilación para verificar que esté sano. Analice los errores de compilación. Tal vez en el futuro, pregunte en serverfault 🙂

Solucion 2:

Este es un tema enorme, 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 del historial de 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 (por ejemplo, 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)

DUENDE

La página de manual del linker ld.so

man ld.so 

explica las rutas y archivos básicos 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 de ld.so, puede ejecutar

ldconfig -v -N -X

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

Macho

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

Lo 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 GNU. Autoconf utiliza pruebas para determinar la disponibilidad de funciones en el sistema de compilación de destino, utiliza 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.in que la salida de autoconf (el script de configuración) se convierte en un Makefile.

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


Solución 3:

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

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

Tim Jones


Construyendo / Instalando una aplicación desde la fuente en Ubuntu Linux

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

El proceso básico de construcción (compilación) de la mayoría de las aplicaciones desde la 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!

Empezando

Si no ha compilado una aplicación desde la fuente en su sistema antes, probablemente necesitará configurarla con algunas herramientas de desarrollo generales, como el gcc conjunto de compiladores, algunos archivos de encabezado comunes (piense en esto como un código que ya ha sido escrito por otra persona y que es utilizado por el programa que está instalando) y la herramienta de creación. Afortunadamente, en Ubuntu, hay un metapaquete llamado build-essential que se instalará de esto. Para instalarlo (¡o simplemente asegurarse 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 “de inicio”. Por lo general, estos estarán en un archivo de almacenamiento con la extensión de archivo de .tar.gz o .tar.bz2. los .tar simplemente significa que es un “archivo de cinta”, que es una agrupación de archivos que conserva su estructura de directorio relativa. los .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 una compresión más alta (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 “home”). Use el comando tar para extraer los archivos del archivo de almacenamiento 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 parámetros de la línea de comandos para extraer archivos, le recomiendo que obtenga una (o ambas) de estas utilidades: dtrx (¡mi favorito!) O deco (más popular). Con cualquiera de estas utilidades, simplemente ingrese el nombre de la utilidad (dtrx o deco) y el nombre del archivo, hace todo el resto. Ambos “saben” cómo manejar la mayoría de los formatos de archivo con los que probablemente se encuentre y tienen un excelente manejo de errores.

Al compilar desde la fuente, hay dos tipos comunes de errores que es probable que encuentre:

  1. Los errores de configuración ocurren cuando ejecuta el script de configuración (generalmente llamado config o configure) para crear un archivo MAKE que es específico para su instalación.
  2. Los errores del compilador ocurren cuando ejecuta el comando make (después de que se ha 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

Una vez que haya extraído el archivo de 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 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 construir / compilar la aplicación e instalarla, incluida información sobre 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 archivo (y, con suerte, miró cualquier documentación en línea relevante para la aplicación), busque un archivo ejecutable (tiene el permiso “x” establecido en el archivo) llamado config o configure. A veces, el archivo puede tener una extensión, como .sh (p.ej, config.sh). Suele ser un script de shell que ejecuta otras utilidades para confirmar que dispone de un entorno “sano” para la compilación. En otras palabras, verificará para asegurarse de que tiene todo lo que necesita instalado.

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 de Python suelen ser muy sencillas de instalar. Para instalar esta aplicación, como root (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 proceder directamente a usar y disfrutar su aplicación.

Ejecute el script de configuración en la terminal. Normalmente, puede (¡y debe!) Ejecutar su script de configuración con su cuenta de usuario habitual.

$ ./config

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

Si no encuentra ningún script que se parezca a un script de configuración, normalmente significa que la aplicación es muy simple y es independiente de la plataforma. Esto significa que simplemente puede pasar al paso de compilación / compilación a continuación, porque el Makefile 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 corro config.sh, se producen 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.

Después de investigar un poco, descubrí que, de hecho, el sqlite3 se instaló la aplicación. Sin embargo, dado que estoy tratando de construir desde la fuente, este es un consejo de que lo que config.sh lo que está buscando son las bibliotecas de desarrollo (encabezados) para sqlite3. En Ubuntu, la mayoría de los paquetes tienen un paquete 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 utilizar el apt-cache utilidad en Ubuntu (y, de manera similar, la 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 detective para determinar cuál es el paquete apropiado. En este caso, el paquete apropiado resulta ser libsqlite3-dev. Tenga en cuenta que a veces el paquete que estamos buscando tendrá la 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. Instalar libsqlite3-dev, ejecute 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 correr config.sh nuevamente para asegurarnos de que hemos resuelto este problema de dependencia y de 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 (p. ej., 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 ejecuta correctamente, el resultado será que creará uno o más archivos make. Estos archivos normalmente se denominan Makefile (¡Recuerde que el caso del nombre de archivo es importante en Unix / Linux!). Si el paquete de compilación incluye subdirectorios, como src, etc., cada uno de estos subdirectorios contendrá un Makefile, así como.

Errores de compilación y creación

Ahora, estamos listos para compilar la aplicación. Esto a menudo se llama edificio y el nombre se toma prestado del proceso del mundo real de construir algo. Las diversas “partes” 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 realicen el trabajo. En la mayoría de los casos, simplemente ejecute make (con su cuenta de usuario habitual) desde el directorio donde ejecutó la configuración. (En algunos casos, como la compilación de aplicaciones escritas con la biblioteca Qt, necesitará ejecutar otra aplicación “contenedora” como qmake. De nuevo, siempre marque la casilla README y / o INSTALL documentos para obtener 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 las advertencias y errores. 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 están siendo violadas. Por lo general, estas advertencias no afectan la función de la aplicación. Por otro lado, deben tratarse los errores del compilador. Con Newsbeuter, cuando ejecuté make, las cosas fueron bien por 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_formu2019 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_ipoolu2019 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. Manejar los errores del compilador a veces puede ser un asunto complicado. Tienes que mirar los errores en busca de pistas sobre el problema. Normalmente, el problema es que algunos archivos de encabezado, que suelen tener la extensión de .h o .hpp, están perdidos. En el caso del error anterior, está (¡o debería estarlo!) Claro que el problema es que stfl.h No se puede encontrar el archivo de encabezado. Como muestra este ejemplo, desea ver las primeras líneas del mensaje de error y avanzar hacia abajo para encontrar la causa subyacente del problema.

Después de mirar la documentación de Newsbeuter (que debería haber hecho antes de comenzó, ¡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 este mismo proceso para esa biblioteca requerida: obtener la biblioteca y ejecutar el proceso de configuración, construcción e instalación para ella y, luego, reanudar la construcció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 rehacer 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 comienza donde termina (en el punto del error). Por lo tanto, no se volverá a compilar ningún archivo que ya se haya 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 complete con éxito, estará 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 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 solo unas pocas veces, ¡se convertirá en una segunda naturaleza para usted!


Solución 4:

Bueno, ./configure –help le dará mucha información, para los archivos de configuración generados por autotools de GNU. La mayor parte se reduce a –with / – without para habilitar funciones (estas pueden requerir 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, generalmente lo desea como –prefix = / usr o tal vez –prefix = / opt / YourPackage).

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 desea sus bibliotecas. Sin embargo, /etc/ld.so.conf puede incluir entradas adicionales.

configurar y encontrarlos con sólo intentar ejecutar “gcc -l” y ver si hay errores. Puede agregar “-L” a su parámetro CFLAGS para agregar rutas adicionales para la búsqueda.

Puede tener varias versiones instaladas, y el software vinculado con una versión anterior permanecerá vinculado (ejecute ldd para averiguar el enlace en Linux), pero las nuevas compilaciones 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 puede encontrar que las aplicaciones no triviales no se compilan correctamente de forma estática.

ls -l es su mejor opción para encontrar las bibliotecas instaladas.

Y ahí es donde me quedo sin información; cómo jugar bien con los 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 de ver qué bibliotecas ha instalado y las versiones (esto es en Linux Debian, por lo que debería funcionar con otras versiones también).

dpkg --list

Debería obtener una lista muy 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
¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *