PHP 5.2.6 niet te compileren met iconv en libiconv

Pagina: 1
Acties:

  • badkuip
  • Registratie: December 2002
  • Laatst online: 21:07
Het werd voor mij weer nodig tijd om een webserver op te zetten op mijn Slackware machine.
MySQL en Apache installeren ging zonder problemen maar bij PHP blijft het hangen.

Ik gebruik de nieuwste source van PHP 5.2.6 en ik volg de instructies van de PHP website.
Ik gebruik Apache 2.2 maar ik ben ervan uit gegaan dat dit niet veel uitmaakt voor de instructies.

Het configgen van PHP gaat goed alleen bij 'make' knalt ie eruit.

Het configgen en het maken heb ik even gelogged en zijn hier en hier te vinden.

de laatste regels van het maken (dit wordt niet weergegeven in de log):
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
ext/iconv/iconv.o: In function `_php_iconv_strlen':
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:603: undefined reference to `libiconv_open'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:626: undefined reference to `libiconv'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:660: undefined reference to `libiconv_close'
ext/iconv/iconv.o: In function `php_iconv_string':
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:441: undefined reference to `libiconv_open'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:453: undefined reference to `libiconv'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:467: undefined reference to `libiconv'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:478: undefined reference to `libiconv_close'
ext/iconv/iconv.o: In function `_php_iconv_strpos':
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:851: undefined reference to `libiconv_open'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:879: undefined reference to `libiconv'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:993: undefined reference to `libiconv_close'
ext/iconv/iconv.o: In function `_php_iconv_appendl':
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:348: undefined reference to `libiconv'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:385: undefined reference to `libiconv'
ext/iconv/iconv.o: In function `_php_iconv_substr':
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:723: undefined reference to `libiconv_open'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:747: undefined reference to `libiconv'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:802: undefined reference to `libiconv_close'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:806: undefined reference to `libiconv_close'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:755: undefined reference to `libiconv_open'
ext/iconv/iconv.o: In function `_php_iconv_mime_decode':
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:1354: undefined reference to `libiconv_open'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:1465: undefined reference to `libiconv_close'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:1468: undefined reference to `libiconv_open'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:1823: undefined reference to `libiconv_close'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:1826: undefined reference to `libiconv_close'
ext/iconv/iconv.o: In function `php_iconv_stream_filter_dtor':
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:2465: undefined reference to `libiconv_close'
ext/iconv/iconv.o: In function `_php_iconv_mime_encode':
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:1043: undefined reference to `libiconv_open'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:1057: undefined reference to `libiconv_open'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:1316: undefined reference to `libiconv_close'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:1319: undefined reference to `libiconv_close'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:1176: undefined reference to `libiconv'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:1128: undefined reference to `libiconv'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:1160: undefined reference to `libiconv'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:1319: undefined reference to `libiconv_close'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:1228: undefined reference to `libiconv'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:1259: undefined reference to `libiconv'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:1303: undefined reference to `libiconv'
ext/iconv/iconv.o: In function `php_iconv_stream_filter_append_bucket':
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:2615: undefined reference to `libiconv'
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:2537: undefined reference to `libiconv'
ext/iconv/iconv.o: In function `php_iconv_stream_filter_ctor':
/tmp/bla/php-5.2.6/ext/iconv/iconv.c:2491: undefined reference to `libiconv_open'
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1


Zo te zien een probleem met iconv en libiconv. iconv is een onderdeel van libiconv, dus ik heb deze lib gedownload en geinstalleerd. Hierna ook gettext opnieuw gecompiled en geinstalleerd, mocht niet baten.
iconv wordt trouwens wel gevonden bij het configgen (checking for iconv support... yes).


Ook heb ik regelmatig een ldconfig gedaan en de paden naar de libaries staan in /etc/ld.so.conf (namelijk /usr/local/lib).

Kan iemand mij uit de brand helpen of mij een richting insturen?

  • phobosdeimos
  • Registratie: Augustus 2007
  • Laatst online: 23:18
www.debian.org

Bespaar jezelf de "compileer vanaf source" nonsens/ergernissen, en spendeer je tijd aan nuttige dingen.

  • badkuip
  • Registratie: December 2002
  • Laatst online: 21:07
phobosdeimos schreef op woensdag 11 juni 2008 @ 19:49:
www.debian.org

Bespaar jezelf de "compileer vanaf source" nonsens/ergernissen, en spendeer je tijd aan nuttige dingen.
Leuk dat je het zegt, ik heb op een ander bak al Debian draaien maar ik wil het toch graag met Slackware proberen. Heeft er iemand anders nog ideeën?

  • jschot
  • Registratie: Oktober 2002
  • Laatst online: 09-07-2025
Heb je wat aan deze PHP bugreport?

  • silentsnake
  • Registratie: September 2003
  • Laatst online: 15-01 11:20
Heb je ook de header files van libiconv in je include path? (Dus dat zal wel /usr/include zijn)

  • _eXistenZ_
  • Registratie: Februari 2004
  • Laatst online: 28-01 17:38
badkuip schreef op woensdag 11 juni 2008 @ 20:47:
[...]


Leuk dat je het zegt, ik heb op een ander bak al Debian draaien maar ik wil het toch graag met Slackware proberen. Heeft er iemand anders nog ideeën?
Gentoo.org, bespaar jezelf gezijk met handmatig compilen, maar optimaliseer en shape je packages toch zoals je zelf wilt ipv die gare bloated dingen van Debian.

There is no replacement for displacement!


  • phobosdeimos
  • Registratie: Augustus 2007
  • Laatst online: 23:18
_eXistenZ_ schreef op vrijdag 13 juni 2008 @ 22:28:
[...]


Gentoo.org, bespaar jezelf gezijk met handmatig compilen, maar optimaliseer en shape je packages toch zoals je zelf wilt ipv die gare bloated dingen van Debian.
De verhouding "compleet onbruikbaar geworden" gentoo installaties ten opzichte van hetzelfde resultaat met Debian bereiken, is een soort van 1000 > 1.
Rare definitie van gaar dat jij hebt.
Heerlijk om gentoo ricers bezig te zien trouwens, rotsvast vasthouden aan de illusie dat het per definitie beter is als je alles zelf compileert.
En dan maar afvragen waarom de helft van je proggies segfault omdat je verkeerde compiler optimalisaties hebt gekozen ;)

  • _JGC_
  • Registratie: Juli 2000
  • Laatst online: 01:51
Niet elke gentoo-er is een ricer. Zolang je je CFLAGS niet te overmoedig instelt valt het best mee. Daarnaast hebben veel ebuilds tegenwoordig een ricer-filter die bekende brakke CFLAGS eruitfiltert zodat je programma alsnog stabiel is.
Voor sommige programma's kunnen CFLAGS flink veel verschil maken, voor andere programma's introduceert het alleen maar ellende of maakt het qua performance niets uit.

Voor MySQL bijvoorbeeld schijnt er een 10-20% performance boost te zijn door het ding statisch te compilen. Als nadeel kleeft hieraan dat je MySQL build gaat segfaulten als je dynamische NSS modules in /etc/nsswitch.conf instelt. Aangezien dit een veel voorkomend iets is op een distributie wordt MySQL daar gewoon 10-20% trager dynamisch zonder problemen gecompileerd, maar als je zelf geen dynamische NSS modules gebruikt, kan je gerust MySQL zelf recompilen met deze optie.

  • phobosdeimos
  • Registratie: Augustus 2007
  • Laatst online: 23:18
_JGC_ schreef op zaterdag 14 juni 2008 @ 00:21:
Niet elke gentoo-er is een ricer. Zolang je je CFLAGS niet te overmoedig instelt valt het best mee. Daarnaast hebben veel ebuilds tegenwoordig een ricer-filter die bekende brakke CFLAGS eruitfiltert zodat je programma alsnog stabiel is.
Voor sommige programma's kunnen CFLAGS flink veel verschil maken, voor andere programma's introduceert het alleen maar ellende of maakt het qua performance niets uit.

Voor MySQL bijvoorbeeld schijnt er een 10-20% performance boost te zijn door het ding statisch te compilen. Als nadeel kleeft hieraan dat je MySQL build gaat segfaulten als je dynamische NSS modules in /etc/nsswitch.conf instelt. Aangezien dit een veel voorkomend iets is op een distributie wordt MySQL daar gewoon 10-20% trager dynamisch zonder problemen gecompileerd, maar als je zelf geen dynamische NSS modules gebruikt, kan je gerust MySQL zelf recompilen met deze optie.
Denk je nu echt dat jij, of _eXistenZ_, of welke doorsnee gentoo boy dan ook, meer afweet van het compileren en packagen van mysql, dan de package maintainers van bijvoorbeeld Debian?
Get real.
Je probeert gewoon het gebruik van gentoo goed te praten, terwijl de hele filosofie van gentoo gebaseerd is op nonsens.
Het enige effect is dat je nog eens meehelpt aan het verpesten van het milieu, doordat een gentoo gebruiker zijn pc heel de dag laat blazen op maximum om alles gecompileert te krijgen.
Tegen dat je klaar bent met gnome, is er weer een nieuwe bugfix klaar ;)

  • _eXistenZ_
  • Registratie: Februari 2004
  • Laatst online: 28-01 17:38
phobosdeimos schreef op zaterdag 14 juni 2008 @ 00:14:
[...]

De verhouding "compleet onbruikbaar geworden" gentoo installaties ten opzichte van hetzelfde resultaat met Debian bereiken, is een soort van 1000 > 1.
Bron?
Rare definitie van gaar dat jij hebt.
Heerlijk om gentoo ricers bezig te zien trouwens, rotsvast vasthouden aan de illusie dat het per definitie beter is als je alles zelf compileert.
En dan maar afvragen waarom de helft van je proggies segfault omdat je verkeerde compiler optimalisaties hebt gekozen ;)
Wanneer zou dat voor moeten komen dan? Of ken jij mensen die Gentoo draaien die hier vaak last van hebben?
phobosdeimos schreef op zaterdag 14 juni 2008 @ 00:30:
[...]


Denk je nu echt dat jij, of _eXistenZ_, of welke doorsnee gentoo boy dan ook, meer afweet van het compileren en packagen van mysql, dan de package maintainers van bijvoorbeeld Debian?
Get real.
Buiten het feit dat op de man spelen natuurlijk geen valide vorm van argumenteren is, 'gentoo boy' :')

Ik weet of ik wel of niet BerkerlyDB ga gebruiken, of selinux securitycrap, of wat dan ook. Dat weten de heren bij Debian niet, want die kunnen (voor zover mij bekend) geen gedachtelezen.
Je probeert gewoon het gebruik van gentoo goed te praten, terwijl de hele filosofie van gentoo gebaseerd is op nonsens.
Meningen presenteren als feiten :N

Don't get me wrong, Debian is een mooie distro die lekker stabiel is, maar ik houd er van om de dingen te installeren die ik ga gebruiken, niet meer en niet minder, en geoptimaliseerd voor mijn machine.

[ Voor 41% gewijzigd door _eXistenZ_ op 14-06-2008 00:41 ]

There is no replacement for displacement!


  • zomertje
  • Registratie: Januari 2000
  • Laatst online: 22-01 20:37

zomertje

Barisax knorretje

Zullen we ontopic verder gaan? De TS wil graag met Slackware verder, laten we dat respecteren en hem daarmee helpen en niet proberen onze eigen favo distro in de maag te splitsen (AIX anyone ;) :+ )

@TS: ben je al wat verder of heb je nog steeds dezelfde foutmelding?

het ultieme jaargetijde.... | #!/usr/bin/girl | Art prints and fun


  • _JGC_
  • Registratie: Juli 2000
  • Laatst online: 01:51
phobosdeimos schreef op zaterdag 14 juni 2008 @ 00:30:
[...]


Denk je nu echt dat jij, of _eXistenZ_, of welke doorsnee gentoo boy dan ook, meer afweet van het compileren en packagen van mysql, dan de package maintainers van bijvoorbeeld Debian?
Get real.
Je probeert gewoon het gebruik van gentoo goed te praten, terwijl de hele filosofie van gentoo gebaseerd is op nonsens.
Het enige effect is dat je nog eens meehelpt aan het verpesten van het milieu, doordat een gentoo gebruiker zijn pc heel de dag laat blazen op maximum om alles gecompileert te krijgen.
Tegen dat je klaar bent met gnome, is er weer een nieuwe bugfix klaar ;)
Toevallig ben ik zelf maintainer van GNOME voor Archlinux, ik weet dus wat het is om spullen vaak te compileren. In de 4 jaar die ik me hier nu mee bezig houd ben ik al heel wat shit tegengekomen die niet alleen met CFLAGS te maken hebben, maar ook met compilerkeuze.
Mijn MySQL voorbeeld staat overigens letterlijk in de debian/rules van mysql, kijk zelf maar als je het niet gelooft.

Gentoo heeft zeker zijn voordelen en nadelen, maar om nou een hele distro af te breken vanwege het feit dat de meeste gebruikers zelf al hun rotzooi compilen (wat ik over het algemeen ook nutteloos vind in de meeste gevallen overigens), vind ik complete onzin.

Om even terug te komen op het originele probleem:
Zorg ervoor dat PHP niet libiconv oppakt, maar de iconv functies van glibc gebruikt. Ik zie het nut niet van libiconv op een linux systeem, glibc heeft alle benodigde functionaliteit al. Als er niets op je systeem is wat linkt tegen libiconv kan je dat ding er net zo goed afgooien.
Pagina: 1