pkg-config en glib om gaim te compileren op debian

[Boudewijn]

Hoi,


Ik ben bezig geweest op een van mijn machines ( sarge) gaim 1.0.3 te compilen.
Ik heb hier glib-2.2.3 op gecompileerd en make install gedaan als root (nergens errors gekregen).

Vervolgens gaim trachten te configuren (versie 1.0.3) : het configure script begon te mekkeren over glib-2.0 die mist.

Ik bedacht toen: oh ja ik ben vergeten een .pc file aan te maken in /usr/lib/pkgconfig dus maakte ik deze aan:

more /usr/lib/pkgconfig/glib-2.0.pc
prefix=/home/boudewijn
exec_prefix=/home/boudewijn
libdir=/home/boudewijn/glib-2.2.3
includedir=/home/boudewijn/glib-2.2.3

glib_genmarshal=glib-genmarshal
gobject_query=gobject-query
glib_mkenums=glib-mkenums

Name: GLib
Description: C Utility Library
Version: 2.2.3
Libs: -L${libdir} -lglib-2.0
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include

Ik heb daarna (toen configure niet nog steeds lukte) PKG_CONFIG_PATH aangemaakt en naar /usr/lib/pkgconfig gezet (daar staat de pc file) alhoewel het default al zou moeten werken.


Ik zie echter niet wat ik verkeerd doe (Ik doet het nog niet zo lang) , maar heb wel de manual gelezen (zoals het hoort) en heb een post op LQ geopend, maar zonder oplossing.


Mijn glib heb ik hier gecompileerd:

/home/boudewijn/glib-2.2.3

Hoe kan ik dit probleem het makkelijkste tackelen?

[_JGC_]

Misschien moet je wel helemaal niet compileren uit source met debian?

http://packages.debian.or...all&exact=1&keywords=gaim

1.0.2 zit in testing, 1.0.3 in unstable. Je kunt gerust een willekeurig pakketje uit unstable op testing installeren, die systemen wijken op dit moment amper van elkaar af.

Als je nog niet zelf uit je compilatieproblemen kunt komen, is het niet aan te raden om dit zelf te gaan doen. Het is raadzaam om dit werk over te laten aan mensen die er verstand van hebben, de package maintainers van je distributie.

Niet alleen maak je met zelf compileren een enorme bende van je systeem, maar je krijgt later ook allerlei conflicten omdat je meerdere versies van hetzelfde pakket op je systeem achterlaat.

[Neophyte]

Zoveel moeite, voor eigenlijk helemaal niks.
Gaim 1.0.3 zit inderdaad gewoon in unstable en de changelog zegt het volgende:

code:

