¿Qué significa Linux From Scratch (LFS)?

He aquí algunos puntos completamente prácticos de netiquette. Estos incluyen solamente aquellos puntos que alguien podría comentar que has obviado. Los que participan en las listas de distribución del proyecto encontrarán obvios los primeros. Hacia el final hay más que no son tan obvios.

Las razones para esto van a ser omitidas para ser breves, pero ténganlo por seguro, las hay, y esas razones son más que sólo una preferencia de alguna persona en particular.

Teniendo esto en cuenta, he aquí varios consejos sobre comportamiento seguidos de cuestiones mas "técnicas":

A pesar que este texto se refiere exclusivamente a "las listas" no pretende ignorar los grupos de noticias a los cuales se envían los mensajes.

Por favor, recuerda que es grosero enviar preguntas que ya están respondidas en la documentación obviamente disponible tales como los libros LFS y BLFS, este PMF (FAQ), las recetas de LFS, las páginas del manual apropiadas, el archivo de la lista, y las búsquedas simples en Google. Mientras puedas demostrar que has hecho un esfuerzo para encontrar la respuesta y no te ofenda que te indiquen alguna documentación, no deberíais preocuparos. Aquél que lo haga puede ser ignorado; lo tiene merecido.

La mayoría de los intercambios de insultos (flamewars) comienzan cuando algún novato con un ego extragrande envía una pregunta obvia, entonces algunos le critican (incluso de manera educada), y éste llega a ser públicamente ofendido. Por favor, intenta evitar esta situación. Con pocas palabras intenta remitirles a la documentación exacta que debieron leer. Si crees que debes criticarle, por favor hazlo a través de su correo personal, no en la lista. Aplicad lo mismo a cualquier situación que pueda caldearse.

La lista tiene miembros de muchas nacionalidades por lo que el lenguaje coloquial de todo tipo y idioma será normalmente mal entendido. (Atestiguado por la reciente discusión sobre "bootstrapping".) Cualquier mención a la blasfemia, política, guerra o religión (incluso en la firma) puede molestar a alguien en algún lugar, así que por favor evítalas. Finalmente, se considera correcto el escribir en ingles aunque la gente de la lista sepa más idiomas.

Ahora vamos a por las cosas "más mecánicas".

No envíes mensajes en HTML. Si usas Yahoo, Hotmail, o Outlook y no has desactivado el HTML, entonces está activado. Si estás usando algún otro cliente de correo, por favor verifica esto antes de enviar algún mensaje. Echa un vistazo a http://www.expita.com/nomime.html.

Escribe tus mensajes a 72 caracteres por línea. Si no deseas hacer esto a mano, configura tu cliente de correo para hacerlo automáticamente al enviar.

Responde debajo del texto del mensaje original. En Outlook es difícil hacer esto Hay un añadido (plugin) para arreglar el Outlook en http://home.in.tum.de/~jain/software/outlook-quotefix/, y uno para Outlook Express en http://home.in.tum.de/~jain/software/oe-quotefix/.

Limitar la firma a 4 líneas.

Recorta el texto del mensaje original, y especialmente las firmas. Pero no cortar tanto como para hacer confusa tu respuesta sin consultar el original.

No hagas click en "responder" a menos que de hecho estés respondiendo a un mensaje. Utiliza "nuevo" o "redactar" o como sea que lo llame tu cliente de correo. Responder hace mucho más que establecer la linea del asunto y hará que tu mensaje aparezca en donde no debe, a menos que de hecho estés respondiendo.

Esto que sigue no es lo más importante, pero es útil conocerlo. En las listas de LFS, la gente suele borrar el contenido del campo CC y sólo envía sus respuestas a la lista. Esto probablemente no es una buena idea, pero existe en la práctica debido a una situación política la cual es improbable que cambie.

La respuesta completa está en http://www.linuxfromscratch.org/mailinglists/, pero aquí tienes un resumen:

• Envía preguntas de soporte sólo a las listas lfs-support y blfs-support. Preguntas del tipo "¿Cómo hago...?" y "Estoy obteniendo este error..." o cualquier otra petición de ayuda deben dirigirse a las listas de soporte, y a ningún sitio más.

