Que hay proyectos que son enormemente grandes (aunque nosotros sólo veamos una mínima parte de ello) es algo más que evidente. Como un ejemplo: el navegador Firefox, veterano ya y con muchos miles de líneas de código en sus entrañas.
Es tan grande que, de hecho, está teniendo problemas de nuevo para ser compilado en plataformas de 32 bits. El problema viene de la mano de las librerías compartidas y del linker del compilador, que excede el límite de memoria virtual en las máquinas que se encargan de hacer estas compilaciones. No es la primera vez que se enfrentan a un problema así. Y esta vez la solución no es tan simple como cambiar un parámetro.
¿Qué hará Mozilla para reparar este problema? Tiene tres opciones: usar un sistema de 64 bits para compilar su versión de 32 bits, empezar a utilizar librerías dinámicas como cosacos o empezar a realizar sus compilaciones usando Visual Studio 2010.
Sea lo que sea la solución parece pasar, sobre todo, por aligerar libxul (pasando código a librerías dinámicas). El caso es que no es Firefox el único navegador que sufre/sufrió este problema. Sin ir demasiado más lejos, Chromium también sufrió de este problema (y parece que ahora requiere de más de 4Gb de memoria para ser compilado).
Vía | The H
Más información | mozilla.dev.platform | Bugzilla@Mozilla
Comentarios
Interesante, pero lo que mas me sorprendió es que sea necesario 4Gb de memoria para compilar Chromium.
Son problemas muy comunes en muchos proyectos multiplataforma. Nada nuevo bajo el sol.
Y el usar Visual sería en contra de su Filosofía supongo.... o alguien aclare este punto
brillante
Interesante pregunta, desde el punto de vista de la redacción de la licencia no hay nada que diga como debe ser compilado el programa, pero así como los ecologistas usan transporte público a gasolina y se iluminan con energía eléctrica generada por centrales nucleares si no hay otra solución tendrán que hacerlo
Por curiosidad, tengo entendido que Firefox esta escrito en C++, entonces ¿el compilador de Microsoft para C++ es superior g++? y de ser así como harían para compilarlo en otras plataformas
Firefox siempre se compiló con Visual C++ en Windows. Lo que ocurre es que actualmente usan la versión 2009.
https://developer.mozilla.org/es/Requerimientos_para_la_compilaci%C3%B3n_en_Windows
En otras plataformas se usa g++, y hasta donde sé no han tenido problemas. El inconveniente por lo visto es en las versiones Desktop de Windows de 32bits, cuyo limite de memoria virtual es 4Gb. En plataformas con soporte PAE (Linux, los BSD, o Windows 2008 server) el limite es de 64gb. Nota que PAE no es algo que se use por defecto en ningún sistema.
-- editado por última vez a las 00:13
"Y el usar Visual sería en contra de su Filosofía supongo...."
- Para nada porque su "filosofía" vale tres centavos a la hora de la verdad. Hasta la versión 3 Firefox usaba un crash reporter privativo (Talkback), hasta que lo reemplazó por el de Google (Breakpad). Y ya ni falta hace hablar del tema muy conocido de los logos, marcas y políticas de uso privativas.
Más bien no, ya usan Visual C++ ahora https://developer.mozilla.org/En/Developer_Guide/Build_Instructions/Windows_Prerequisites
La duda es usar la nueva versión del Studio.
Edito: no había visto que atoi ya lo había aclarado. Hasta hemos puesto el mismo enlace jejeje.
-- editado por última vez a las 00:38
Porfa, una explicación para los profanos.
Es que yo tengo más bien ninguna idea de programación y no logro ver el problema, sobre todo con lo de Chromium, que comentáis que necesita 4GB para su compilación: Pregunta estúpida, si 4GB de memoria los tiene en su PC hasta el menos pintado, ¿cuál es el problema?
Saludos!!
Algunas aplicaciones cuando se compilan hacen uso de gran cantidad de RAM. Si esta en 32bits, a veces peta si usas 2gb de ram o 4gb de ram (4gb el maximo direccionable en 32bits).
Como firefox es tan grande, puede dar error al compilar.
Ocurre de manera similar si usas aplicaciones de 32bits en plan photoshop y se zampa más de 2gb de ram. Petará.
Aaah, voy pillándolo.
Y claro, no puedes compilar la versión de 32 bits en una plataforma de 64 bits, ¿correcto?
Gracias!
En realidad si puedes, aunque no todos los compiladores lo soportan. Lo que no se puede es lo contrario.
Por poder, puedes (de hecho en la universidad lo hago a diario: compilo ensamblador para IA32 usando GCC y el parámetro -m32 en un Ubuntu de 64 bits). Lo que no sé es si, como dice #10, el compilador de Visual C++ lo admite en Windows.
Te explico:
En principio te explico un detalle tecnico, un equipo de 32 bits unicamente puede reconocer 3.25 GB de RAM por cuestiones de direccionamiento.
Ahora bien, Firefox se supone que es codigo abierto. Un programa de codigo abierto se basa en una serie de principios: posibilidad de conocer el codigo, de reutilizarlo y de modificarlo. Si nos basamos en eso, un equipo para el que fue desarrollado un programa deberia ser capaz de modificar ese programa y recompilarlo. Aunque haga falta una semana para ello o meterle una ampliacion de memoria.
Ahora nos encontramos con el caso de que un procesador de 32 bits no puede recompilar un programa de 32 bits de codigo abierto y llegamos a un grave problema, porque se ataca a uno de los principios del codigo abierto.
Las primeras versiones de Linux requerian grandes equipos para poder compilarse, incluso con decenas de MB de RAM. El que se pudiera recompilar usando un equipo domestico fue un gran avance.
Por otra parte, se ha alcanzado lo que se podria llamar "un punto de interes". El equivalente a superar la marca de 100 metros lisos en menos de 10 segundos, alcanzar el piso 100 al construir un rascacielos, llevar un año de noviazgo :-) o similares...
Desde Win64 puedes generar programas para Win32 con Visual Studio... porque el compilador sigue siendo de 32 bits. De hecho, para compilar a 64 bit se usa un compilador de plataforma cruzada aunque compiles desde una máquina de 64 bits.
La ventaja de compilar desde una máquina de 64 bits está en que, mediante la "magia" del SysWow64 y no sé qué rollo del "thunking" (o algo así), puedes tener los 4GB completos como memoria real para tu proceso y no la partición 2GB/2GB ó 3/1...
También podrían empezar a hacer limpieza del código porque algo me dice que hay una cantidad de mierda bastante importante y quizás así también logren reducir el consumo de recursos final
Con lo fácil que es en el Visual...
http://img39.imageshack.us/img39/7425/compf.jpg
Hay máquinas muy baratas x64
Sigo sin entender como no se jubilan ya las 32 bits, por favor, si hasta está siendo un incordio para los programadores.
Hagámonos un favor y dejemos a Adobe y Microsoft en sus particulares nebulosas, en donde se han tragado las 64 bits a regañadientes.
Lo que pasa es que empresas e instituciones públicas (así como muchos particulares) no pueden dirigir tan facilmente recursos para actualizaciones masivas de hardware, sobre todo si a lo que usan actualmente todabia le sale jugo. Por eso los cambios son paulatinos y no de "guamazo".
Ya, pero a nivel de hardware las 32 bits pronto llevarán una década en la tumba, con lo que creo que tiempo ha habido para renovar el hardware, al menos que pretendas aguantar 20 años con los mismos equipos, algo que para mi es un despropósito, pero bueno, aun veo muchos equipos funcionando con Windows 2000 que aunque me parezca un buen sistema operativo está lejos de satisfacer las necesidades actuales.
Como ya dije, y me da igual que me cosan a negativos porque es la verdad, si aun andamos con estos software es gracias a dos empresas que debido a un abuso de su posición de monopolio se han negado a ofrecer software nativo de 64 bits. Microsoft vendía Vista con 64 bits, pero la mayoría de los equipos que traían Vista preinstalado eran de 32 bits... EN UN INTEL CORE 2 DUO. Lo de Adobe ya es el colmo y es su culpa el hecho de que los navegadores de 32 bits sigan al pie del cañón. Se negó a dar soporte nativo para 64 bits de su dichoso plugin, algo que los usuarios de GNU/Linux hemos padecido bastante con dos retiradas del plugin cuando aun estaba en fase beta, eso si, la segunda vez el cabreo fue tan brutal que los de Adobe tuvieron que echarse para atrás al día siguiente, ya estaba bien que riesen de nosotros.
Soy un gran detractor de las 32 bits, la considero una tecnología muerta y que actualmente como vemos ofrece demasiadas limitaciones, pero mientras haya gente que se compre un Core iX para meterle Windows XP no tenemos nada que hacer, de hecho hay gente que se queja que su Intel Core 2 Quad va lento y yo les pregunto, ¿qué sistema operativo tienes instalado?, Windows XP me responden, a lo cual digo, pues ya puedes metiendo un Windows 7 de 64 bits si quieres exprimir ese procesador, porque con Windows XP lo estás tirando a la basura, pero la gente raras veces me hace caso, se creen que su CPU o su placa está en mal estado.
De hecho sigue habiendo muchas empresas y oficinas, con sus XP e IE6.
Perdón, pero no entiendo el problema. ¿No pueden costearse una máquina de 4 GiB?
con 32bits el espacio de direccionamiento de la memoria es de 2^32 (que si no me equivoco es un poco menor), por lo que un compilador que necesite más no va a poderse compilar en una máquina de 32 bits
Excelente la respuesta de "Enrike", pero para aclarar un poco mas, quiere decir que los equipos (S.O.) basados en 32 bits, tienen la limitante de solo poder manejar poco menos de 4Gb, es decir por mas Teras de RAM que le coloques a un equipo de estos, simple y sencillamente te reconocerá a lo mucho 4 GB de RAM.
En Linux esto tiene solución agregando un PAE (Physical Address Extension) al kernel, pero en Windows no y en Mac lo desconozco.
Gracias por la aclaración.
Yo pensé que, cuando se hablaba de máquinas de 64 bits se refería al bus de datos, no al bus de direcciones.
En cualquier caso, hay desacuerdos en esto. Según un profesor mío, lo realmente correcto cuando se dice que un procesador es de X bits es referirse al tamaño de los registros del procesador, no a los buses, y no siempre conciden, al menos en procesadores antiguos.
PAE en MSDN Library
Tu profesor -casi- está en lo cierto. No antes, ahora también el bus físico está compartido en muchos procesadores, más que nada por un problema de espacio físico: no caben tantas patas, por lo que se utilizan señales extra para decirles a los componentes qué parte de la dirección/dato vas a sacar, etc.
Lo de los registros no es totalmente cierto, porque hay micros de 8 bits que tienen registros de 16, de 16 que tienen de 8/16/32 y en arquitecturas Hardvard incluso pese a ser de 8 bits el bus tiene 9 ó 10 para poder direccionar más código (hay un Atmel de 8 bits que soporta 256KB de código cuando si fuera puro de 8 sólo podría direccionar 64KB).
En general, se suele decir que un micro de 8 bits tiene un bus de datos de 8 bits aunque esté físicamente multiplexado. En otras palabras: el tamaño de un microprocesador es el tamaño de su dato estándar.
interesante
Los Windows de 32 bits pueden direccionar hasta 8GB de RAM (Mirate las especificaciones de Windows Server 2003 Standard en su versión x86), gracias al PAE (como ya te han dicho).
La limitación viene impuesta por Microsoft, que limita eso en el certificado que controla el núcleo del sistema, impidiendo el acceso al bus de direcciones de 24 bits completo (que direcciona 16GB). La razón es bien sencilla: sólo hay una mínima cantidad de drivers para windows de 32 bits que tengan el ancho de puntero exigido por el PAE, que creo que son 48 bits (para funcionar con el modelo segmentado plano.
En palabras de la calle: si los programadores de drivers no fueran tan chapuceros, podríamos tener windows de 32 bits accediendo hasta 16GB de RAM (con la limitación de los 4GB por proceso).
Si Firefox no fuese monolítico (que estuviera dividido en partes y procesos) no pasaría esto, aunque también el rendimiento sería mucho menos. Realmente es un gran problema. Les aconsejaría a los de Mozilla lo siguiente: Existe un aplicación para hacer posible que las programas de 32 bits sean capaces de manejar hasta 4 GB, así que habría que aplicar este programa al compilador y así poderlo compilar. Salu2
Esto lo escribió una persona ...pero... en el 2006 FF era " intocable e irrespetuoso escribir algo parecido "
" Mozilla: por ahí no sigas ... Pues bien; según Mozilla, en gran parte porque así ha sido solicitado "por sitios web muy populares, que querían una solución a este problema". No cuesta demasiado anticipar lo que hubiera ocurrido si fuera Microsoft quien hubiera ideado semejante disparate para su Explorer. También preocupa pensar qué más peticiones de "sitios web populares" estaría Mozilla dispuesta a complacer.
Tampoco sirve de mucho consuelo pensar que el código es libre y siempre pueden compilarse versiones sin esa funcionalidad, ni confiar en que pronto salgan extensiones que la inhabiliten. Simplemente esperamos otra cosa de Mozilla: que Firefox dificulte el rastreo de los usuarios, no que lo facilite.
Para colmo de males, se dice que las versiones -preliminares- en que ya se ha introducido llevan esta opción habilitada por defecto, como puede comprobarse tecleando about:config en la barra del navegador y observando como el campo browser.send_pings está por defecto a True."
http://www.kriptopolis.org/mozilla-por-ahi-no-sigas
-- editado por última vez a las 09:48
Que hagan como en la época de los dinosaurios, cuando los proces de 8bits solo podían direccionar 65kb: Bank Switching http://en.wikipedia.org/wiki/Bank_switching
Disculpen mi ignorancia pero creo yo que son 4 GB en el disco duro si es 4 GB de ram todas las plataformas compilando al mismo tiempo porque yo estoy compilando el source full de firefox 10 pesa algo de 400 MB y me ocupa 4 GB en el disco duro una ves que esta por finalizar la compilación y solo ocupo 1,8 ram y tengo 4 GB ram ?????
Escribir un comentario
Para hacer un comentario es necesario que te identifiques: ENTRA o conéctate con FacebookConnect