compileren mozilla 1.5 op Debian Testing

[Sir Isaac]

Ik heb een probleem met het compileren van mozilla 1.5 op een Debian Sarge pc met een duron processor. Het lijkt op een bug, maar dat kan ik me niet voorstellen: mozilla wordt veel gebruikt en ik heb een standaard computer.

Daar om wil ik vragen of iemand anders die ook testing draait eens zou willen proberen om mozilla-source-1.5.tar.bz2 te downloaden en te compileren met dezelfde configure regel als ik? Ik heb geen repositories in mijn sources.list staan die voor een niet standaard versie van belangrijke libraries (gtk, glib) zorgen. De md5sum heb ik gecontroleerd. Verder heb ik gecompileerd met g++ 3.2 en 3.3

Ik krijg deze foutmelding:
nsTextFormatter.cpp: In function `struct NumArgState * BuildArgArray(const PRUnichar *, void *, int *, NumArgState *)':
nsTextFormatter.cpp:910: `va_copy' undeclared (first use this function)
nsTextFormatter.cpp:910: (Each undeclared identifier is reported only once
nsTextFormatter.cpp:910: for each function it appears in.)
make[3]: *** [nsTextFormatter.o] Error 1
make[3]: Leaving directory `/mnt/storage/build/mozilla/xpcom/ds'
make[2]: *** [libs] Error 2
make[2]: Leaving directory `/mnt/storage/build/mozilla/xpcom'
make[1]: *** [tier_2] Error 2
make[1]: Leaving directory `/mnt/storage/build/mozilla'
make: *** [default] Error 2

De configure commando regel die ik heb gebruikt is:
./configure --enable-default-toolkit=gtk2 --disable-debug --enable-optimize --disable-tests --enable-crypto --enable-xft --with-system-zlib

In de output van configure staan o.a. deze regels:

checking for an implementation of va_copy()... yes
checking for an implementation of __va_copy()... yes
checking whether va_lists can be copied by value... yes
#define VA_COPY va_copy

Voor geintereseerden heb ik config.log beschikbaar gemaakt: eambrouwer.kabel.utwente.nl/files/config.log

Misschien doe ik moeilijk en mis ik gewoon een package, maar daar duidt de foutmelding wat mij betreft niet op.

[tech-no-logical]

Sir Isaac schreef op 26 december 2003 @ 23:58:
De configure commando regel die ik heb gebruikt is:
./configure --enable-default-toolkit=gtk2 --disable-debug --enable-optimize --disable-tests --enable-crypto --enable-xft --with-system-zlib

In de output van configure staan o.a. deze regels:

checking for an implementation of va_copy()... yes
checking for an implementation of __va_copy()... yes
checking whether va_lists can be copied by value... yes
#define VA_COPY va_copy

mijn configure-opties, exclusief de paden (mozilla 1.5 gecompiled vanuit garnome, ook debian testing) :

--enable-default-toolkit=gtk2 --disable-gtktest --enable-calendar
--enable-mailnews --disable-freetypetest --enable-xft --enable-crypto
--disable-jsd --enable-xinerama --enable-composer --enable-mathml
--disable-installer --disable-tests --disable-debug --enable-optimize
--disable-dtd-debug --disable-pedantic --disable-glibtest --with-system-zlib

compileert feilloos. de output van configure die jij aangeeft heb ik ook. misschien dat de --disable-pedantic nog van belang is ?

[_JGC_]

Waarom zelf compilen uit source als er:
a) backports zijn
b) deb-src pakketten zijn van zowel mozilla 1.5 als mozilla 1.6a

[Sir Isaac]

tech-no-logical schreef op 27 december 2003 @ 02:39:
[...]


mijn configure-opties, exclusief de paden (mozilla 1.5 gecompiled vanuit garnome, ook debian testing) :

--enable-default-toolkit=gtk2 --disable-gtktest --enable-calendar
--enable-mailnews --disable-freetypetest --enable-xft --enable-crypto
--disable-jsd --enable-xinerama --enable-composer --enable-mathml
--disable-installer --disable-tests --disable-debug --enable-optimize
--disable-dtd-debug --disable-pedantic --disable-glibtest --with-system-zlib

compileert feilloos. de output van configure die jij aangeeft heb ik ook. misschien dat de --disable-pedantic nog van belang is ?

Ik heb jouw configure regel overgenomen, maar het resultaat blijft hetzelfde.

[PowerSp00n]

_JGC_ schreef op 27 december 2003 @ 08:46:
Waarom zelf compilen uit source als er:
a) backports zijn
b) deb-src pakketten zijn van zowel mozilla 1.5 als mozilla 1.6a

Als ik ook even mijn mening mag geven , waarom wordt dit nou altijd gezegd. Misschien zijn er wel mensen die graag wat van compilen willen leren, en pakken niet gelijk een pakketje voor een package-manager erbij als het fout gaat. Wees blij dat er ook vanaf de source wordt gecompileerd, fouten moeten toch eens naar boven komen . Gewoon even hoe ik het zie hoor...

[moto-moi]

PowerSp00n schreef op 27 december 2003 @ 22:47:
Als ik ook even mijn mening mag geven , waarom wordt dit nou altijd gezegd. Misschien zijn er wel mensen die graag wat van compilen willen leren, en pakken niet gelijk een pakketje voor een package-manager erbij als het fout gaat. Wees blij dat er ook vanaf de source wordt gecompileerd, fouten moeten toch eens naar boven komen . Gewoon even hoe ik het zie hoor...

Dat is waar, maar Mozilla is een biatch om te compileren, en sowieso houdt compileren meestal niet veel meer in dan ./configure && make && make install , wat je daar nou precies aan wilt leren is beyond me
Natuurlijk kun je allemaal switches meegeven aan configure, maar ook dat is echt kinderspel.

Kijk bijvoorbeeld naar de topicstarter, hij loopt vast. Als je verstand hebt van programmeren, kun je proberen dat probleem op te lossen. Dat doet hij niet, hij geeft alleen een foutmelding, en vraagt waar die op slaat.
Daar leer je bar weinig van, of verwacht je nu van ons complete patches die dit oplossen, als het uberhaupt al een probleem in de source is ?

Hij zou bijvoorbeeld de mozilla sourcefile van Debian kunnen pakken, en dan met diff kunnen gaan kijken of er daadwerkelijk verschillen zijn, en zo ja, wat de verschillen zijn, en deze uitproberen op zijn vanilla kernel.
En raad eens hoeveel tijd dat kost ? Veel, onder andere daarom raadt _JGC_ hem de versie van Debian te pakken.

[PowerSp00n]

moto-moi schreef op 27 december 2003 @ 23:23:
[...]

Dat is waar, maar Mozilla is een biatch om te compileren, en sowieso houdt compileren meestal niet veel meer in dan ./configure && make && make install , wat je daar nou precies aan wilt leren is beyond me
Natuurlijk kun je allemaal switches meegeven aan configure, maar ook dat is echt kinderspel.

Daar heb je natuurlijk ook gelijk in. Het verschilt misschien ook wel wat voor gebruiker je bent of wat voor systeem het is. Maar zelf heb ik er al heel wat aan gehad om gewoon een linux distributie zeer kaal te installeren en zelf software gaan compilen. Het gebeurt regelmatig dat als je iets tegen komt wat niet goed gaat je zoiets ook al tegen bent gekomen bij het compilen van de software of iets wat eromheen te lezen is (documentatie weet ik het wat allemaal) waardoor het probleem weer snel opgelost kan worden.

Kijk bijvoorbeeld naar de topicstarter, hij loopt vast. Als je verstand hebt van programmeren, kun je proberen dat probleem op te lossen. Dat doet hij niet, hij geeft alleen een foutmelding, en vraagt waar die op slaat.
Daar leer je bar weinig van, of verwacht je nu van ons complete patches die dit oplossen, als het uberhaupt al een probleem in de source is ?

Ik verwacht zeker niet dat jullie dat er complete patches geschreven gaan worden . Ik heb net even snel een blik geworpen op Google maar kan ook zeer weinig vinden. Als ik hetzelfde probleem had en het zat me zeer in de weg had ik ook ergens hulp gezocht (al doe ik dat niet echt heel snel maarja ) danwel hier of op een maillinglist. Als daar iemand is die hetzelfde probleem heeft gehad en er meer over kan vertellen valt dat weer onder het leren zoals hierboven genoemd, en daar zijn fora voor toch .

Hij zou bijvoorbeeld de mozilla sourcefile van Debian kunnen pakken, en dan met diff kunnen gaan kijken of er daadwerkelijk verschillen zijn, en zo ja, wat de verschillen zijn, en deze uitproberen op zijn vanilla kernel.
En raad eens hoeveel tijd dat kost ? Veel, onder andere daarom raadt _JGC_ hem de versie van Debian te pakken.

Kan ik je zeker geen ongelijk in geven .

Verder lijkt de topicstarter mij vast wel iemand die niet nieuw is met Debian (of in ieder geval linux) en zal vast op de hoogte zijn dat er overal debian packages van beschikbaar zijn, maar heeft misschien wel een reden om te achterhalen wat het probleem nou precies is.

Maar goed, ik zal ondertussen het regeltje dat ik hierboven zie "Reageer ontopic" wel hebben overtreden. Maar dat is dus wat ik jammer vind (wat ik veel vaker hier voor zie komen) dat er dan maar gelijk naar een debian package wordt gegrepen... Problemen zijn er om opgelost te worden toch?

[moto-moi]

PowerSp00n schreef op 28 december 2003 @ 00:04:
Maar goed, ik zal ondertussen het regeltje dat ik hierboven zie "Reageer ontopic" wel hebben overtreden.

Ik vind van niet hoor
Dit is een afgeleide discussie, maar slaat wel op deze thread, en anders kan ik altijd nog deze subthread uit deze thread halen om er een losstaand topic van te maken

Maar dat is dus wat ik jammer vind (wat ik veel vaker hier voor zie komen) dat er dan maar gelijk naar een debian package wordt gegrepen... Problemen zijn er om opgelost te worden toch?

Dat is waar, maar waarom zou je elk probleem zelf op willen lossen als de problemen al zijn opgelost door (in dit geval een Debian-) maintainer ?

[PowerSp00n]

moto-moi schreef op 28 december 2003 @ 00:41:
Dat is waar, maar waarom zou je elk probleem zelf op willen lossen als de problemen al zijn opgelost door (in dit geval een Debian-) maintainer ?

Juist om er weer wat van te leren. Stel je krijgt het probleem weer op een niet debian machine zonder package manager of waar geen package van beschikbaar is kun je toch het probleem oplossen.

Het is natuurlijk ook per persoon of situatie verschillend hoever je door wil gaan met het zelf uitzoeken en wanneer je voor een package kiest, zelf ga ik liever zo lang mogelijk door tot ik weet wat er fout gaat dan dat ik voor een andere oplossing kies.

En dan krijg je weer waarom er altijd (aan het begin) van een topic al wordt geroepen dat je het met een debian package zo werkend hebt. Kijk als een topic helemaal stil ligt kan ik me heel goed voorstellen van "Joh, misschien is het een beter idee dat je het maar met een debian package installeerd. Dan werkt het direct.".

Eventjes geleden zat ik ook het topic over Qmail te lezen ([rml][ qmail] daemontools probleem.[/rml]), en het viel me hier ook op dat er gelijk geroepen werd (door dezelfde persoon trouwens, niet persoonlijk bedoeld of wat dan ook of zo hoor) dat het ook met Debian is te installeren, ik denk dat de topicstarter zich hier vast wel bewust van is. Wat ook blijkt uit de replie, waarna er weer in een replie wordt vermeld dat het met een debian package direct werkt. Maar volgensmij heeft de topicstarter toch al vermeld dat hij het probleem op wil lossen en niet naar een package wil grijpen.

[moto-moi]

PowerSp00n schreef op 28 december 2003 @ 01:14:
Eventjes geleden zat ik ook het topic over Qmail te lezen ([rml][ qmail] daemontools probleem.[/rml]), en het viel me hier ook op dat er gelijk geroepen werd (door dezelfde persoon trouwens, niet persoonlijk bedoeld of wat dan ook of zo hoor) dat het ook met Debian is te installeren, ik denk dat de topicstarter zich hier vast wel bewust van is. Wat ook blijkt uit de replie, waarna er weer in een replie wordt vermeld dat het met een debian package direct werkt. Maar volgensmij heeft de topicstarter toch al vermeld dat hij het probleem op wil lossen en niet naar een package wil grijpen.

Nou, je zult ze de kost moeten geven die iets willen downloaden, en er nooit bij stilstaan dat er ook gewoon een package voor hun distro te vinden is. Ik persoonlijk installeer voor 99% debian packages, en als ik er geeneen kan vinden, dna maak ik die zelf, kleine moeite, en het zorgt ervoor dat Debian weet dat ik een package heb geinstalleerd, i.p.v. dat ik het zelf moet onthouden, en ik vergeet dat soort dingen altijd.

En wat gebeurt er dan ? Juist, ik installeer het nog een keertje, en dan wordt het altijd een zooitje omdat er packages zijn die zichzelf in /usr neerzetten, terwijl een zelf gecompileerd programma gewoon in /usr/local thuishoort.

[_JGC_]

Tja, waarom je packagesysteem helemaal verneuken door zelf uit source te compilen. Wat betreft dat andere topic: die debian source pakketten werken gewoon perfect, gebruik ze zelf ook voor qmail mailservers. Leuk als je de standaard exim mailserver wilt verwijderen, mag je eerst met equivs een dummy package bouwen voor je je eigen gecompileerde mailserver in de lucht krijgt.

Dingen als garnome kan ik me nog voorstellen, maar een stable release van een mailserver of een webbrowser zou ik toch echt gewoon een package voor nemen.

Overigens stop ik alles in een package, hetzij door de debian sources te nemen, hetzij door zelf met deb-make aan de slag te gaan. Ik wil gewoon geen rotzooi op harddisk hebben slingeren waar de packagemanager niets van weet. Wil je dat wel, dan kan je net zogoed een andere distro gaan zoeken, zoals slackware of LFS.

[PowerSp00n]

moto-moi schreef op 28 december 2003 @ 01:20:
[...]

Nou, je zult ze de kost moeten geven die iets willen downloaden, en er nooit bij stilstaan dat er ook gewoon een package voor hun distro te vinden is.

Dat zal vast en zeker zo zijn .

Ik persoonlijk installeer voor 99% debian packages, en als ik er geeneen kan vinden, dna maak ik die zelf, kleine moeite, en het zorgt ervoor dat Debian weet dat ik een package heb geinstalleerd, i.p.v. dat ik het zelf moet onthouden, en ik vergeet dat soort dingen altijd.

En wat gebeurt er dan ? Juist, ik installeer het nog een keertje, en dan wordt het altijd een zooitje omdat er packages zijn die zichzelf in /usr neerzetten, terwijl een zelf gecompileerd programma gewoon in /usr/local thuishoort.

Dat is natuurlijk het fijne van packages, zelf ben ik Slackware gebruiker en gebruik af en toe wel eens packages (naast die standaard bij de installatie worden geinstalleerd natuurlijk) maar dat is vooral omdat ik alleen heel even iets nodig heb of om iets te proberen. Daarna gaat die package er weer vanaf (wat natuurlijk heel makkelijk is met een package ).

Maar het is natuurlijk wel iets anders dan maar een package gebruiken omdat je het vanaf de source niet voor elkaar krijgt, waar hier dus sprake van is.

_JGC_ schreef op 28 december 2003 @ 01:23:
Tja, waarom je packagesysteem helemaal verneuken door zelf uit source te compilen.

Bijv. omdat het leerzamer kan zijn, maar hier hebben we het hierboven al over gehad.

Wat betreft dat andere topic: die debian source pakketten werken gewoon perfect, gebruik ze zelf ook voor qmail mailservers.

Ik beweer ook nergens dat het niet perfect werkt, maar de een kiest voor een package en de ander voor de source, en zal hier in veel gevallen ook wel een reden voor hebben. En wil dan ook het probleem met het source pakket opgelost hebben.

Ik wil gewoon geen rotzooi op harddisk hebben slingeren waar de packagemanager niets van weet. Wil je dat wel, dan kan je net zogoed een andere distro gaan zoeken, zoals slackware of LFS.

Daar heb je natuurlijk wel gelijk in, maar dat wil nog niet zeggen dat als iemand een probleem heeft met een source pakket op een distributie die een goede package manager heeft maar gebruik moet gaan maken van de package manager.

[ Voor 29% gewijzigd door PowerSp00n op 28-12-2003 01:50 ]

[tech-no-logical]

Sir Isaac schreef op 27 december 2003 @ 13:22:
[...]
Ik heb jouw configure regel overgenomen, maar het resultaat blijft hetzelfde.

hmm.... een beetje zoeken leert dat va_copy bij de GNU C library hoort, en een nogal apart geval is ('t is een macro). zie ook 'man va_start' (als je die hebt).
het enige dat ik me kan voorstellen is dat er een verschil in onze C-libraries is.

ik heb :

code:

peter@fire:~$ dpkg -l | grep libc6
ii  libc6          2.3.2.ds1-10   GNU C Library: Shared libraries and Timezone
ii  libc6-dev      2.3.2.ds1-10   GNU C Library: Development Libraries and Hea

als compilers heb ik overigens :

code:

peter@fire:/usr/share/doc$ dpkg -l | grep gcc
ii  gcc            3.3-1          The GNU C compiler.
ii  gcc-2.95       2.95.4-11      The GNU C compiler.
ii  gcc-3.0        3.0.4-7        The GNU C compiler.
ii  gcc-3.0-base   3.0.4-7        The GNU Compiler Collection (base package).
ii  gcc-3.2        3.2.3-0pre9    The GNU C compiler
ii  gcc-3.2-base   3.2.3-0pre9    The GNU Compiler Collection (base package)
ii  gcc-3.3        3.3.1-0pre0    The GNU C compiler
ii  gcc-3.3-base   3.3.1-0pre0    The GNU Compiler Collection (base package)

waarbij 3.3.1 (en de overeenkomende g++) de default is.

overigens is er maar 1 bugzilla-melding over va_copy, op exact de plek die jij aangeeft, maar da's voor freebsd.

ik heb geen ervaring met de gebruikte functies/macro's, dus verder kan ik je helaas niet helpen.

[tech-no-logical]

_JGC_ schreef op 28 december 2003 @ 01:23:
Tja, waarom je packagesysteem helemaal verneuken door zelf uit source te compilen.
[snip]
Dingen als garnome kan ik me nog voorstellen

wat garnome doet (standaard in een aparte dir installen), kun je zelf vaak ook. 't is vaak erg makkelijk om, _juist_ buiten het packagemanagement om, een nieuwe versie te testen. met packages zit je vaak weer aan een upgrade van 27 andere packages vast, wat in mijn situatie vaak onwenselijk is. probeer dan nog maar 's een succesvolle downgrade te doen als de nieuwe versie niet bevalt.

[_JGC_]

tech-no-logical schreef op 28 december 2003 @ 02:01:
[...]

wat garnome doet (standaard in een aparte dir installen), kun je zelf vaak ook. 't is vaak erg makkelijk om, _juist_ buiten het packagemanagement om, een nieuwe versie te testen. met packages zit je vaak weer aan een upgrade van 27 andere packages vast, wat in mijn situatie vaak onwenselijk is. probeer dan nog maar 's een succesvolle downgrade te doen als de nieuwe versie niet bevalt.

Zelf gebruik ik op dit moment archlinux. Ik onderhoud op dit moment gnome 2.5 voor archlinux zodat bij de 2.6 release er niet van alles en nog wat uitgevonden moet worden. Weet je hoe simpel dat gaat?

PKGBUILD: (vanmorgen nog gebouwd trouwens )

code:

[ "$GNOMEDIR" = "" ] && source /etc/profile.d/gnome.sh
 
pkgname=gnome-vfs
pkgver=2.5.4.1
pkgrel=1
pkgdesc="The GNOME Virtual File System"
depends=('fam' 'bzip2' 'cdparanoia' 'libbonobo' 'gconf' 'openssl')
url="http://www.gnome.org"
groups=('gnome')
install=gnome-vfs.install
source=(ftp://ftp.gnome.org/pub/gnome/sources/$pkgname/2.5/gnome-vfs-$pkgver.tar.bz2 \
        gnome-vfs.install)
md5sums=('cbad0157be2b0f253e53a810b36dcc7f' \
        '140fd039098d5f06049fe277b5017017')
 
build() {
  cd $startdir/src/$pkgname-$pkgver
  intltoolize -f
  ./configure --prefix=/opt/gnome --disable-gtk-doc
  make || return 1
  make DESTDIR=$startdir/pkg install
}

vervolgens draai ik makepkg, gaat dat ding ff rammelen, krijg ik een gnome-vfs-2.5.4.1-1.pkg.tar.gz bestand, voer ik "pacman -U gnome-vfs*.pkg.tar.gz" uit, heb ik mn nieuwe pakket geinstalleerd.
Mooi, dan ga ik em testen, ow shit, dat ding is helemaaaal niet goed, ik had beter bij de oude versie 2.5.3 kunnen blijven:
pacman -S gnome-vfs
installed gnome-vfs-2.5.4.1 is newer, reinstall? [y/n] Y
en dan ben ik terug bij de vorige versie. Handig he, zo'n simpel packagesysteem waarbij je altijd terug kunt zolang je de oude versie nog hebt

zelfde geldt voor debian zn apt-get, je zult alleen "apt-get install pakket=versie" moeten doen.

[tech-no-logical]

_JGC_ schreef op 28 december 2003 @ 13:04:
[...]
zelfde geldt voor debian zn apt-get, je zult alleen "apt-get install pakket=versie" moeten doen.

mja, voor 1 package werkt dat goed. voor ingewikkeldere dependencies werkt het gewoon niet meer (<-- eigen ervaring). en dan handmatig met --force dingen gaan weghalen maakt de zooi alleen maar erger.