Preguntas frecuentes sobre la compilación de Mozilla

Mira también:

Debugging Mozilla on Windows FAQ: Consejos para depurar Mozilla en Windows

Preguntas Generales

Que plataformas soportan Mozilla?

Hay varios niveles o grados de "soporte" para Mozilla:

Grado-1 son las plataformas en las cuales se centra el desarrollo. Los problemas en estas plataformas son considerados primordiales. También son las plataformas que se muestran en SeaMonkey tinderbox page.

Las Grado-1 son:

linux/x86 (gcc)
win32/x86 (msvc)
OS X (gcc)

Grado-2 son las plataformas en las que hay algunos desarrolladores y contribuyentes activos, pero que la mayor parte del desarrollo no se centra en los problemas. Nos referimos a estas plataformas como los Puertos y la mayoría se encuentran en SeaMonkey-Ports tinderbox page.

Estas son:

aix 4.3 (aCC)
beos 5.0.3 (gcc)
bsdi 4.x (gcc)
hpux 10.x,11.x (HP cc)
irix 6.x/gcc (gcc/MIPSpro)
linux/ppc (gcc)
os/2 (gcc)
osf1 5.x (Compaq cc)
solaris (sparc & x86) 2.6+ (gcc/Forte)

Grado-3 son aquellas en las que casi no hay desarrollo activo por la mayor parte de los desarrolladores pero que hay algunas soluciones contribuidas por terceros.

Las Grado-3 son:

freebsd (gcc)
linux/alpha (gcc)
netbsd (gcc)
openvms (?)
ps2linux (gcc)
qnx 6 (gcc)
win32/x86 (gcc)

Las demás plataformas "no son soportadas" por Mozilla. En realidad "no soportada" quiere decir que no hay gente trabajando activamente en eso y que no son una prioridad.

La mayoría de los desarrolladores no tienen acceso a las plataformas que no sean Grado-1; así que cualquier bug reportado en una plataforma que no sea Grado-1,debería poseer bastante información para ayudar al responsable del bug a determinar la causa y brindar una solución apropiada. Si puedes proporcionar un parche y/o verificar que el parche del desarrollador funciona en tu plataforma, puedes ayudar a muchos a verificar y arreglar sus bugs.

Qué tipo de sistema de compilación usa Mozilla?

Mozilla usa para todas las plataformas una delgada capa de configuración GNU sobre el legado de sistema de makefile recursivo de Netscape. Como la mayoría de los proyectos configure-based, utiliza GNU autoconf para generar el script de configuración. GNU make se utiliza para manejar el proceso de compilado.

Por qué usa GNU?

GNU make ha sido exportado a muchos sistemas. Esto hace que exportar Mozilla a esos sistemas sea un poco más fácil. Utilizando las características de make, que son soportadas por el programa nativo make en 10 plataformas diferentes, se logra que el sistema de compilado no sea innecesariamente complicado.

Funciona otra versión de make?

No. El makefiles Mozilla utilza características propias de GNU make que, obviamente, sólo funcionan con GNU make.

Por qué no usa automake?

Parte del legado de Netscape involucra utilizar el make de GNU. Tiene características para incluir un conjunto de reglas comunes desde un puñado de archivos en cada Makefile que necesite usarlas. También, hoy en día el método de generación de librerías de Mozilla no funciona bien con libtool.

Qué les sucedió a nmake y al sistema de compilado CodeWarrior?

Ya no existen. El soporte para nmake se dejó durante la distribución de Mozilla 1.2a. El sistema mac cfm se abandonó con el soporte para OS9 poco después de la liberación de Mozilla 1.3

Por qué no ant, tmake, scons o inserte su sistema favorito aquí?

Principalmente porque nadie los utiliza en Mozilla. Cuando Mozilla empezó a ser de código abierto, sólo contenia el legado de Netscape. Autoconf se integró en una rama y se mantuvo en paralelo durante 6 meses antes de convertirse en el sistema standard para unix.

Si deseo utilizar mi sistema favorito,¿ lo empezarìan a usar en Mozilla?. No quiero perder mi tiempo si no lo van a usar.

