Si alguna vez ha intentado compilar los fuentes de -current de alguna versión de OpenBSD antigua, se habrá dado cuenta de que el proceso no siempre es fácil. En esta guía se intentan solucionar los problemas más comunes que se encuentran al actualizar entre versiones de OpenBSD, o desde las versiones a -current.
gcc) a una
versión más nueva. ¿Hay algún
procedimiento para el sistema de arranque?
4.2.1 - i386 y sparc ya no usan #define4.3: make build muere con errores de tipo unimplemented syscall.
4.2.2 - La compilación falla en xlint
4.2.3 - «Volcado de Memoria» ("Core Dump") en uthread_autoinit.c
4.2.4 - egcs parece mucho más lento que gcc
4.2.5 - egcs genera código de mayor tamaño que gcc
4.2.6 - Después de instalar egcs, me queda muy poco espacio en el disco
4.2.7 - La compilación falla al compilar libcurses
4.2.8 - 'make obj' falla
Con anterioridad a OpenBSD 2.7, el desarrollo de OpenBSD tenía lugar desde un sólo árbol de fuentes sin ramificaciones. A partir de la versión 2.7 se introdujo una ramificación de parches.
Las «versiones oficiales» ("releases") de OpenBSD se producen con intervalos aproximados de seis meses. Éstas se enumeran en un modo convencional (2.x). La versión oficial de OpenBSD actual es la 2.8.
-current, la contracción de openbsd-current («openbsd-actual»), se refiere a la versión de última hora del árbol de fuentes contenida en el repositorio de CVS. Éste es el árbol que usan con más asiduidad los desarrolladores de OpenBSD. El árbol -current contiene todo el código que está planeado para el lanzamiento de la siguiente versión. De vez en cuando, algunos valientes abandonan las versiones oficiales y utilizan openbsd-current, generalmente para aprovechar funcionalidades que todavía no se han implementado en las versiones oficiales. Sin embargo, debido a su naturaleza de incertidumbre, la actualización a -current no se recomienda a usuarios no técnicos.
Entre una versión oficial y otra, se ponen a disposición unas versiones llamadas snapshots. Éstas son versiones de prueba del árbol de fuentes de -current. Debido a que son un reflejo del estado actual de desarrollo, no se puede garantizar que los snapshots funcionen correctamente... ni siquiera que funcionen. Los snapshots son bastante útiles cuando se está actualizando desde una versión oficial (o una versión de -current más antigua) a la del árbol actual.
A partir de OpenBSD 2.7 se introdujo una ramificación de parches (llamada -stable). Esta ramificación contiene la versión oficial ("release") base y cualquier otro parche o solución importante (se consideran importantes los parches publicados en la página de erratas, además de otros que son obvios y simples pero que no merecen ser mencionados en dicha página).
Debido a cambios en las bibliotecas de base, actualizar de una versión oficial a -current no siempre es fácil. La forma más difícil de actualizar a -current es actualizar primero al snapshot más reciente (por lo general, mediante una instalación por FTP). Una vez el snapshot ha sido instalado, se pueden obtener los fuentes más recientes y compilarlos. Este procedimiento debería eliminar la mayoría de problemas con las bibliotecas y las herramientas necesarias.
Los snapshots se solían retirar de los servidores de distribución justo antes del lanzamiento de una nueva versión oficial. Esto ya no forma parte de la política de OpenBSD.
Los snapshots se pueden retirar según se vayan anticuando (o según dejen de ser relevantes). Si no hay ningún snapshots disponible, entonces debe actualizar a la versión más reciente y compilar lo restante desde los fuentes.
Respuesta corta: http://www.openbsd.org/es/anoncvs.html
Por ejemplo, para obtener el árbol completo mediante CVS (usando la shell bash; para otras, substituya export por setenv):
# export CVSROOT=anoncvs@anoncvs.ca.openbsd.org:/cvs # export CVS_RSH=/usr/local/bin/ssh # cd /usr # cvs -q get -PA src
Hay unas instrucciones básicas en /usr/src/Makefile. Ésta es una versión ligeramente extendida.
Si había creado un directorio /usr/obj separado, límpielo y reconstruya los enlaces simbólicos:
# rm -rf /usr/obj # mkdir /usr/obj # cd /usr/src # make objSi se encuentra con que tiene que realizar este paso muchas veces, puede encontrar mucho más rápido poner /usr/obj en su propia partición y usar newfs en lugar de rm. Por ejemplo, lo que yo hago es:
# umount /dev/wd0h (la partición /usr/obj) # newfs wd0h # mount -a # make objSi está preocupado porque pueda haber ficheros objeto en su árbol de fuentes, haga lo siguiente:
# cd /usr/src # find . -type l -name obj | xargs rm # make cleandir # rm -rf /usr/obj # mkdir /usr/obj # make obj
# cd /usr/src/etc && make DESTDIR=/ distrib-dirs
# cd /usr/src/sys/arch/`machine`/conf # cp GENERIC MYKERNEL # vi MYKERNEL (edite MYKERNEL como le convenga) # config MYKERNEL # cd ../compile/MYKERNEL # make clean && make depend && make (sólo en la arquitectura arc) copie bsd.ecoff en su partición FAT # cp /bsd /bsd.old && cp bsd /bsd # chown root.wheel /bsd (if you compiled as someone else) (reinicie)
# cd /usr/src # make build
# mkdir /home/newroot # export DESTDIR=/home/newroot # cd /usr/src/etc && make distribution-etc-root-varAhora compare los ficheros en /home/newroot con sus correspondientes ya instalados. Reemplace o actualice los ficheros según sea necesario.
# rm -rf /home/newroot (cuando haya acabado)
Yo lo haría, pero si realmente quiere retomarlo desde el punto en que se quedó, haga lo siguiente:
# cd /usr/src # make -n buildDe este modo le mostrará lo que 'make build' esté haciendo. Por ejemplo, el mío dice:
(cd /usr/src/share/mk && make install) (cd /usr/src/include; make prereq; make includes) make cleandir (cd /usr/src/lib && make depend && make && make install) (cd /usr/src/gnu/lib && make depend && make && make install) (cd /usr/src/kerberosIV/lib && make depend && make && make install) (cd /usr/src/gnu/usr.bin/perl && make -f Makefile.bsd-wrapper config.sh && make e -f Makefile.bsd-wrapper depend && make -f Makefile.bsd-wrapper perl.lib && make -f Makefile.bsd-wrapper install.lib) make depend && make && make installPara empezar desde donde se quedó, vuelva a invocar las órdenes desde el punto en donde se cortó la compilación.
Si tiene que realizar este procedimiento muchas veces, es posible que le convenga crear un nuevo objetivo en su fichero makefile. Sólo tiene que copiar la entrada para build (a build-noclean, por ejemplo), y eliminar la referencia make cleandir.
Si su 'make build' finaliza con un error, es muy posible que se deba a que no eliminó sus ficheros objeto antiguos antes de recompilar. Lea la sección 1.5 para más detalles sobre cómo limpiar esos ficheros.
Si está seguro de que su árbol está limpio de viejos restos, y aún así recibe un error de compilación, es que ha ocurrido una de las siguientes tres cosas:
gcc) a una
versión más nueva. ¿Hay algún
procedimiento para el sistema de arranque?Debido a que la actualización de un compilador es como «el problema del huevo y la gallina», los cambios al compilador original del árbol requieren que se les preste algo más de atención. Por regla general se seguirá este procedimiento:
(... y sí, se compilará dos veces)
$ rm -r /usr/obj/gnu/egcs/gcc/* $ cd /usr/src/gnu/egcs/gcc $ make -f Makefile.bsd-wrapper clean $ make -f Makefile.bsd-wrapper obj $ make -f Makefile.bsd-wrapper depend $ make -f Makefile.bsd-wrapper $ sudo make -f Makefile.bsd-wrapper install $ make -f Makefile.bsd-wrapper clean $ make -f Makefile.bsd-wrapper depend $ make -f Makefile.bsd-wrapper $ sudo make -f Makefile.bsd-wrapper instally a continuación ejecute un make build normal.
Puede acelerar este proceso usando el procedimiento BOOTSTRAP:
$ cd /usr/src/gnu/egcs/gcc $ make -f Makefile.bsd-wrapper clean $ make -f Makefile.bsd-wrapper obj $ make -f Makefile.bsd-wrapper -DBOOTSTRAP $ sudo make -f Makefile.bsd-wrapper -DBOOTSTRAP install $ make -f Makefile.bsd-wrapper clean $ make -f Makefile.bsd-wrapper $ sudo make -f Makefile.bsd-wrapper install
Respuesta corta: A mano.
Respuesta larga:
Como parte de la política de OpenBSD, el software en el árbol de cvs no modifica los ficheros en /etc de forma automática. Esto quiere decir que es siempre el administrador quien debe llevar a cabo las modificaciones necesarias a los ficheros de configuración. Las actualizaciones no constituyen una excepción. Para actualizar los ficheros en estos directorios, primero determine qué cambios ha sufrido los ficheros básicos de la distribución, y a continuación vuelva a aplicar esos cambios manualmente.
Por ejemplo, para ver los ficheros que han cambiado más recientemente en el árbol, haga:
# cd /usr/src/etc # ls -lt |morePara ver todos los cambios en /etc entre versiones de OpenBSD arbitrarias, puede usar CVS. Por ejemplo, para ver los cambios acontecidos entre 2.6 y 2.7, haga:
# cd /usr/src/etc # cvs diff -u -rOPENBSD_2_6 -rOPENBSD_2_7Una vez que haya identificado los cambios, vuelva a aplicarlos a su árbol local, conservando cualquier configuración a nivel local que haya hecho Vd. anteriormente.
# cd /usr/src # cvs -q -d anoncvs@some.anon.server:/cvs up -PAd # find . -type l -name obj | xargs rm # make -k cleandir # rm -rf /usr/obj/* # make objSi todavía tiene algún problema, puede añadir las opciones -I ! -I CVS -I obj a sus actualizaciones por CVS. De este modo identificará cualquier resto adicional en su árbol de fuentes.
Con posterioridad a la versión 2.3, el dæmon de DNS named se cambió a una jaula chroot. Para hacer este cambio posible, se creó el usuario named. Si todavía no lo tiene, necesitará crearlo para estar seguro de que todos los directorios se crean correctamente durante el proceso de compilación.
Añada la siguiente entrada a /etc/passwd, usando vipw:
named:*:70:70::0:0:BIND Daemon:/var/named:/sbin/nologinAñada lo siguiente a /etc/group:
named:*:70:
Probablemente le falte una entrada para el usuario named en el fichero de la contraseña.
Respuesta corta:
Cree este usuario antes de la compilación.
Respuesta larga:
El usuario named es necesario para configurar correctamente los permisos. Si este usuario faltara, parte del proceso de compilación fallaría. Si hiciera una captura de pantalla de su compilación de un fichero (por ejemplo, con make build &>/tmp/build.log), notaría el siguiente mensaje:
(cd /usr/src/etc && make DESTDIR=/ distrib-dirs) install -d -o root -g wheel -m 755 / mtree -def mtree/4.4BSD.dist -p // -u mtree: unknown user named mtree: failed at line 1632 of the specification *** Error code 1 (ignored)Desafortunadamente para nosotros, la compilación continuaría felizmente su camino, ignorando completamente el hecho de que ha ocurrido un error.
Si el usuario named existiera, mtree funcionaría correctamente:
missing: ./var/named (created) missing: ./var/named/dev (created) missing: ./var/named/etc (created) missing: ./etc/afs (created) missing: ./etc/ssl (created) missing: ./etc/ssl/private (created) missing: ./usr/obj (not created: File exists) missing: ./usr/share/doc/html (created) missing: ./usr/share/doc/html/lynx_help (created) missing: ./usr/share/doc/html/lynx_help/keystrokes (created) missing: ./usr/share/doc/usd/13.viref (created) missing: ./usr/share/man/cat4/powerpc (created) missing: ./usr/share/man/man4/alpha (created) missing: ./usr/share/man/man4/pmax (created) missing: ./usr/share/man/man4/powerpc (created) missing: ./usr/share/tmac/mdoc (created) missing: ./var/www/htdocs/manual/vhosts (created) missing: ./usr/include/ssl (created)En este caso, la razón de que fallara sería que el directorio /usr/include/ssl nunca fue creado. Sin los ficheros de cabeceras, la compilación de ssleay fallaría.
Solución:
Cree el usuario y el grupo named. Elimine /usr/include/ssl, /var/named, y cualquier otro directorio de la lista anterior que hubiera sido creado por error como un fichero normal por 'make build'.
Su árbol del directorio es incompleto. En concreto, falta el directorio /usr/share/man/cat4/powerpc.
Solución rápida:
Cree este directorio y proceda con la compilación.
Solución completa:
Cree el árbol del directorio completo:
# cd /usr/src/etc && make DESTDIR=/ distrib-dirsEs probable que vea una salida como la siguiente:
install -d -o root -g wheel -m 755 / mtree -def mtree/4.4BSD.dist -p // -u missing: ./var/named (created) missing: ./var/named/dev (created) missing: ./var/named/etc (created) missing: ./etc/afs (created) missing: ./etc/ssl (created) missing: ./etc/ssl/private (created) missing: ./usr/obj (not created: File exists) missing: ./usr/share/doc/html (created) missing: ./usr/share/doc/html/lynx_help (created) missing: ./usr/share/doc/html/lynx_help/keystrokes (created) missing: ./usr/share/doc/usd/13.viref (created) missing: ./usr/share/man/cat4/powerpc (created) missing: ./usr/share/man/man4/alpha (created) missing: ./usr/share/man/man4/pmax (created) missing: ./usr/share/man/man4/powerpc (created) missing: ./usr/share/tmac/mdoc (created) missing: ./var/www/htdocs/manual/vhosts (created) missing: ./usr/include/ssl (created)Note que /usr/share/man/cat4/powerpc es uno de los directorios creados por este proceso.
La sintaxis para invocar cap_mkdb ha cambiado ligeramente. Antes de hacer un 'make build', recompile cap_mkdb desde los fuentes más recientes:
# cd /usr/src/usr.bin/cap_mkdb # make clean && make && make installY 'make build' debería seguir el proceso hasta que estuviera completo.
Varias páginas de manual se cambiaron desde la sección 1 a secciones posteriores. Desafortunadamente, si las páginas de manual viejas se dejan en la sección 1, los usuarios que no lo sepan no podrán ver las últimas versiones de las páginas.
Las siguientes páginas se deberían eliminar:
/usr/share/man/cat1/ipf.0 /usr/share/man/cat1/ipnat.0 /usr/share/man/cat1/ipsecadm.0
Tiene que eliminar el contenido del directorio obj/ antes de
actualizar /usr/src/games/snake.
Síntoma:
'make build' da como resultado un error como éste:
cap_mkdb -i -f terminfo terminfo.src cap_mkdb: illegal option -- i usage: cap_mkdb [-v] [-f outfile] file1 [file2 ...] *** Error code 1
Solución rápida:
Necesita compilar un nuevo cap_mkdb. Mire en la sección 3.1.
La última versión de Perl (5.005_03) requiere una nueva versión de make para compilar correctamente. Debe recompilar make antes de compilar el nuevo Perl. Haga lo siguiente:
# cd /usr/src/usr.bin/make # make clean && make && make install
Ahora continúe y recompile el nuevo Perl. Necesitará
limpiar el directorio obj de Perl a mano antes de
compilar.
Los desarrolladores de Perl deberían tomar nota de los últimos cambios.
De millert@openbsd.org:
La versión de perl en el árbol de fuentes de OpenBSD (posterior a 2.5) se ha actualizado a 5.005_03. El método de compilación ha cambiado algo, pero casi todo debería ser invisible. Los cambios importantes que afectan a los usuarios son los siguientes: 1) Los ficheros lib de perl han cambiado de /usr/lib/perl5 al más correcto /usr/libdata/perl5 2) Los directorios site_perl por definición están ahora en /usr/local. O sea, si instala un módulo de perl, se ubicará en /usr/local/libdata/perl5/site_lib. Esto facilita que pueda ver qué módulos no est´ndar tiene. También significa que podemos tener módulos de perl en el sistema de portes con facilidad. 3) Las páginas de manual de la biblioteca de perl están ahora instaladas en /usr/share/man/cat3p. Necesitará actualizar el fichero man.conf en base al directorio src/etc/man.conf para poder aprovecharlo. Esto quiere decir que ahora puede hacer 'man 3p less' y obtener información sobre el pragma de less, pero 'man less' le seguirá mostrando la página de manual del paginador less. Si tiene módulos u otros ficheros de perl no estándar, lo mejor que puede hacer es mover /usr/lib/perl5 a /usr/libdata/perl5 y añadir un enlace de /usr/lib/perl5 a /usr/libdata/perl5. Alternativamente, podría editar el fichero instalado Config.pm y arreglar los caminos desde ahí.
Este cambio es probablemente el más significativo que encontrará. Para ver instrucciones detalladas, lea la sección 4.2.
La estructura statfs ha cambiado desde el 31 de mayo. Debe recompilar el núcleo de su sistema antes de intentar un 'make build'. Lea la sección 4.3 para más detalles.
El modo más seguro es actualizar a un snapshot reciente, en cuanto haya uno disponible. ¡Busque un snapshot primero!. Arrancar el compilador nuevo desde el viejo debería ser el último recurso.
Antes que nada, le avisamos que en algunas plataformas el mecanismo de arranque todavía no es perfecto. Hasta la fecha, debería funcionar en las siguientes, si lleva cuidado:
Para probar si su plataforma puede arrancar desde el disco, instale egcs-snapshot, que se encuentra disponible en la colección de portes. Si funciona, la versión del árbol también lo hará. Éste es el método m´s seguro para proceder.
Antes de continuar, asegúrese de que las copias que tenga de binutils, gas, y ld estén actualizadas. Recuerde que existen dos copias de gas y ld en el árbol. En i386 y sparc, no se usan las versiones de binutils. Debe usar en su lugar /usr/src/gnu/usr.bin/gas y /usr/src/gnu/usr.bin/ld.
Las siguientes instrucciones se refieren al snapshot original de egcs (egcs-990517). Desde entonces existe en el árbol un segundo snapshot (egcs-990608). Si viene de la versión "vainilla" 2.5, es muy probable que no pueda compilar la última versión directamente. En este caso tendrá que arrancar con una versión intermedia siguiendo estas instrucciones:
De espie@openbsd.org:
Si pasó este procedimiento y todavía funciona todo, felicidades. Si no, busque consejo en las siguientes secciones. Los problemas que no aparezcan aquí se deben enviar a tech@openbsd.org.Hoy cambia el compilador. Sale gcc 2.8.1, entra egcs ... o para ser más exactos, la versión previa de gcc 2.95. Probablemente esto suponga un duro cambio, pero no puedo calcular todos los detalles para todas las arquitecturas yo solo. Voy a empezar a importar partes *ahora*. Enviaré un segundo mensaje a tech@ una vez todo esté asentado... Gracias a todos los que me ayudaron a ordenar las partes, de forma especial a niklas, turan, y millert. Porqué del cambio ----------------- como muchos ya sabrán, egcs es ahora el compilador *oficial* soportado por la FSF. La futura versión de julio ha sido renombrada gcc 2.95. Simplemente mirando a los mensajes se pueden ver muchas mejoras: el soporte para nuevos procesadores es mejor, C++ se acerca más a las normativas ANSI/ISO, Fortran 77 se encuentra más integrado. También hay una inmensa cantidad de errores solucionados y mejoras en la generación del código. Además, el desarrollo es más abierto. Hay un árbol de cvs, varias listas de correo, y estamos cooperando más con el equipo de egcs. Para ser más exacto, he estado enviando parches al equipo de egcs, para que las configuraciones de OpenBSD estén soportadas oficialmente. También, el equipo de desarrollo ha respondido con frecuencia a los informes de errores, y los problemas se solucionan. También hay un fenómeno a tener en cuenta: todo el mundo está cambiando a egcs, lo que se traduce en montones de código para probar el compilador, y que podemos beneficiarnos de proyectos relacionados. Porqué ahora ------------ egcs-1.1 no estaba preparado para algunos propósitos. En concreto, el tamaño del código en i386 era mayor que gcc 2.8.1, lo que resultaba en problemas con los disquetes. En el momento de «congelar» 2.5, el único código que se podía incluir era un snapshot algo inestable. En interés de la estabilidad, después de considerarlo mucho, egcs no fue incluido en 2.5. Ahora, el proyecto egcs está en un ciclo de lanzamiento que acabará en egcs 1.2. Juzgando por su programa de tiempo en el proyecto, existe un amplio margen entre egcs 1.2 y el lanzamiento de la próxima versión de OpenBSD. Además, queremos empezar ahora para que podamos tener la oportunidad de enviar informes sobre problemas en arquitecturas de uso menos frecuente, y tenerlo todo solucionado para la versión 1.2. La `congelación de las funcionalidades' de egcs está programada para el 7 de mayo, y en el snapshot actual 19990502 parece sólido. Qué funciona y qué no --------------------- egcs funciona en los sistemas OpenBSD para i386 sin problemas. m68k también funciona, con algunos arreglos relacionados con errores extraños que serán solucionados. sparc también parece funcionar bien. Hay algún problema con el enlazador en algunas otras arquitecturas que necesita ser solucionado antes de nuestro próximo lanzamiento. En este momento, los constructores a través de bibliotecas dinámicas todavía no está preparados. egcs ahora dispone de un cpp propio que va a ser mejor que la actual solución que usamos. Esto significa unos pocos cambios en la interfaz y probablemente avisos extraños. ¿Mantener gcc 2.8.1? -------------------- debido a restricciones de tamaño, en cuanto se importe egcs, gcc pasará al Ático del cvs. Si no quiere tener egcs ahora, deberá tener cuidado en sus actualizaciones de cvs. Algunos ficheros Makefile están ligados al cambio: includes, gnu/usr.bin, y gnu/lib. xlint y cpp.sh también cambiarán. Cómo arrancar el compilador --------------------------- el modo más simple es probablemente confiar en los varios mantenedores de las arquitecturas y bajarse un snapshot. Si quiere hacerlo del modo difícil, primero debe volver a compilar directorios obj adecuados: cd /usr/src make obj Si su arquitectura es i386, gas debe estar actualizado. Si su arquitectura en sparc, ld debe estar actualizado. y compile libiberty: cd /usr/src/gnu/egcs/libiberty make -f Makefile.bsd-wrapper clean make -f Makefile.bsd-wrapper depend make -f Makefile.bsd-wrapper make -f Makefile.bsd-wrapper install y el compilador de C: cd /usr/src/gnu/egcs/gcc make -f Makefile.bsd-wrapper clean make -f Makefile.bsd-wrapper depend make -f Makefile.bsd-wrapper make -f Makefile.bsd-wrapper install recompile el compilador de C con la nueva versión: cd /usr/src/gnu/egcs/gcc make -f Makefile.bsd-wrapper clean make -f Makefile.bsd-wrapper depend make -f Makefile.bsd-wrapper make -f Makefile.bsd-wrapper install recompile los ficheros include: cd /usr/src/include make includes compile todas la bibliotecas de egcs e instálelas: cd /usr/src/gnu/egcs make -f Makefile.bsd-wrapper clean make -f Makefile.bsd-wrapper depend make -f Makefile.bsd-wrapper make -f Makefile.bsd-wrapper install instale el nuevo controlador de cpp: cd /usr/src/usr.bin/cpp make install y ya está preparado; un make build normal debería funcionar...[nota del autor: en realidad no funciona del todo. xlint no compilará. Sin embargo, la solución es simple. Ejecutemake && make installen el directorio/usr/src/usr.bin/xlint/xlintantes de ejecutarmake buildy proceda. Vea la sección 4.2.2.]Si no funciona es porque está usando una arquitectura que no ha pasado por make build todavía. Lo más lógico es que sea un «Error Interno del Compilador» (ICE, "Internal Compiler Error"). Primero intente ver si el ICE desaparece con -01 ó -00. En ese caso, puede hacer un arreglo en el fichero Makefile hasta que sea solucionado (vea /usr/src/lib/libm/Makefile para un ejemplo de cómo hacer estos arreglos en m68k). Entonces debe enviar un informe sobre el error a la lista de correo de egcs-bugs. Como mínimo, debe compilar los fuentes con la misma invocación que para el compilador, añadiendo -v -save-temps a las opciones. -v muestra la secuencia exacta de órdenes invocadas por gcc. -save-temps le dará un fichero preprocesado de C (.i) o de C++ (.ii) que los desarrolladores de egcs pueden entender... no les pida que instalen OpenBSD en sus máquinas. Si dispone de más tiempo, puede intentar recortar el fichero preprocesado de C al mínimo indispensable que haga saltar el error. La dicotomía funciona bien.
Esto es cierto. egcs usa __i386__ y __sparc__ que son de código más limpio. Si necesita compilar código que dependa en los viejos define, añada -Dsparc o -Di386 a la ubicación apropiada del fichero Makefile.
Esto se debe a diferencias semánticas en cpp. La solución es fácil y parecida al problema de cap_mkdb descrito en la sección 3.1.
Haga lo siguiente:
# cd /usr/src/usr.bin/xlint/xlint # make && make installahora vuelva a ejecutar 'make', y la compilación debería continuar.
De: Marc Espie <Marc.Espie@liafa.jussieu.fr>
Asunto: egcs core-dumping on uthread_autoinit.c
Si le ocurre esto, es un conocido problema del enlazador... el cc1 que tiene
fue enlazado en un modo extraño.
Al principio hice un enlace cc1 contra /usr/lib/libiberty.a estático,
para evitar este problema; pero esto sólo era temporal y el error
reaparecía, probablemente debido a cambios relacionados con libc u
otros...
El árbol ha sido parcheado con un arreglo en
src/gnu/egcs/f/lang-options.h
asegúrese de que tiene la versión parcheada de ese fichero (por
lo menos la revisión 1.2), recompile y reinstale cc1; el problema
debería desaparecer.
Lo que ocurre es que el enlazador de 386 se equivoca debido a la cadena de
vectorial en toplev.c, y algo se desenlaza, de modo que
void f(void) __attribute((constructor)) {}
mata cc1.
Como solución temporal, he matado los textos de ayuda de las opciones
de Fortran, hasta que alguien encuentre dónde comete el error el
enlazador.
Lo es, pero existe un motivo. egcs actúa optimizando más pases. La alineación de los datos y otras funcionalidades semejantes mejorarán el código generado por egcs.
Sí, lo hace. Esto se nota especialmente con el viejo conmutador -O2 de gcc. egcs introduce una nueva opción, -Os, que optimiza el espacio. Estos es comparable a grandes rasgos con el viejo comportamiento -O2.
egcs se instala en un subdirectorio distinto al de gcc 2.8.1. Una vez que egcs haya arrancado y funcione, puede eliminar gcc. (a propóposito de esto, los cambios en perl mencionados en la sección 4.1 significan que puede eliminar el directorio /usr/lib/perl5. La nueva ubicación para estos datos es /usr/libdata/perl5).
libcurses se apoya ahora en la última versión de cpp. Obtenga la última versión, recompile cpp, y continúe. Por ejemplo:
# cd /usr/src/usr.bin/cpp && make installY vuelva a intentar 'make build'.
Si make obj falla, nombrando errores en un Makefile, los include de makefile es posible que estén obsoletos. Por ejemplo:
===> lib/libkvm
"Makefile", line 30: Malformed conditional ((${UVM} == "yes"))
"Makefile", line 30: Missing dependency operator
"Makefile", line 32: if-less endif
"Makefile", line 32: Need an operator
Fatal errors encountered -- cannot continue
Esto se puede resolver recompilando los ficheros include de makefile:
cd /usr/src/share/mk && make installe intente compilar de nuevo.
Respuesta corta:
La estructura statfs del núcleo ha cambiado. Necesita recompilar el núcleo antes de intentar un make build.
Respuesta larga:
La estructura statfs del núcleo ha cambiado. La nueva struct statfs tiene las siguientes funcionalidades:
Cuando actualice a la versión 2.6 necesitará crear un enlace simbólico para gcc.
cd /usr/lib/gcc-lib
ln -s ${ARCH}-unknown-openbsd2.5 ${ARCH}-unknown-openbsd2.6
tar: Unable to remove directory ./usr/include/machine <Directory not empty>
En la versión 2.5 /usr/include/machine era un directorio, y /usr/include/i386 era un enlace a ese directorio. En la versión 2.6 esta situación se ha revertido.
Para corregir el problema, escape a la shell, elimine el directorio /usr/include/machine, y vuelva a intentar actualizar.
Existe un nuevo fichero termcaps.master. Necesitará regenerar los ficheros terminfo y termcaps con la versión actual de tic(1). Si está actualizando a través de make build, se usará la versión correcta de tic(1) y regenerará los ficheros por usted. En caso contrario, verá el siguiente error:
terminfo.src is corrupt! You need to update /usr/bin/tic
En tal caso, debe recompilar e instalar tic(1) (asegurándose de utilizar la versión actual de libcurses), o simplemente compilar la versión de tic(1) en su árbol de fuentes.
(Nota: en algunas partes de esta sección se usa sólo pn para simplificar. La información es igualmente aplicable a pn, mx, al, o ax, según el caso)
Estos cuatro controladores han sido substituidos por el controlador unificado dc. Debe cambiar cualquier mención a pn*, mx, al, o ax en sus ficheros de configuración. Esto incluye:
Si no está modificando un núcleo personalizado, asegúrese de haber incluido el dispositivo dcphy en la configuración del núcleo, de la siguiente forma:
dcphy* at mii? phy ? # PHYs Clónicos de Digital
Mientras está en ello, también puede añadir:
ukphy* at mii? phy ? # PHYs "desconocidos"
gcc 2.95.2 se fusionó en el árbol de fuentes de OpenBSD alrededor del 19 de enero de 2.000. Para que gcc compile correctamente, se requiere una versión más reciente de la biblioteca libiberty (post 2.6). Para compilar esta biblioteca, haga lo siguiente:
cd /usr/src/gnu/egcs/libiberty make -f Makefile.bsd-wrapper clean make -f Makefile.bsd-wrapper obj make -f Makefile.bsd-wrapper make -f Makefile.bsd-wrapper installNOTA: En las arquitecturas basadas en mips, como pmax, debe llevar a cabo un ldconfig explícito después de compilar las nuevas bibliotecas.
Una vez compilada libiberty, puede proceder con un arranque típico de gcc:
cd /usr/src/gnu/egcs/gcc make -f Makefile.bsd-wrapper clean make -f Makefile.bsd-wrapper obj make -f Makefile.bsd-wrapper -DBOOTSTRAP make -f Makefile.bsd-wrapper -DBOOTSTRAP install make -f Makefile.bsd-wrapper clean make -f Makefile.bsd-wrapper make -f Makefile.bsd-wrapper install
Para que Kerberos IV compile correctamente, necesita seguir estas instrucciones:
# cd /usr/src/usr.bin/compile_et # make clean && make depend && make && make install
# cd /usr/src/lib/libcom_err # make clean && make depend && make && make install
# rm -r /usr/include/kerberosIV/* # cd /usr/src/kerberosIV # make includes
# cd /usr/src/kerberosIV/lib # make clean && make depend && make && make install
# cd /usr/src/kerberosIV # make cleandir && make depend && make && make install
La versión de m4 incluida en OpenBSD 2.6 se engancha en un bucle infinito mientras procesa los ficheros .mc de sendmail en ficheros .cf. Debido a esto, necesitará instalar la nueva versión de m4 antes de intentar un 'make build'. En otras palabras:
# cd /usr/src/usr.bin/m4
# make && make install && make cleandir
En sendmail 8.10.X, las ubicaciones (y nombres) de los ficheros de configuración de sendmail han cambiado. Ahora todo, excepto el fichero pid, se encuentra en /etc/mail. Además, varios ficheros han cambiado de nombre.
| VIEJO | NUEVO |
| /etc/sendmail.cf | /etc/mail/sendmail.cf |
| /etc/sendmail.cw | /etc/mail/local-host-names |
| /etc/sendmail.ct | /etc/mail/trusted-users |
| /etc/sendmail.oE | /etc/mail/error-header |
| /etc/aliases | /etc/mail/aliases |
| /etc/service.switch | /etc/mail/service.switch |
| /etc/userdb | /etc/mail/userdb |
| /usr/share/misc/sendmail.hf | /etc/mail/helpfile |
Hay un par de maneras para convertir la vieja configuración de sendmail a la nueva, pero el primer paso es siempre el mismo.
include(`../m4/cf.m4')ya que la habrá incluido 'make'. Note también que, a partir de ahora, cuando añada máquinas a la clase w (mediante "Cw nombredemáquina"), tendrá que hacerlo en la sección LOCAL_CONFIG (vea como ejemplo openbsd-lists.mc).
Se produjo un cambio significativo en gcc gracias al cual es muy fácil generar bibliotecas libc de auto-referencia. A causa de este cambio, las actualizaciones deben seguir el siguiente procedimiento al pie de la letra:
$ cd /usr/src/gnu/usr.bin/ld $ make clean && make obj && make $ sudo make install
$ cd /usr/src/sys/arch/`machine`/conf $ config GENERIC $ cd ../compile/GENERIC $ make clean && make depend && make
# echo "lookup file bind" >> /etc/resolv.conf
# cd /usr/src/sys/arch/`machine`/compile/GENERIC # mv /bsd /bsd.old # mv bsd /bsd # chown root.wheel /bsd # shutdown -r now(si este paso fallara, puede recuperarlo arrancando con el núcleo viejo - bsd.old - desde el punto de pedido boot>)
$ cd /usr/src/usr.bin/make $ make clean && make obj && make depend && make $ sudo make install $ cd /usr/src/share/mk $ sudo make install
$ cd /usr/src/etc/mtree $ sudo install -c -o root -g wheel -m 444 4.4BSD.dist /etc/mtree $ sudo mtree -qdef /etc/mtree/
# cd /usr/src && make build
auth:*:11:
--
Originally [OpenBSD: upgrade-minifaq.html,v 1.42 2000/12/29 15:28:52 aaron Exp ]
$Translation: upgrade-minifaq.html,v 1.10 2001/01/03 21:09:30 horacio Exp $
$OpenBSD: upgrade-minifaq.html,v 1.10 2001/01/04 05:20:09 jufi Exp $
Copyright © 1998-2001, Kjell Wooding.
Por favor, envíe cualquier comentario, pregunta o sugerencia a
kjell@openbsd.org