After adding ~amd64 keyword to php-5.0.2 and mod_php-5.0.2 ebuild files I was able to build these on my amd64 using ACCEPT_KEYWORDS="~amd64" without any problems. And it even seems to work! I think it's time to add ~amd64 keyword to these. Reproducible: Always Steps to Reproduce: 1. add ~amd64 keyword to php-5.0.2 and mod_php-5.0.2 ebuild files 2. set env-var ACCEPT_KEYWORDS="~amd64" 3. emerge mod_php (and php) Actual Results: PHP works without any noticeable problems.
I would like to add that I have done this myself and I am using several PHP scripts coded by myself and from other projects with no noticeable problems. I think they should be ~amd64 keyworded.
Just noticed that this is a duplicate of bug 65819, although this bug has better keywords in title enabling me to find it :)
Odd, then, that it doesn't build here. I get this after building php-5.0.2 more or less succesfully: [...] -lfam -ldb-4.1 -lgdbm -lcurl -lbz2 -lz -lresolv -lm -ldl -lnsl -lxml2 -lz -lm -lssl -lcrypto -ldl -lcurl -lssl -lcrypto -ldl -lssl -lcrypto -ldl -lz -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -lcrypt -o sapi/cli/php /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../lib/libc-client.a(osdep.o)(.text+0x99b5): In function `ssl_onceonlyinit': : warning: the use of `tmpnam' is dangerous, better use `mkstemp' Build complete. (It is safe to ignore warnings about tempnam and tmpnam). >>> Test phase [not enabled]: dev-php/php-5.0.2-r1 >>> Install php-5.0.2-r1 into /var/tmp/portage/php-5.0.2-r1/image/ category dev-php Installing PHP SAPI module: embed cp: cannot stat `libs/libphp5.so': No such file or directory make: *** [install-sapi] Error 1 !!! ERROR: dev-php/php-5.0.2-r1 failed. !!! Function php5-sapi_src_install, Line 439, Exitcode 2 !!! install failed [...] Sounds like an ebuild bug, but I can't seem to figure out which and where...
*** Bug 71927 has been marked as a duplicate of this bug. ***
I get the same build error, switching to -O2 doesn't help at all
after hours of testing from myself, lares, kumkuat, and neclimdul(all amd64), we've determined that php-5.0.2-r1 will fail if USE has imap in it. imap depends on net-libs/c-client. +imap also causes configure to fail on libc-client.a. the work around is to add -imap to /etc/portage/package.use
removing imap from the use flags works for me, too :-)
I never had imap in my USE flags for php or mod_php. I have just recompiled using GCC 3.4.3 and both recompiled without incident - although still -imap. As I said I have been using this version of mod_php for quite a while now without problems. Adding USE="imap" did then cause the emerge to fail, so I can also confirm this.
I've found comment about PHP-5 (USE="imap") working with newer portage/gcc BUG: 61392
*** Bug 65233 has been marked as a duplicate of this bug. ***
Confirmation. php-5.0.2-r1 & mod_php-5.0.2 both compile with modified ebuilds including ~amd64 in portage overlay. +imap is still problematic though. please add ~amd64 to the ebuilds.
~amd64 was removed because of the +imap issues. It won't be readded until imap support is resolved. If anyone can get it to compile with +imap, please let us know how you did it.
*** Bug 76520 has been marked as a duplicate of this bug. ***
Done ! I've just compiled php-5.0.3 with imap support. It will fail if i do not add the shared use flag. My use flags follow. If someone else could test it and quickly report the result so that it can be marked ~amd64... Notice that it works the same for mod_php. [ebuild R ] dev-php/php-5.0.3 (-adabas) -bcmath +berkdb (-birdstep) -bzlib -calendar -cdb (-cpdflib) +crypt -ctype -curl -curlwrappers -db2 +dba -dbase -dbm (-dbmaker) -dbx -debug -dio (-empress) (-empress-bcs) (-esoob) -exif +fam (-fdftk) (-filepro) -flatfile (-frontbase) -ftp +gd -gd-external +gdbm -gmp -hyperwave-api -iconv +imap (-informix) (-ingres) -inifile -interbase -iodbc +jpeg -kerberos +ldap -libedit -mcve -memlimit -mhash -mime -ming -mnogosearch -msession -msql -mssql +mysql -mysqli +ncurses -nis +nls -oci8 -odbc -oracle7 -ovrimos -pcntl -pcre (-pfpro) +png -posix -postgres -qdbm +readline -recode -sapdb +sasl +session +shared -sharedmem -simplexml -snmp -soap -sockets (-solid) +spell -spl +sqlite +ssl (-sybase) (-sybase-ct) -sysvipc -tidy +tiff -tokenizer +truetype -wddx +xml2 -xmlrpc +xpm +xsl* +zlib 0 kB
adding shared to use flags works for me, tested on php and php-cgi. I noticed that in phpinfo() there is the compile flag --with-imap, but there is no further imap status message. Can anyone confirm that imap is really working?
Compiles for me too, doesn't seem to work though. I get "Call to undefined function imap_open()" when i try tu use it (or at least i think i'm trying to use _that_ imap :).
Uhm... what is the 'shared' use flag all about? Shouldn't we ALWAYS be shared unless USE=static (in which some ebuilds install static only and others use it to install both)? I don't recall seeing that USE flag discussed before being added...
eradicator: PHP's shared use flag controls if you get a monolithic or modularized PHP build. If a modularized one, we put lines to load all build modules in the php.ini (the user can then selectively disable some of them if they want, and load at runtime instead).
then why there's no extension=imap.so line in my php.ini after installing with USE='imap shared'?
That's a very good question. Did you do etc-update of your mod_php php.ini after installing mod_php, and put in the new config file with 'extension=imap.so' ? please attach the output from: f=$(/usr/bin/php-config --extension-dir) echo $f ls -lR $f
Created attachment 47749 [details] requested output (php modules) imap module seems like static to me...
hmm try adding extension=imap.a to your php.ini and see if things work (I doubt it). I'm not sure why it's building an imap.a instead of imap.so for you (I get the imap.so on x86, no amd64 box to test on).
it complains (imap.a: invalid ELF header) as was expected. what else could i do?.. (not that i need the imap thing, it's just that the resolution of this thing is sooo slow... i just want to have an untweaked php5 on my box:)
Would you mind doing: ebuild /usr/portage/dev-php/mod_php/mod_php-5.0.3 package then tarring up the entire working directory (/var/tmp/portage/mod_php-5.0.3/) and putting it somewhere? then please email me a link to it (it may contain private information so I advise against posting it here).
5.0.3 work for me on dual opteron after manually emerging libxml2
I have been working on the IMAP issues on amd64. I have come up with what I believe to be the best solution - building a shared c-client library for PHP to link against. This solution works well for me, and allows PHP to build and successfully utilise the IMAP functionality. Robin - if this looks OK to you I can commit it. I am attaching the patch and the updated c-client ebuild. This also fixes the error of the c-client.a symlink not being properly created on amd64 systems.
Created attachment 49887 [details, diff] c-client-2004a.diff Diff of c-client-2004a.ebuild.
Created attachment 49888 [details, diff] files/c-client-2004a-amd64-so-fix.patch Makefile patch to build the shared library.
cryos: your patch will need to apply to: net-lib/c-client net-mail/uw-imap net-mail/vimap as all of those provide a c-client.
I have now added patched ebuilds that make the required shared library - net-mail/uw-imap-2004c-r1 and net-libs/c-client-2004a-r1. These allow mod_php-5.0.3-r1 to build successfully with IMAP support, and also use said IMAP support. I will take a look at vimap at some point, but it is not keyworded on amd64 yet and so is not urgent. Robin - I think the sedding to fix the various Makefiles in uw-imap, and then to apply -fPIC to c-client should be applied for all architectures, but have left it inside the condtional block for amd64 in case of issues I was unaware of on other architectures.
Seems to me like working. Tried to compile mod_php and php with USE="imap -shared" - no problems. IMAP seems to work (doesn't show "function undefined" errors), although i don't have any host to test it on :).