No hay garantías de que cualquier código escrito para Mozilla sea aceptado en árbol por defecto. Todo sistema que se desee utilizar debe demostrar ser mejor que el sistema actual. Velocidad, flexibilidad, portabilidad y la capacidad de que un gran grupo de desarrolladores- que tiene 3 años o más de experiencia- pueda cambiarlo facilmente, son los principales factores que deciden el cambio. Si hablas en serio y vas a realizar mucho trabajo, contacta a User:Benjamin Smedberg para discutir los detalles.

Por qué Mozilla no soporta autoconf 2.5x?

Simplemente porque autoconf 2.5x no ofrece nada para que los esfuerzos por actualizar valgan la pena. Autoconf 2.5x no es compatible con 2.13 y las restricciones adicionales hechas en las nuevas versiones de autoconf requirirían reescribir gran parte del código- sistema de compilado de Mozilla.

Algunas características de 2.13, como la posibilidad de pasar argumentos adicionales para sub-configuración, no están disponibles en 2.5x. Varios han preguntado por estas características en las listas de correos de autoconf y no han obtenido respuestas favorables. No es conveniente reescribir las configuraciones para subprojectos de Mozilla (NSPR & LDPA).

Por qué NSS no usa aurtoconf?

El projecto NSS también es utilizado fuera de Mozilla, y los miembros del mismo creen que cambiar a autoconf no vale la pena. Mira bug 52990 para más detalles.

Puedo compilar múltiples proyectos basados en Mozilla desde un único árbol-fuente?

Sí!, cada projecto debe ser compilado en su propio objdir.

Qué es un objdir?

Un objdir se refiere a crear los archivos de salida en un directorio distinto al que se encuentran las fuentes. Es un estándar en la mayoría de los proyectos basados en configuración. Te permite, desde un único árbol-fuente, compilar para múltiples configuraciones, incluyendo varias plataformas si trabajas en un sistema de archivos de red. También elimina la corrupción de tu árbol-fuente, de esta manera sabes que los archivos en el árbol no han sido modificados en el proceso de compilado.

Si ejecutas configure manualmente, puedes usar el método estàndar de crear un directorio vacío en cualquier parte de la unidad, y luego entrar a ese directorio y ejecutar path/to/mozilla/configure.

mkdir obj-debug
cd obj-debug
../mozilla/configure

Si usas client.mk, puedes agregar lo siguiente al .mozconfig:

mk_add_options MOZ_OBJDIR=/path/to/objdir

Puedo multi-compilar Mozilla?

Sí, mira el documento Cross-Compiling Mozilla. No soporta Canadian Cross-Compiling.

Cómo puedo compilar sólo ciertos archivos para pruebas, en lugar de compilar todo el árbol, mientras modifico el código?