• Si no estás teniendo ningún problema siguiendo el libro LFS, no preguntes en lfs-support.

• Si no estás enviando ninguna sugerencia para mejorar el propio libro LFS, no envíes a lfs-dev.

• Sólo se aceptan sugerencias sobre el libro BLFS en la lista blfs-dev.

• Las cosas son un poco diferentes para blfs-support. Cualquier cosa que no quepa en una de las listas anteriores tiene cabida aquí, excepto para el precio de la cerveza y las peleas de GNU contra BSD.

• El precio de la cerveza, las peleas de GNU contra BSD y las peleas de Microsoft contra Linux deben restringirse a lfs-chat. Hoy en día, la discusión sobre hardware también debería ir aquí.

Cuando estas FAQ no te ayuden, hay varios sitios a los que puedes acudir.

Si tienes problemas con algo del libro, nunca está de más volver al libro. Es sorprendente con qué facilidad se pueden pasar por alto pequeños detalles.

Si lo anterior no funciona, leer las páginas de manual y los documentos info apropiados te proporcionará información útil sobre el tema, aunque no encuentres lo que estás buscando, y tendrás los conocimientos necesarios para no avergonzarte si tienes que preguntar a alguien.

http://lucas.hispalinux.es/ tiene traducidos al castellano los COMOs y una gran cantidad de documentación. Puedes encontrar algo allí. En http://www.tldp.org/ se encuentran los originales en inglés.

El sitio de búsqueda de linuxfromscratch.org incluye las listas de correo. Muchas preguntas se han discutido allí al menos una vez. Puedes encontrarlo en http://search.linuxfromscratch.org/.

Si deseas soporte, el IRC normalmente es mejor. Es más rápido y no atasca las listas de correo. Se puede encontrar información sobre los canales IRC de LFS en http://www.linuxfromscratch.org/misc/irc.shtml.

Hay dos canales interesantes en el IRC. #LFS, que es el canal de la comunidad, y #lfs-support, que es para soporte. Si vas a pedir soporte es más fácil encontrar ayuda competente y amistosa en #lfs-support.

Como último recurso, están las listas de correo. La gente se enfadará contigo si no usas la adecuada o si envías mensajes a más de una lista (cross post). Puedes encontrar información sobre las listas de correo en http://www.linuxfromscratch.org/mailinglists/, y además te indica que lista usar.

Las sugerencias son muy bien recibidas. Puedes contactar con el desarrollador de estas FAQ tanto directamente en su dirección de correo electrónico, como en la lista de correo apropiada.

Entre las sugerencias útiles se incluye añadir preguntas que son formuladas frecuentemente - con respuestas bien elaboradas - y la eliminación de preguntas que estén obsoletas.

Contribuciones regulares y serias también son bienvenidas. Si estás interesado en esto, necesitas crearte una copia local de la FAQ a partir del módulo CVS de LFS, igual que harías con el libro, y modificar las fuentes DocBook XML. Estas modificaciones deben suministrarse, normalmente, como parches generados con "diff -Naur", pero para adiciones simples que implican añadir un solo fichero, puede ser más sencillo enviar sólo ese nuevo fichero.

Todo lo que se prevea incluir en la FAQ, sin implicar correcciones sustanciales, debe estar bien pensado, comprobado e investigado, y escrito en un estilo consistente con el contenido actual.

No, los comandos "ln -s" del libro estan bien. Un enlace simbólico no es más que un fichero especial que contiene el nombre del fichero. Así que el nombre del fichero es relativo al enlace, y no al directorio desde el que se crea el enlace. Pruebalo y lo veras.

Prueba "ls -i /bin/foo /bin/bar". ¿Tienen el mismo número de inodo? Si es así entonces no son copias, son enlaces duros.

