Shared libs werking, PHP en upgrade GD

[Verwijderd]

Beste mensen,

Ik heb een Redhat 8.0 server draaien met Apache 2, PHP 4.2.2 en momenteel is de 1.8.x library van GD geinstalleerd. Mijn doel is om de GD versie te upgraden naar 2.x om truecolor en resample bewerkingen mogelijk te maken met plaatjes via PHP. Zowel PHP als GD (als Webalizer) zijn geinstalleerd met RPMs.

De geschiedenis van mijn pogingen tot upgrade:
1) rpm -U gd-2.x.rpm
=> failed dependencies: php en webalizer require gd.1.8.x
2) rpm -U --nodeps gd-2.x.rpm en om PHP te foppen een libgd.1.8.so symlink aangemaakt naar het nieuw gegenereerde libgd.2.x.so bestand
=> installeert prima, alleen PHP geeft "GD 2.0 niet aanwezig" fouten

Om te begrijpen waarom PHP nog steeds geen GD 2 ondersteunt, heb ik op een andere machine (zonder webserver, php en gd) even geprobeerd PHP als rpm te installeren (hetzelfde pakket als op de andere machine). Een van de dependencies bleek gd.1.8.x te zijn.

Mijn vragen:
1) Moet ik concluderen dat deze php RPM alleen werkt met gd-1.8.x en niet zelf kan uitzoeken welke gd versie is geinstalleerd? Is dit de algemene "statische" werking van RPMs?
2) Wat is de reden dat mijn tweede poging tot het foppen van PHP dat hij via een 1.8 symlink toch uitkomt bij een 2.0 library, niet lukt?

3) De belangrijkste vraag: Wat zou de snelste weg zijn om de GD library te upgraden en PHP de juiste koppeling te laten maken?

4) Zijn er handmatige manieren waarmee je bestaande applicaties (als PHP of Webalizer, die GD nodig hebben) kunt laten verwijzen naar nieuw gecreerde libraries (GD 2) zonder de applicaties opnieuw te installeren / 'configure'en?

Lang verhaal, boel vragen, hoop dat het niet demotiveert om wat inzicht te verstrekken. Hoe dan ook, bij voorbaat dank.

[moto-moi]

Verwijderd schreef op 07 september 2003 @ 12:03:
Mijn vragen:
1) Moet ik concluderen dat deze php RPM alleen werkt met gd-1.8.x en niet zelf kan uitzoeken welke gd versie is geinstalleerd? Is dit de algemene "statische" werking van RPMs?

De rpms worden gecompileerd, en worden dus gelinked naar een gd versie, degene die php heeft gecompileerd had alleen maar 1.8, dus heeft PHP zich ingesteld op 1.8..

2) Wat is de reden dat mijn tweede poging tot het foppen van PHP dat hij via een 1.8 symlink toch uitkomt bij een 2.0 library, niet lukt?

Omdat er blijkbaar een groot verschil zit tussen de 1.8 versie, en de 2.0 versie, waardoor ze niet onderling uitwisselbaar zijn.

3) De belangrijkste vraag: Wat zou de snelste weg zijn om de GD library te upgraden en PHP de juiste koppeling te laten maken?

De simpelste manier is de rpm van gd 2.0 te installeren, daarna de srpm (Let op de s!) te downloaden van php, en deze opnieuw te builden, hoe dat gaat kun je uitvinden door de RPM-Howto te lezen, die je wel met google kan vinden
Dat levert je een php op die gelinked is met gd 2.0

4) Zijn er handmatige manieren waarmee je bestaande applicaties (als PHP of Webalizer, die GD nodig hebben) kunt laten verwijzen naar nieuw gecreerde libraries (GD 2) zonder de applicaties opnieuw te installeren / 'configure'en?

Soms kan het door een symlink aan te leggen, maar zoals je al gemerkt hebt, werkt dat niet altijd

[Kippenijzer]

IIRC zijn voor PHP gd1 en gd2 nogal verschillende dingen en moet je PHP opnieuw compileren wil je hem gd2 support geven en het is een of/of kwestie, je kunt hem niet voor zowel gd1 als gd2 compileren in 1 rpm -> die rpm voor php kan niet werken met gd2