gaim (1:1.0.3-1) unstable; urgency=low

  * New upstream version.
    - Fixes Jabber authentication issues       (closes: #266632, #218994)
    - Fixes crash when dragging a buddy onto a convo window
                                                        (closes: #277208)

Dus je kan nog prima 1.0.2 gebruiken ook, geen critical updates.

Tik dus gewoon:

code:

apt-get install gaim

En je bent klaar...

[Boudewijn]

sorry maar dat is niet de bedoeling, ik wil gewoon zoveel mogelijk vanaf source compileren. En daarmee leren hoe dingen als pkg-config het makkelijkste werken. Dat ik gewoon als easy way out een binary kan halen is niet mijn mentaliteit (en hopelijk ook niet die van een echte tweaker). Niet rottug bedoeld btw.

Lees nu net pas de 2e post:

Ik ben geen n00b ofzo hoor, daar nu al aardige tijd verschillende linux versies (waaronder Gentoo). Willen jullie me er aub niet op wijzen dat er ook binaries zijn.

Over het nut van binaries hoor je mij niets zeggen, maar ik prefereer source (aanpasbaar). Niet alleen bij de kernel (draai 2.6.9 en 2.6.10beta) maar ook bij gewone applicaties.

[ Voor 47% gewijzigd door Boudewijn op 01-12-2004 14:26 . Reden: typo en wat toelichting ]

[QuarkuS]

Staat je glib installatie niet stiekem ergens in /usr/local/ geinstalleerd, en dus niet in /home/boudewijn? En dus ook je pkgconfig files? Zoveel mensen zijn er niet die grote libs in hun homedir neerzetten. /usr/local is in ieder geval het default pad doorgaans, en dus niet je homedir. Je geeft niet aan dat je dat pad veranderd hebt, dus ik maak me sterk dat je die paden verkeerd hebt staan in je .pc file.

[_Squatt_]

BoudewijnLinux schreef op woensdag 01 december 2004 @ 00:00:
Ik ben bezig geweest op een van mijn machines ( sarge) gaim 1.0.3 te compilen.
Ik heb hier glib-2.2.3 op gecompileerd en make install gedaan als root (nergens errors gekregen).

Heb je een prefix meegegeven aan configure? Zo nee, dan is glib geinstalleerd onder /usr/local, en kloppen de paden in je glib-2.0.pc niet. _{zie ook QuarkuS' reply}

Ik bedacht toen: oh ja ik ben vergeten een .pc file aan te maken in /usr/lib/pkgconfig dus maakte ik deze aan:

Ik heb nog nooit zelf een .pc bestand aan hoeven maken. Dat werd gewoon meegeinstalleerd (staat dan waarschijnlijk in /usr/local/lib/pkgconfig).

Mijn glib heb ik hier gecompileerd:
/home/boudewijn/glib-2.2.3

Maar waar staat het geinstalleerd?

BoudewijnLinux schreef op woensdag 01 december 2004 @ 13:58:
Ik ben geen n00b ofzo hoor, daar nu al aardige tijd verschillende linux versies (waaronder Gentoo). Willen jullie me er aub niet op wijzen dat er ook binaries zijn.

Er komen regelmatig topics voorbij van mensen die iets proberen te compileren, maar er niet uitkomen. Zelden zijn er overtuigende redenen om als 'gebruiker' van source te compilen. Als jij in je topicstart er niet bij zet dat je per se wilt compilen is het gebruiken van een binary package een redelijke suggestie.

Ik heb liever dat jij even uit moet leggen dat je liever wilt compilen dan dat iemand anders Linux verder links laat liggen omdat: 'het installeren van programma's onnodig complex is' (wat niet zo is ).

offtopic:
en Gentoo kunnen draaien zegt niet veel meer dan dat je de handleiding kunt lezen .

Over het nut van binaries hoor je mij niets zeggen, maar ik prefereer source (aanpasbaar). Niet alleen bij de kernel (draai 2.6.9 en 2.6.10beta) maar ook bij gewone applicaties.

Mjah, met het installeren van een binary package ontneem je jezelf natuurlijk niet de mogelijkheid om de source te bekijken of wanneer nodig aan te passen (apt-get source etc), maar goed: jouw systeem, jouw regels .

[Boudewijn]

Nou ok, daar zit wat in.

Staat tegenover dat ik alles heb geuntarred in /home/boudewijn
en dus ook glib in /home/boudewijn/glib-2.2.3 heb ge-maked en ge-installed.

Heb net even van een mandrake machine het standaard .pc pakketje afgehaald (ja daar heb ik lekker simpel een RPM genomen) en die gecopied.

Ik zie vervolgens dat de referenties aardig kloppen (het pad wat ik krijg als ik whereis glib-2.0 intyp bestaat en is gevuld)

prefix=/usr
exec_prefix=/usr
libdir=/usr/lib
includedir=/usr/include

glib_genmarshal=glib-genmarshal
gobject_query=gobject-query
glib_mkenums=glib-mkenums

Name: GLib
Description: C Utility Library
Version: 2.2.3
Libs: -L${libdir} -lglib-2.0
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include


Dit is de inhoud van het glib.pc filetje.
Ik heb een locate gedaan op een mandrake bak en deze debian en zie dat het /usr/local/include is op debian. Hetzelfde geldt voor /usr/lib

Ik heb dus (omdat hier kennelijk overal /usr/local ipv /usr wordt gebruikt) dit veranderd:


prefix=/usr/local
exec_prefix=/usr/local
libdir=/usr/local/lib
includedir=/usr/local/include

Toch werkt het niet. Nog enig idee (het klinkt idd stom van me )?



Lees net post van _squatt_ (na posten van wat hierboven staat)



Heb je een prefix meegegeven aan configure? Zo nee, dan is glib geinstalleerd onder /usr/local, en kloppen de paden in je glib-2.0.pc niet.

Heb ik net aangepast


Ik heb nog nooit zelf een .pc bestand aan hoeven maken. Dat werd gewoon meegeinstalleerd (staat dan waarschijnlijk in /usr/local/lib/pkgconfig).

Dat is hier niet gebeurd, ik ga het even opnieuw compileren (en mieter het huidige .pc bestand even apart in een mapje)

Maar waar staat het geinstalleerd?


Je hebt gelijk .... /usr/local (was ik net ook al achter , na 2 dagen)

[ Voor 23% gewijzigd door Boudewijn op 01-12-2004 20:18 . Reden: type, post van squatt ]

[QuarkuS]

BoudewijnLinux schreef op woensdag 01 december 2004 @ 20:03:
Nou ok, daar zit wat in.

Ik heb een locate gedaan op een mandrake bak en deze debian en zie dat het /usr/local/include is op debian. Hetzelfde geldt voor /usr/lib

Even een misverstand uit de wereld helpen: dat is zo op jouw specifieke installatie omdat je hebt zitten kloten. Op een normaal geinstalleerd debian systeem staat dat in /usr/include en /usr/lib.

Ik heb dus (omdat hier kennelijk overal /usr/local ipv /usr wordt gebruikt) dit veranderd:



Lees net post van _squatt_ (na posten van wat hierboven staat)
Je hebt gelijk .... /usr/local (was ik net ook al achter , na 2 dagen)

Da's wel handig om te weten he, als je je systeem zelf wilt compileren. De default installatiedir van de meeste programma's is /usr/local. Gelukkig hebben we debian packages die dat netjes in /usr neerzetten, dependencies oplossen en op tijd met securitypatches geupdate worden

[Boudewijn]

QuarkuS schreef op woensdag 01 december 2004 @ 20:21:


Even een misverstand uit de wereld helpen: dat is zo op jouw specifieke installatie omdat je hebt zitten kloten. Op een normaal geinstalleerd debian systeem staat dat in /usr/include en /usr/lib.

Wat raad jij dan aan (nee geen binary), ding opnieuw reinstallen?
Heb net een make clean make make install gedaan maar toch wordt die .pc file neit aangepast

Da's wel handig om te weten he, als je je systeem zelf wilt compileren. De default installatiedir van de meeste programma's is /usr/local. Gelukkig hebben we debian packages die dat netjes in /usr neerzetten, dependencies oplossen en op tijd met securitypatches geupdate worden

Ja packages zijn tof en ik snap er het nut van, maar daarvoor heb ik hier wat mandrake gevallen staan. Ik wil gewoon graag van source compilen (dat is toch niet gek voor een tweaker ???)

[QuarkuS]

BoudewijnLinux schreef op woensdag 01 december 2004 @ 20:31:
[...]
Wat raad jij dan aan (nee geen binary), ding opnieuw reinstallen?
Heb net een make clean make make install gedaan maar toch wordt die .pc file neit aangepast

./configure --prefix=/usr

Bekijk de volgende keer anders eens ./configure --help of de INSTALL file.

En dan inderdaad opnieuw 'make install' draaien (ik weet niet precies of je 'make' nog moet uitvoeren daarvoor. Je kan dat voor de zekerheid nog doen natuurlijk). Dan zou het spontaan op de juiste plek moeten verdwijnen, inclusief je .pc file. Die wordt natuurlijk niet aangepast dan, maar overschreven.

Ja packages zijn tof en ik snap er het nut van, maar daarvoor heb ik hier wat mandrake gevallen staan. Ik wil gewoon graag van source compilen (dat is toch niet gek voor een tweaker ???)

Als je toch een debian systeem hebt, gebruik dan de debian packages. Daar heb je geen Mandrake voor nodig.
Van source compileren is niet zo gek, als je maar weet waar je mee bezig bent

[Boudewijn]

QuarkuS schreef op woensdag 01 december 2004 @ 22:31:
Van source compileren is niet zo gek, als je maar weet waar je mee bezig bent

Klopt, maar om dat goed te weten moet je een aantal keren op je bek gaan. Ik doe dat met plezier als ik er wat van leer. Ik ben namelijk nog geen goede overview tegengekomen over hoe dit werkt .

Ontopic:

Ik heb het volgende gedaan:

1: naar mijn glib sources gegaan, daar een make clean gedaan. ./configure --prefix=/usr , make make install.
2: De .pc file stond in /usr/lib/pkgconfig met als inhoud:

prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include


3: Ik heb gaim opnieuw geconfigured, eerst met ./configure . Dit ging mis . Ook daarna de prefix meegeven (leek me onlogisch, maar toch maar geprobeerd) werkte niet. PKG_CONFIG_PATH staat op /usr/lib/pkgconfig.

Zou je me nog even kunnen helpen (of heb ik teveel verklooit aan dit systeem, ik denk zelf van niet (is tough met Linux) )?

[_Squatt_]

BoudewijnLinux schreef op woensdag 01 december 2004 @ 23:58:
3: Ik heb gaim opnieuw geconfigured, eerst met ./configure . Dit ging mis . Ook daarna de prefix meegeven (leek me onlogisch, maar toch maar geprobeerd) werkte niet. PKG_CONFIG_PATH staat op /usr/lib/pkgconfig.

Welke fouten geeft configure? Wellicht moet je config.cache even weghalen zodat er geen oude waarden meer worden gebruikt. Als configure een fout geeft dan staat in config.log meestal het falende test programma met welke fout er precies was. Daarmee kun je wat gerichter zoeken naar de oorzaak van een probleem.

[Boudewijn]

huh, ik zie dit

*** 'pkg-config --modversion glib-2.0' returned 2.2.3, but GLIB (2.4.7)
*** was found! If pkg-config was correct, then it is best
*** to remove the old version of GLib. You may also be able to fix the error
*** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing
*** /etc/ld.so.conf. Make sure you have run ldconfig if that is
*** required on your system.
*** If pkg-config was wrong, set the environment variable PKG_CONFIG_PATH
*** to point to the correct configuration files
no
configure: error:
*** GLib 2.0 is required to build Gaim; please make sure you have the GLib
*** development headers installed. The latest version of GLib is
*** always available at http://www.gtk.org/.

Hoe kan dit nu weer
Die bestaat nog niet eens (heb het net gecheckt).

Over dat weggooien van bestanden:

config.guess config.h.in config.log configure
config.h config.h.mingw config.sub configure.ac


zijn de config-bestanden na de mislukte configure van gaim (in de gaim map).

mijn PKG_CONFIG_PATH staat nog steeds goed.

[ Voor 6% gewijzigd door Boudewijn op 02-12-2004 00:40 ]

[_Squatt_]

BoudewijnLinux schreef op donderdag 02 december 2004 @ 00:24:
huh, ik zie dit
[...knip...]

Ik denk dat glib 2.2.3 door jou is geinstalleerd, en 2.4.7 door apt. Ik weet zo uit mijn hoofd niet met welk commando je dat kunt controleren (tijdje geen debian gebruikt). En aangezien 2.4.7 nieuwer is (maar wel dezelfde major version) maakt ldconfig de symlinks voor libglib-2.0.so naar de 2.4.7 versie (dacht dat het zo werkte).

Je zult dus handmatig wat linkjes aan moeten passen, maar elke keer als ldconfig wordt gestart moet je dat weer opniew doen. Je kunt ook met apt-get glib-2.4.7 deinstalleren, maar dat zou ook alles wat een dependency heeft op glib >= 2.4.7 mee kunnen deinstalleren. Dit is wel een van de mogelijke problemen van het door elkaar gebruiken van packagemanagers en zelf compileren.

Misschien is het een idee om op een aparte partitie een Linux from Scratch te bouwen, dan heb je altijd een werkend systeem (debian) en een systeem waar je naar hartelust kunt knoeien. Zonder dat vooraf geinstalleerde pakketten of packagemanagers in de weg zitten.

Die bestaat nog niet eens (heb het net gecheckt).

Sinds 8 oktober is glib 2.4.7 beschikbaar .

[QuarkuS]

code:

mark@flappie:~$ dpkg -l |grep glib2.0
ii  libglib2.0-0   2.4.7-1        The GLib library of C routines
ii  libglib2.0-dat 2.4.7-1        Common files for GLib library
ii  libglib2.0-dev 2.4.7-1        Development files for the GLib library

op een debian unstable systeem.

Dus ofwel de debian packages weghalen (maar dan haal je je allerlei dependency problemen op de hals), of zelf die versie installeren.

[Boudewijn]

hmm ik zat er idd naast met glib (had op gtk.org gekeken onder downloads en zag alleen die 2.2.3 staan). Op zich heb ik dan geen nieuwere GLIB nodig denk ik zo.

een zoekactie naar de pakketjes levert me op:
ii libglib2.0-0 2.4.7-1 The GLib library of C routines


Hmm op zich is het niet zo erg als deze install totaal naar de knoppen gaat (ik heb hier zat pc's (stuk of 6 dikke bakken) ).


Ik denk dat ik dus nu de -devel nodig heb.

Hmm een LFS systeem is dan nog niet eens zo gek op een oud bakje .


Is het niet mogelijk naast de standaard binary versie van glib de source versie ergens te installeren en dan GAIM daartegen te compileren?

[QuarkuS]

libglib2.0-dev is genoeg om gaim te kunnen compileren. Daar heb je de complete source niet voor nodig, alleen de header files, en daar is die -dev package dus voor.

[Boudewijn]

ja dat snap ik (schrijf al 7 jaar programmas onder windows).

Hmm wat ik echter bedoelde : is het mogelijk om de headers uit de sources te gebruiken en voor de andere (reeds geinstalleerde) de binaries te gebruiken.

[QuarkuS]

Gezien de versienummers aanzienlijk verschillen, zou ik dat niet proberen. Het verschil is een minor versie, niet een patchlevel. En wat schiet je ermee op? Als je toch niet je zelfgecompileerde versie gebruikt, waarom zou je dan nog wel de (waarschijnlijk incompatibele) headers van een verouderde versie willen gebruiken?

[Boudewijn]

ok daar zit wat in.

Ik ga zo een 2400+je ofzo pakken voor LFS en eens kijken of het wil draaien.
Zou het ook mogelijk zijn al die meuk uit een debian install te kicken en dan zelf dergelijke libs te compileren (en dan de X server etc)?

[QuarkuS]

Ja, dat kan. Maar als je dat perse wilt, neem dan gentoo of lfs ofzo. Dat is niet echt waar debian voor bedoeld is, en je screwt het hele packaging systeem, tenzij je dat ook weer gaat rechtbreien. Je haalt je een hoop moeite op de hals om dpkg nog steeds te laten werken.