Si esta es la primera vez que construyes el LFS, usar una versión que no está en el libro o desviarse del libro de alguna forma, no es una buena idea. En el canal de IRC, los que concurren regularmente tienen un dicho, "FBBG". Como rms, el bot residente rápidamente aclara, esto significa "Follow Book, Book Good" (Sigue el Libro, el Libro es Bueno). Ellos y los participantes de las listas de correo han ayudado muchas veces a algún novato descontento que se desvió del libro en su primera instalación.

Una vez que construyas un sistema "como manda el libro", tendrás una base estable de conocimientos a partir de la que experimentar lo que a tu corazón alegre (o entristezca, como suele suceder).

Para ayudarte durante tu recorrido, aquí tienes algunas notas para versiones específicas:

• flex-2.5.31: Esta versión es mala. En #lfs-support se dice que funcionará con XFree86 4.0.3.1, las últimas binutils de HJL y usando "flex -l" con modutils, lo que puede hacerse con http://evanidus.ath.cx:8080/l14h/patches/personal/modutils-2.4.25-flex-2.5.31-tmp-fix.patch.bz2 También tendrás problemas con libidl y quizás otros más. Si lo intentas será por tu cuenta. No esperes ningún tipo de soporte. Probablemente, la versión 2.5.27 funcionará sin tantos ajustes extraños.

• gcc-3.3: No uses esta versión aún, a menos que seas un desarrollador y puedas corregir los errores que se te presenten, porque compila mal muchos paquetes. Si eres un desarrollador, puedes encontrar útiles los parche de Jim Gifford. Se encuentran en http://www.jg555.com/projects/patches/ftpdownload/

• glibc-2.3.2: A las instrucciones de instalación añade esto:

  touch /etc/ld.so.conf && ln -s /static/bin/pwd /bin/pwd && touch /usr/include/assert.h &&

• bash-2.05b: Aplica los parches de ftp://ftp.gnu.org/gnu/bash/bash-2.05b-patches/ y configura la versión estática (Capítulo 5) con la opción --without-bash-malloc.

Si la nueva versión tiene más de un día, es muy probable que haya alguien probándola e informando de ello en las listas de distribución. Busca en los archivos antes de enviar preguntas sobre sí funciona.

Si quieres informar sobre una nueva versión de un paquete, sigue los siguientes pasos y evita duplicar el aviso:

• Comprueba la página de freshmeat del proyecto para ver si ha sido actualizada. Si no lo ha sido, informa de la nueva versión allí.

• Si freshmeat ha sido actualizado, comprueba el bugzilla de LFS (o el bugzilla de BLFS) para ver si se ha enviado un mensaje sobre esa versión.

• Si la versión no está en bugzilla, avisa en la lista de correo lfs-book (o blfs-book para paquetes de BLFS). Y si lo deseas, prueba e informa de cualquier problema o cambio en las instrucciones de compilación.

Lee: http://beyond.linuxfromscratch.org/view/cvs/postlfs/inputrc.html.

Normalmente, los sistemas Unix ejecutan sulogin si, en el arranque normal, el programa fsck encuentra errores. Así el administrador puede entrar en el sistema y arreglarlo. Como sulogin aceptará cualquier contraseña si el fichero /etc/passwd se ha corrompido, los desarrolladores de LFS decidieron que esto era un riesgo para la seguridad. Por lo tanto, los guiones de arranque de LFS apagan la máquina si fsck encuentra errores; entonces debe ser arrancada con "init=/bin/bash" como parámetro del núcleo para conseguir un intérprete de comandos para el administrador. Decidir si esto es deseable sobrepasa el alcance de estas FAQ, pero si esto no te funciona, puedes querer cambiar ese guión de arranque antes de que sea demasiado tarde.

GRUB, probablemente, reemplazará a LILO en el libro cuando los desarrolladores de GRUB hagan una versión a la que llamen estable. Si te gustaría que eso ocurriese, avisa a los desarrolladores de GRUB, ya que las versiones actuales parecen perfectamente estables.

Si en tu configuración actual usas GRUB o te gustaría usarlo, no deberías tener ningún problema si sigues su documentación y el "GRUB-Cómo" de LFS, que puedes encontrar en http://hints.linuxfromscratch.org/hints/grub-howto.txt. Si haces esto, puedes omitir bin86, debido a que sólo es usado por LILO.