Entra en el directorio objdir, luego vè al directorio especifico que deseas compilar (la estructura del objdir coincide con la estructura de los directorios de las fuentes), y tipea "make". Sólo funciona si encuentras un directorio que tenga un Makefile (el equivalente en el árbol fuente tandrá "Makefile.in". Si quieres algo más especifico que eso puedes probar con "make <nombrearchivo>.obj". Mira Incremental Build.

Funcionan las compilaciones paralelas (make -j) en Mozilla?

Sí, mira GNU Make Parallel Execution para su uso óptimo.

Si obtienes errores de compilación al utilizar aquello (sobre todo cuando usas -j en lugar de -jN), prueba reduciendo el número de paralelismo disminuyendo el valor de N (o, si usaste paralelismo ilimitado, agrega un número pequeño N a -j)

La compilación en paralelo con -j4 y -j8 parece funcionar.

Cómo fuerzo al sistema de compilación para aceptar cualquier cambio hecho a mi archivo .mozconfig?

Toca cualquiera de los scripts de configuración en el árbol. No hay dependencia sobre el archivo mozconfig; el archivo puede encontrarse donde sea a tráves de la variable de entorno MOZCONFIG.

error: file '../../toolkit/locales/en-US/chrome/necko/contents.rdf' doesn't exist at ../../config/make-jars.pl line 418, <STDIN> line 9.

Estás tratando de compilar Firefox sin seguir las intrucciones sobre cómo Configurar las opciones de compilación. En particular, tu mozconfig debe contener el mozconfig por defecto de Firefox:

. $topsrcdir/browser/config/mozconfig
# add your custom additional options here

Initial cvs checkout fails with the message: cvs [checkout aborted]: *PANIC* administration files missing

No puedes crear un árbol CVS debajo de un directorio llamado "CVS". Es una característica/bug de CVS. CVS espera encontrar cierta administración de archivos debajo del directorio CVS y no funciona si no la encuentra.

Error: ../coreconf/rules.mk:406: target `c' doesn't match the target pattern

Necesitas make 3.80 y no otras versiones como 3.81

make 3.80 ya no está disponible en el instlador de Cygwin, así que lo deberás encontrar por ti mismo. Puedes buscarlo en google como make-3.80-1.tar.bz2, también está disponbleaquí.

Preguntas específicas sobre Mac

Puede compilar una aplicación Mozilla como un binario universal?: Sí, mira Mac OS X Universal Binaries.
Cómo puedo usar distcc para ayudar a compilar?: TBA.
Mozilla compila UFS?: Sí, ha sido arreglado desde bug 157036.
Mozilla corre sobre UFS?: Sí.
Puedo usar CodeWarrior para compilar Mach-O?: No, CodeWarrior murió. Mira bug 119589.
Luego de re-compilar, ej. layout. Cómo hago que mi FirefoxDebug.app refleje el cambio?: make -C browser/app.

Para errores comunes en Mac y consejos adicionales sobre solución de problemas. Mira solución de problemas en Requerimientos para la compilación en Mac OS X.

Preguntas sobre Win32

Existe un archivo de proyecto Microsoft Visual Studio para compilar Mozilla?

No. Debes usar cygwin y GNU make.

Puedo correr los comandos para compilar desde cmd.exe?

Sí. Make llama la subshell cygwin /bin/sh para ejecutar el comando, así que no hay problema sobre cual shell uses para llamar a make.

Qué versión del paquete de autoconf de cygwin debo usar?

Debido a las incompatibilidades entre autonconf 2.1x y 2.5x, la gente de cygwin escribió un script (wrapper) que determinará qué versión necesitará tu script de configuración y llamará a esa versión. Necesitarás los paquetes autoconf(-wrapper) y autoconf estable. Mira https://cygwin.com/ml/cygwin-announce.../msg00177.html para más detalles

Las herramientas de Microsoft (CL, LINK, RC) tiran error File not found

Las variables de entorno INCLUDE y LIB son usadas por las herramientas de Microsoft Visual C++. Comúnmente están configuradas en vcvars32.bat. Tal vez necesites o no MFC y ATL, dependiendo de qué modulos estés compilando. Debajo hay paths que funcionan si Visual C++ está instalado en "C:\msvs"

set INCLUDE=C:\msvs\VC\Include;C:\msvs\VC\ATLMFC\Include
set LIB=C:\msvs\VC\Lib;C:\msvs\VC98\ATLMFC\Lib

cvs update: authorization failed: server XXXX rejected access -- used empty password; try "cvs login" with a real password

Estás mezclando wincvs y cygwin cvs. Usa uno o el otro.

cvs [checkout aborted]: cannot rename file CVS/Entries.Backup to CVS/Entries: Permission denied

En cygwin 1.3.13, ntsec está activada. ntsec es un intento de cygwin por obtener una estructura de permiso mas similar a UNIX sobre características de seguridad que Windows NT. El mensaje de error indica que hay una discrepancia de mapeo entre los permisos de unix listados en el archivo de cygwin /etc/password y los usados por Windows NT. Puedes agregar "nontsec" a tu variable de entorno CYGWIN. Para arreglarlo de forma adecuada deberías solucionar el problema de mapeo.

Al descomprimir, no se encuentra un archivo .dtd

Probablemente usaste Winzip para descomprimir los archivos. No hagas eso. Por defecto, Winzip no extrae los archivos sin longitud (0 bytes). Usa otro utilitario.

nsinstall u otro programa nativo win32 no encuentra un archivo

Revisa tu tabla de subida. Ejecuta el comando de montura, deberia devovler algo como esto:

c: on /cygdrive/c type user (binmode,noumount)
e: on /cygdrive/e type user (binmode,noumount)
c:\cygwin on / type system (binmode)
c:\cygwin\bin on /usr/bin type system (binmode)
c:\cygwin\lib on /usr/lib type system (binmode)

El sistema de compilado espera que las particiones del disco hayan sido montadas usando /cygdrive como prefijo de la unidad. Si C: o E: no usan /cygwin como prefijo de unidad no podrás compilar Mozilla en esas unidades. Debes montar la unidad manualmente usando:

mount -s "e:\" /cygdrive/e

Si tu árbol fuente está debajo de tu $HOME, el modo de montura debería ser binmode (finales de líneas estilo Unix), de otro modo fallará al compilar. Si el árbol está fuera de tu $HOME, no importa el modo de montura siempre y cuando tu editor reconozca finales de linea estilo Unix.

No such file or directory errors from lines in your mozconfig

This can be caused by your mozconfig file having Windows-style line endings. Convert them to UNIX-style and the error should go away.

xpidl.exe cae con una violación de acceso

Usualmente ocurre por una discordancia entre tu compilador y tus librerías glib y/o libIDL.

Si compilas con Visual Studio .NET, debes enlazar con las version de VC7 de las DLL glib y libIDL. Para Visual Studio .NET 2003, usa las versiones VC7.1. Para Visual Studio 2005, usa VC8.

El directorio que contenga esas versiones de librerías para tu compilador debe estar en tu PATH antes que cualquier otra versión de las mismas librerías. Los archivos .dll y lib deben ser ejecutable o cygwin no los cargará.

Mira los Requerimientos para la compilación en Windows sobre más consejos para compilar con VC7 o superior.

También en bug 242870 se encuentran disponibles algunas librerías estáticas que pueden ser usadas en lugar de las librerías específicas del compilador.

Si compilas con VC6, debes asegurarte que no estás usando las librerías de VC7 a la hora de compilar o ejecutar.

configure: error: the midl major version, , does not match the compiler suite version, <Visual C++ nro de versión> -- lo mismo para el linker

TLa herramienta cygwin "link.exe" para enlazar no reconoce el objeto enlazador de la suite del compilador Microsoft, o no se encuentra midl. Asegúrate que las herramientas de Microsoft se encuentran antes que cygwin en el PATH (Mira las intrucciones), o renombra o quita el archivo /bin/link.exe. Nota que cygwin tal vez modifique el path cuando arranque su shell, asi que también mira export.

configure: error: installation or configuration problem: C compiler cannot create executables.

Prueba asegurándote que la variable PATH incluya todos los directorios necesarios. Si usas MS Visual Studio, ejecuta vcvars32.bat (que configura las variables PATH, LIB, y INCLUDE). Si tu entorno ha cambiado, tal vez debas eliminar el archivo config.cache (en el directorio mozilla o directorio objeto) y luego volver a compilar.

build error: ../coreconf/rules.mk:365: target `c' doesn't match the target pattern

Has usado make 3.81 del instalador cygwin. Debes usar make 3.80. Por favor lee las instrucciones.

fatal error LNK1112: module machine type 'IA64' conflicts with target machine type 'X86'

Prueba cambiando el orden de los directorios en las variables PATH, LIB e INCLUDE. Cambia cualquier directorio que incluya cerca del final: "win64" o "IA64" (o "AMD64").

LINK : fatal error LNK1104: cannot open file 'atlthunk.lib'

De acuerdo con this Microsoft forum thread, hay una versión diferente de Active Template Library (ATL) para Platform Software Development Kit -libre- (PSDK), que para Visual Studio. La ATL en el PSDK no soporta código 32-bits, sólo 64-bits; mientras que Visual Studio soporta ambas y no requiere atlthunk.lib. Aparentemente el archivo atlthunk.lib no está disponible y no se pudo compilar desde freely available tools, incluyendo las herramientas Visual C++ y Visual Studio Express. De todos modos puedes actualizar a la versión full de Visual Studio y utilizar la versión de ATL del mismo, o puedes trabajar en el problema cambiando algunos códigos en atlbase.h (en \include\atl debajo del directorio PSDK). Ejemplo:

--- atlbase.h.old       2006-06-08 08:20:26.671875000 -0400
+++ atlbase.h   2006-06-08 08:13:26.578125000 -0400
@@ -283,7 +283,7 @@
         }
 };
 #pragma pack(pop)