[Verwijderd]

Dank voor jullie bijdrage. Ik zal eerst eens kijken wat de mogelijkheden zijn met nieuwere RPMs die wellicht wel een gd-2.x versie ondersteunen.

Het gaat hier om een live hosting server en, alhoewel er weinig PHP gebruik is, ik geef voorkeur aan het laten doen van het werk door RPMs, voordat ik zelf ga builden. Al heeft het natuurlijk wel zijn voordelen om de sources gereed te hebben opdat je veel makkelijker een custom PHP kan compilen.

[Verwijderd]

Is het trouwens mogelijk twee versies van hetzelfde pakket (bijv. GD 1.8 en GD 2.x) naast elkaar te bouwen, dus 2 libs overhouden.

Dit zou op zich wel aardig zijn zodat ik weet dat ik bijv. Webalizer met rust kan laten, door gewoon de oude GD 1.8 te gebruiken. Maar dan voor PHP me te richten op GD 2.0.

Of is dit iets wat buiten RPM om zou moeten gebeuren omdat RPM zich juist bezig houdt met versie beheer?

Alvast bedankt.

[_JGC_]

GD en GD2 kunnen gewoon naastelkaar geinstalleerd zijn, je webalizer blijft dus gewoon werken.
PHP kan echter niet zowel met GD als met GD2 gecompileerd worden, je zult bij compileren van PHP dus sowieso al aan moeten geven dat je GD2 wilt ipv GD.

Overigens vind ik die RPMs die RH heeft gemaakt van PHP nou ook weer niet al te best. Op mn debian servers kan ik gewoon php4 installeren, dan heb je alleen PHP4 voor apache 1.3.x met alleen het nodige erin. Wil je nog meer, dan kan je voor elke optie een dynamische module aan PHP toevoegen, waarbij je dus ook keuze hebt tussen php4-gd en php4-gd2, beetje slordig van RH dat ze dat wel voor IMAP en dergelijke doen, maar niet voor GD.

[Kippenijzer]

Ik ben op het moment ook zelf bezig om een meer grafische dingen ondersteunende PHP te bouwen, (beetje zonde om daarvoor extra topic te openen vind ik) maar ik blijf (ondanks dat ik hem letterlijk gecompiled en op de juiste plek neergezet heb uit pine4.56) de error krijgen :

checking for crypt in -lcrypt... yes
configure: error: Cannot find imap library (libc-client.a). Please check your IMAP installation.

Iemand een idee hoe ik dit kan verhelpen?

[igmar]

Verwijderd schreef op 07 September 2003 @ 12:58:
Is het trouwens mogelijk twee versies van hetzelfde pakket (bijv. GD 1.8 en GD 2.x) naast elkaar te bouwen, dus 2 libs overhouden.

In principe wel, tenzij de library names hetzelfde zijn. Van beide versies ook de devel versie geeft meer problemen dan je lief is, dus niet doen.

Dit zou op zich wel aardig zijn zodat ik weet dat ik bijv. Webalizer met rust kan laten, door gewoon de oude GD 1.8 te gebruiken. Maar dan voor PHP me te richten op GD 2.0.

Of is dit iets wat buiten RPM om zou moeten gebeuren omdat RPM zich juist bezig houdt met versie beheer?

Het meest simpele is de .src.rpm installeren, de specfile aan te passen op gd 2.x, en dan een recompile.

[Verwijderd]

Bedankt voor de laatste comments, het is gelukt, zij het met een omweg door het vooraf compileren van de diverse grafische libraries:

Hier een geschiedenis van het traject. Ik heb onderweg veel foutmeldingen gekregen die ik ook tegenkwam in menig forum. Wellicht dat onderstaand traject van hulp kan zijn voor iemand anders.

____________________________________________

De geschiedenis in chronologische volgorde voor het compileren van PHP 4.2.3 met GD versie 2.0.8 op een Linux RedHat 7.1 machine met Apache 2.0.4.x:
____________________________________________