De momento, el libro se ha detenido en LILO 22.2 porque las versiones de LILO posteriores a la 22.2 requieren nasm. Aunque instalar nasm no es un problema, el libro y muchos usuarios son reacios a instalar un paquete extra sólo para LILO. Muchos usuarios se están cambiando a GRUB. (El libro posiblemente cambiará a GRUB si los desarrolladores de GRUB hacen una versión a la que llamen estable. Puedes contactar con los desarrolladores de GRUB si deseas que esto suceda.)

Los usuarios que cambien a GRUB pueden omitir bin86, pues sólo es usado por LILO.

Marc Heerdink puede que sea quien mejor lo haya dicho en un correo a la lista lfs-dev:

El problema es que las FAQ son un documento dinámico. Las FAQ para una versión del libro sólo se publican después de la propia versión del libro, porque las FAQ se actualizan para reflejar las preguntas hechas sobre la versión actual del libro. Es mejor incluir un enlace; de esta forma, siempre tendrás a mano las respuestas actualizadas.

Este es un tema ampliamente discutido en el hilo que se puede leer en http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2002/02/0012.html.

El libro incluye ed porque patch lo usa para procesar guiones ed. De todas formas, estos son raros hoy en día; todo el mundo utiliza parches con formato diff.

Pero ed tiene otros usos:

• Para todos aquellos que han aprendido a utilizarlo, ed es un editor de emergencia muy útil. El cliente de telnet estándar de MS Windows puede funcionar con ed, pero tiene problemas con editores de pantalla completa (como vim). Y un vim con todas sus funciones no sólo necesita ncurses, sino también X11. Cualquier problema con esas librerías dejaría al sistema sin un editor si ed no estuviera presente.

• Aunque no es una razón para incluir ed en el libro, a algunas personas les gusta ed.

• Conocer ed ayuda a entender vi(m) y la historia de Unix en general.

La gestión de paquetes -más allá de la proporcionada por los archivos de código fuente - está fuera del alcance del libro. Si ninguna otra parece válida, el número de diferentes "soluciones" debería apuntar a algunas de las razones.

Estas son algunas de las opciones:

• No es necesario ningún tipo de gestión de paquetes en realidad. A menos que sea deseable supervisar minuciosamente la colocación de los ficheros de los paquetes, cualquier paquete lo suficientemente grande como para justificar su borrado por razones de espacio de disco puede instalarse en /opt como se detalla en la norma FHS (tal vez en /opt/foo-x.x con un enlace desde /opt/foo), y las nuevas versiones pueden instalarse sobre las anteriores, aunque los cambios de versión mayor y las librerías se actualizan mejor, generalmente, reconstruyendo el sistema desde ese punto en adelante.

• Un buen número de distribuciones utilizan RPM, el Gestor de Paquetes de Redhat (Redhat Package Manager), Está disponible en http://www.rpm.org/, y hay una receta sobre RPM para ayudar con su instalación en http://hints.linuxfromscratch.org/hints/rpm.txt.

• Hay un sistema LFS basado en RPM en http://www.puxedo.org/lvr/

• Existen varias implementaciones de administradores de paquetes del estilo "enlaces simbólicos":

  • Epkg está disponible en http://encap.cso.uiuc.edu/epkg/.

  • Graft está disponible en http://www.gormand.com.au/peters/tools/.

  • GNU Stow está disponible en http://www.gnu.org/software/stow/.

  • Depot está disponible en http://asg.web.cmu.edu/depot/.

  • La documentación de Graft menciona muchos otros en http://www.gormand.com.au/peters/tools/graft/graft.html#research.

• El gestor de paquetes de NetBSD, pkgsrc, también está disponible para otros sistemas, incluyendo Linux. Encuéntralo en http://www.netbsd.org/zoularis/.

• Originalmente basado en un guión escrito por el propio Gerard Beekmans (cabeza de LFS), install-log guarda una lista de los ficheros instalados por un paquete mientras éste se instala. Está disponible en http://install-log.sourceforge.net/.