-
+/*
 PVOID __stdcall __AllocStdCallThunk(VOID);
 VOID  __stdcall __FreeStdCallThunk(PVOID);

@@ -291,6 +291,11 @@
 #define FreeStdCallThunk(p) __FreeStdCallThunk(p)

 #pragma comment(lib, "atlthunk.lib")
+*/
+
+// workaround for not having atlthunk.lib in PSDK or VC++ 2005 Express Edition
+#define AllocStdCallThunk() HeapAlloc(GetProcessHeap(),0,sizeof(_stdcallthunk))
+#define FreeStdCallThunk(p) HeapFree(GetProcessHeap(), 0, p)

 #elif defined (_M_AMD64)
 #pragma pack(push,2)

También hubo que borrar el directorio objeto y volver a compilar desde el principio, de modo que el compilador tome el cambio.

Compilar o generar un ejecutable con cygwin y VS6.0 termina en FIND: Parameter format not correct

Hay una confusión entre System32 "find" y /usr/bin/find de cygwin. Lo que queremos es el find de cygwin. Es causado por el orden del path. Algunas posibles soluciones serían:

Renombrar temporalmente system32/find.exe
Asegurarse que en la entrada del path esté primero cygwin que system32

Empaqueté Firefox a través del instalador: make -C ${OBJ_DIR}/browser/installer installer sin problemas. Al ejecutar pide el archivo perdido mozz.dll; la instalación falla.