1) Ga naar http://www.boutell.com/gd/ en zoek de Documentation op, waarin je links kan vinden naar de websites van PNG, JPEG en ZLIB. Download van deze sites en die van GD de meest recente sources:
+ GD 2.0.8 => gd-2.0.8.tar.gz (Boutel website)
+ PNG 1.2.5 => libpng-1.2.5.tar.gz (Via http://www.libpng.org/)
+ JPEG V6 => jpegsrc.v6b.tar.gz (Via http://www.ijg.org/)
+ ZLIB 1.1.4 => zlib-1.1.4.tar.gz (Via http://www.zlib.org/)

2) Tijdens het compileren van PHP-4.2.3 en hoger met GD-2.0.8 krijg je foutmeldingen die in 1e instantie niet voorzien waren door Boutell. Ze hebben een patch ontwikkeld, download deze van hun site:
+ Patch => php-4.2.3-gd-2.0.8.patch

3) Download een source van PHP, ik heb gekozen voor PHP versie 4.2.3:
+ PHP 4.2.3 => php-4.2.3.tar.gz

4) Vervolgens heb ik de reeds geinstalleerde RPMs weggehaald van PHP, GD, LIBPNG en JPEG. ZLIB had nogal wat dependencies met andere pakketten, dus die heb ik laten staan.

5) Alle sources bijvoorbeeld zetten in directory /tmp (ik heb ze zelf in /install gezet, en laat ze daar ook lekker staan ivm mogelijk opnieuw compilen van sources) en daar uitpakken met gunzip filename.tar.gz en tar -xvf filename.tar. Je krijgt nu 5 directories met de sources van de 5 pakketten.

6) Compile nu in deze volgorde de sources (bij sommige sources moet je eerst even de juiste Makefile erbij halen door bijv. makefile.linux te kopieren naar Makefile) door het uitvoeren van ./configure, make en make install per pakket:
+ zlib
+ libpng
+ jpeg (./configure --enable-shared => dit levert de benodigde shared libs op)
+ gd (./configure laat zien of PNG en JPEG gevonden zijn. Indien niet gevonden is waarschijnlijk het installeren van de png en jpeg libs niet goed gegaan)

Als alles goed is gegaan heb je nu in de map /usr/local/lib (de standaard map voor installatie door de diverse ./configure's) diverse bestanden staan die de libs van GD, JPEG, PNG en ZLIB vertegenwoordigen.

7) Nu is het de beurt om PHP te configuren:
=> ./configure --with-gd --with-jpeg --with-png --with-zlib (+ wat je nog meer wil)

8 ) LET OP! Als je nu make doet kan het zijn dat make crasht met 'ctx' foutmeldingen. Dit heeft te maken met incompatibiliteit tussen de PHP-4.2.3 install en de GD 2.0.8 library. Pas daarom nu de patch toe:
=> Kopieer de patch naar de source directory van PHP
=> Voer uit: patch -p1 < php-4.2.3-gd-2.0.8.patch
Dit geldt alleen voor als je GD 2.0.8 hebt geinstalleerd en met PHP 4.2.3 en hoger wil gebruiken. Andere versies schijnen OK te zijn.

9) Installeer PHP
=> make
=> make install
=> Kopieer eventueel het nodige naar de juiste plek

10) Klaar! Maak een php script en kijk of truecolor en andere GD 2 functies werken!

Succes.

[moto-moi]

Jups, en op deze manier ga je helemaal voorbij aan de voordelen die rpm biedt, but hey.. het is jouw systeem..

[ Voor 47% gewijzigd door moto-moi op 08-09-2003 13:21 ]

[Verwijderd]

Helemaal gelijk moto-moi..
Alleen voor de RPM van GD 2 had ik allerlei versies van rpms nodig die ik niet beschikbaar had voor RedHat 7.1. Volgens mij werkt de GD 2 rpm pas standaard vanaf RedHat 8 want dan zijn de algemeen benodigde libraries beschikbaar (glibc.so.6 was de ramp voor mij). Daarnaast ging de RPM van PHP 4.2.3 uit van GD 1.8.4, en daar moest ik om heen.

Ik had het ook graag anders gezien!

[moto-moi]

Daarvoor heb je dus die srpms, die kun je zelf compileren, en dan heb je dat probleem vaak een stuk minder.

[Verwijderd]

Bij de volgende situatie ga ik je raad eens opvolgen. Dank.