• Desde entonces, Gerard ha añadido algunas cosas a este guión. Están disponibles en http://linuxfromscratch.org/~gerard/log-install and http://linuxfromscratch.org/~gerard/pkgdel.

• CheckInstall intenta registrar las llamadas al sistema que hace "make install". Está disponible en http://asic-linux.com.mx/~izto/checkinstall/.

• pkgutils, usado en la distribución CRUX, está disponible en http://www.fukt.bth.se/~per/pkgutils/.

• Más información sobre estos y otros sistemas interesantes la tienes en http://hints.linuxfromscratch.org/hints.shtml#package.

Kelledin mantiene una lista de soluciones para compilar en la plataforma Alpha en http://skarpsey.dyndns.org/alpha-lfs/alpha.html.

Por razones de ancho de banda, el paquete lfs-packages ya no está disponible. Esto está sujeto a cambio, pero por ahora los paquetes pueden descargarse en bloque mediante un guión para wget. Para LFS-4.1 tienes este: http://linuxfromscratch.org/~highos/packages-ordered.wget y para la versión CVS del LFS tienes otro: http://archive.linuxfromscratch.org/mail-archives/lfs-support/2003/05/att-0492/01-lfs-cvs-20030516.wget. La página de manual de wget(1) indica cómo usar estos guiones.

Usualmente, no es difícil, pero algunos pueden requerir una buena búsqueda.

Para encontrar un comando, debes saber a que paquete pertenece. A veces es obvio, pero cuando no lo es, una búsqueda en http://www.debian.org/distrib/packages#search_contents o en http://www.rpmfind.net te dará la respuesta.

Una vez que sepas que paquete es, al buscar en http://freshmeat.net/ por

foo

En http://www.google.com/, utilizando una búsqueda como

+foo +index +lsm

Si el resultado de la búsqueda está saturado de paquetes RPM y ficheros Debian, prueba

+foo +index +lsm -RPM -debian

Los resultados en http://www.ibiblio.org/ con frecuencia son buenos. Para encontrarlos específicamente usa

foo site:ibiblio.org

Si la última versión es demasiado antigua, Debian o un SRPM pueden tener parches que te ayuden, y puede que haya un sustituto moderno para el paquete que una búsqueda en freshmeat seguramente encontrará.

Además de la documentación del núcleo en /usr/src/linux/Documentation o dondequiera que hayas desempaquetado las fuentes del núcleo, y de la ayuda en la herramienta de configuración del núcleo (make menuconfig), lee el Module-HOWTO en http://www.tldp.org/HOWTO/Module-HOWTO/ y el Kernel-COMO en http://lucas.hispalinux.es/COMO-INSFLUG/COMOs/Kernel-Como/.

Cualquier distribución reciente servirá. Si tienes problemas, intenta instalar y/o actualizar los paquetes de desarrollo (busca aquellos que comiencen por "gcc", "glibc" o "libstdc++" o que terminen en "-dev").

http://beyond.linuxfromscratch.org/view/cvs/general/which.html

Hay instrucciones en el consejo sobre NFS, que puedes encontrar en http://hints.linuxfromscratch.org/hints/nfs.txt.

Además, Marc Heerdink escribe:

Tengo una versión de tcp_wrappers y de portmap que han sido parcheadas con los parches de Debian, se han adaptado los Makefiles para LFS y se han arreglado todos los problemas y avisos de compilación. Además, se ha incluido un guión llamado lfs-install.sh que proporciona una manera realmente rápida y fácil de instalarlos. Ambos pueden encontrarse en http://www.linuxfromscratch.org/~gimli/. Puedes añadir una nota sobre estos paquetes para la gente que quiere hacerlo de la manera sencilla :)

En Mandrake/RPMS2/libncurses5-devel-5.2-16mdk.1586.rpm, en el Disco 2. El número de versión puede ser diferente (si no tienes libcurses.a (sin "n"), lee de nuevo las instrucciones del libro para bash más cuidadosamente).