Tanto Firefox como Thunderbird,deberían compilarse con las etiquetas --enable-static --disable-shared

shlibsign.exe - Entry Point Not Found; El procedimiento CERT_GetFirstEmailAddress no ha sido localizado en la librería nss3.dll.

Tal vez tengas muchos nss3.dll en tu máquina y en tu path. Haz una búsqueda para todas las copias de este archivo. Mueve todas las copias que se encuentren dentro del árbol de Firefox durante la compilación y vuelve a colocarlos cuando se termine la compilación.

Preguntas sobre Mingw32

Si la compilación o la configuración fallan debido a que se perdió w32api, agrega el directorio /include de mingw32 al final de la variable de entorno INCLUDE. Las librerías o binarios mingw32 no deberían ser necesarios, sólo los headers.

Preguntas sobre Unix

Galeon necesita libgtksuperwin.so pero no tengo ese archivo en mi Mozilla gtk2, dónde está?: Sólo Mozilla gtk1 compila libgtksuperwin.so. Si deseas usar galeon con compilación gtk2, debes usar galeon2.
Por qué la configuración dice que necesito libIDL >= 0.6.3 cuando tengo instalado libIDL 0.8.x?: libIdl 0.8.x sólo puede ser usado compilando con gtk2. Por defecto, Mozilla compila con gtk1. Para usar libIDl 0.8.x y gtk2 debes especificar --enable-default-toolkit=gtk2 en la línea de comando de laconfiguración o .mozconfig. NOTA: Esto es viejo y ha sido arreglado en Mozilla 1.8
Cómo compilo en Solaris 10 x86 (SeaMonkey)?: Tuve que hacer lo siguiente para conseguir un entorno que funcione:; 1. instalar forte (Gratis desde Sun); 2. Instalar gmake (desde blastwave); 3. mv /usr/ucb/cc /usr/ucb/cc.hold; 4. CFLAGS="-xlibmil"; exporta CFLAGS; 5. CXXFLAGS="-xlibmil -xlibmopt -features=tmplife -norunpath"; exporta CXXFLAGS; 6. LDFLAGS='-R$ORIGIN -R/usr/sfw/lib -R/opt/sfw/lib -R/usr/local/lib -R/opt/csw/lib'; exporta LDFLAGS; 7. PATH=$PATH:/opt/SUNWspro/bin:/opt/csw/bin:/opt/csw/sbin:/usr/ucb/bin:/usr/ccs/bin; exporta PATH; 8. LD_LIBRARY_PATH=/opt/SUNWspro/lib:$LD_LIBRARY_PATH; exporta LD_LIBRARY_PATH; 9. Crear un archivo mozconfig y compilar normalmente.; 10. La generación del paquete (tar y gzip) falló, así que simplemente lo cree manualmente con los archivos resultantes en el directorio dist.
libxpcom_core.so: cannot restore segment prot after reloc: Permission denied</dt>: Probablemente estés usando Fedora Core 5, o alguna otra distribución de Linux que tiene activado SELinux. Para arreglarlo, utiliza el comando 'chcon -t chcon -t texrel_shlib_t lib*' en el directorio dist/bin.</dd>