Hay varias Recetas en la sección "Booting" en http://hints.linuxfromscratch.org/hints.shtml#booting.

También hay imágenes ISO en http://www.stockwith.co.uk/iso/ y http://pogostick.net/~peram/lfs/.

Gerard describe el proceso de crear una instalación de LFS de 5MB en un correo que se puede encontrar en http://archive.linuxfromscratch.org/mail-archives/lfs-support/2001/10/0072.html, y hay enlaces a muchos recursos en un mensaje enviado por Cor Lem, que se puede encontrar en http://archive.linuxfromscratch.org/mail-archives/lfs-support/2002/06/0225.html y en una respuesta al mismo.

A menudo, es útil compilar un sistema LFS para una máquina en otra. Supongamos que utilizamos un rápido procesador Athlon de 1GHz para construir e instalar un sistema para un antiguo 486. A pesar de que, técnicamente, eso no es compilación cruzada, los programas compilados para un Athlon no pueden ejecutarse en un 486. Esto es debido a que los programas compilados para el procesador más moderno usan características que el más antiguo no tiene. Para conseguir que el sistema más moderno compile para el más antiguo, sigue las instrucciones del consejo http://hints.linuxfromscratch.org/hints/crosscompiling-x86.txt.

Hay unas cuantas cosas que no requieren mucho conocimiento de C y que tu puedes hacer para conseguir que compile un código fuente antiguo en un sistema reciente.

• Si estás usando GCC 3, intenta añadir la opción -std=gnu89 (por ejemplo, en CFLAGS o CC. La forma exacta de hacerlo está fuera del alcance de estas FAQ).

Me alegra que lo preguntes ;) En el Reino Unido, Ian Molton ejecuta un servidor de Quake para usuarios de LFS. Aquí están los detalles:

• Los jugadores necesitan la última versión liberada de Quake 3. A Febrero de 2003 es la versión 1.32b que puedes encontrar en ftp://ftp.idsoftware.com/idstuff/quake3/linux/linuxq3apoint-1.32b.x86.run

• Los jugadores necesitan el fichero pak0.pk3 de la versión completa de Quake 3. Este está disponible en el CD de Quake 3 (incluso en la versión de MS Windows). Debes colocarlo en /usr/local/games/quake3/baseq3/ a menos que instales el Quake 3 en cualquier otro sitio.

• También necesitan el programa utilizado en el servidor para añadir mapas, que pueden descargar de http://games.mnementh.co.uk/ y lo deben instalar en ~/.q3a/baseq3/ o donde han colocado el fichero pak0.pk3. Es totalmente necesario descargarse los mapas manualmente porque el servidor tiene deshabilitada la descarga automática.

• Por la misma razón por la que está deshabilitada la descarga automática de mapas, por favor, no descargues nada de la web mientras se está jugando.

• Aunque sólo se garantiza que el servidor se esté ejecutando cuando está prevista una partida, los jugadores pueden intentar conectarse cuando quieran.

• Los juegos están planificados todas las semanas, los martes a las 20:00 UTC y los sábados a las 22:00 UTC. Ten en cuenta que las horas están en UTC.

• Como el servidor es sólo para usuarios de LFS, e Ian quiere evitar el uso de claves, el nombre del servidor sólo lo encontrarás en los archivos del lfs-chat.

• Si has creado una entrada al servidor en tus "favoritos" pero no lo ves, puede ser porque tienes desactivado "Show empty servers".

Tiene que ver con los caracteres usados para indicar el fin de línea.

Se pueden usar dos caracteres:

• Line Feed (Avance de línea): (LF) Octal:012 Decimal:10 Hex:0A Carácter de escape estilo C:' ' Avanza una línea hacia abajo.

• Carriage Return (Retorno de carro): (CR) Octal:015 Decimal:13 Hex:0D Carácter de escape estilo C :' ' Avanza al margen izquierdo.

cp  .dos &&
cat .dos | tr -d '
' > 

Aquí hay un ejemplo de cuando todo funciona:

tar xvjf foo-0.0.tar.bz2
cd foo-0.0
./configure --prefix=/usr
make
make install
cd ..
rm -rf foo-0.0

Es importante borrar el código fuente al terminar. Los fuentes solo son útiles para reinstalar sin recompilar porque "make clean" y sus amigos no son confiables. Fíjate en el próximo ejemplo que hacer si fallan "./configure" o "make".

La única excepción al borrar los fuentes es el núcleo Linux. Casi todos conservan el árbol de los fuentes del núcleo para no tener que reconfigurarlo todo desde cero si sólo quieren hacer un pequeño cambio. Si se necesita una gran modificación, como cambiar el tipo de procesador, quizá sea necesario borrar y volver a desempaquetar los fuentes del núcleo.

Y aquí va un ejemplo por si algo falla (en este caso configure):

tar xvjf foo-0.0.tar.bz2
cd foo-0.0
./configure --prefix=/usr
.
.
.
*** configure: error: foo requires libess 4.2 or greater
please install libess and rerun configure.

(*** configure: error: foo requiere libess 4.2 o superior)
(por favor, instala libess y vuelve a ejecutar configure.)
cd ..
rm -rf foo-0.0
tar xvjf libess-4.2.tar.bz2
cd libess-4.2
./configure --prefix=/usr
make
make install
cd ..
rm -rf libess-4.2
tar xvjf foo-0.0.tar.bz2
cd foo-0.0
./configure --prefix=/usr
make
make install
cd ..
rm -rf foo-0.0

Nota del editor: El nombre de la librería ficticia libess viene siguiendo a libiberty (de glibc, hasta donde yo sé) y libofat. La razón de esto es la opción -l de gcc, para enlazar con una librería al momento de compilar. Por ejemplo,

gcc -o foo foo.c -lm

gcc -o foo foo.c -liberty -lofat -less
(gcc -o foo foo.c -libertad -bajoengrasa -menos)

No, pero mira en "¿Cómo compilo un paquete?" para más detalles, incluido una excepción a esta regla.

No es un fichero real. Existe en algunos espacios de nombres del kernel. (Y si, no eres el primera persona en pensar que los dispositivos de red deberían ser ficheros reales como todo el resto.)

El manejo de la energía es una función del núcleo (kernel), así que necesitas activarla en el núcleo. Al hacer "make menuconfig", en la sección "configuración general (General Setup)", busca "Soporte para el manejo de energía (Power Management Support)" y lee la ayuda.

Utiliza el programa useradd. Se instaló con el paquete shadow y tiene muchas opciones interesantes. Para más información, consulta la página de manual de useradd.

En pocas palabras, copiamos las cabeceras del núcleo en lugar de hacer enlaces a ellas porque esas cabeceras deberían corresponder con las de la librería libc que se esté ejecutando, no con las del núcleo que se utiliza.

Para econtrar la respuesta larga, mira aquí:

• Un correo del mismo Linus: http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html.

• Tráfico del Núcleo #80, 4. Enlaces simbólicos en el núcleo; Discusión sobre la interfaz Núcleo/Librería/etc: http://kt.zork.net/kernel-traffic/kt20000814_80.txt (Esto cubre el hilo en el que ocurrió el correo anterior.)

Respuesta corta: no.

Respuesta larga: probablemente, pero sólo para aquellas personas que han desarrollado el paquete que intentas compilar. Para la mayoría todo irá bien a menos que make finalice con un error.

Veamos un ejemplo:

sk ~/tmp $ cat > Makefile
main:
gcc main.c
sk ~/tmp $ cat > main.c
void main() { exit(0); }
sk ~/tmp $ make
gcc main.c
main.c: In function `main':
main.c:1: warning: return type of `main' is not `int'
sk ~/tmp $ ######## that worked ########
sk ~/tmp $ 
sk ~/tmp $ cat > main.c
int main() { exxit(0) }
sk ~/tmp $ make
gcc main.c
main.c: In function `main':
main.c:1: parse error before `}'
make: *** [main] Error 1
sk ~/tmp $ ######## that failed ########
sk ~/tmp $