|Summary:||php 4.1.2 src.rpm redhat 7.2 recompiled php-imap broke|
|Product:||[Retired] Red Hat Linux||Reporter:||Jason Nielsen <jnielsen>|
|Component:||php||Assignee:||Joe Orton <jorton>|
|Status:||CLOSED WONTFIX||QA Contact:||David Lawrence <dkl>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-01-25 16:46:23 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Jason Nielsen 2003-07-16 16:30:23 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20030131 Description of problem: I do not know if this is a bug or what. Or just user error but for the life of me I can not determine what is wrong. I am attempting to add --with-mcrypt to php-4.1.2-7.2.6.src.rpm. All related libs (libmcrypt, mcrypt, mhash) install fine. php src.rpm recompiles apparently perfectly. php on the web server works perfectly including mcrypt support. Something appears to be wrong with php-imap though. If I use the precompiled .rpm from updates.redhat.com (I get the src.rpm from sameplace) php-imap works fine. I have done this on a totally stock redhat 7.2 system. Meaning I can install the php-4.1.2-7.2.6.rpm and php-imap works. If I take the src.rpm from same place, version etc and simply install it, rpmrebuild -ba php.spec php-imap is seems broken. This happens wether I add mcrypt support or not. The main system I have upgraded to imap-2002c in hopes this would solve it (non redhat rpm). It did not. After performing the "Steps to Reproduce" I check a phpinfo() test page, a horde test page, try out our internal PHP apps for interfacing postgresql and mysql databases and a few other php pages including a test page that uses the new mcrypt functions. All of these work fine. The second I attempt to log into horde though via IMP(uses imap) I get a document contains no data and the php module crashes. After speaking with numberous people in #php and #horde as well as reading documents and so on the conclusion was its an IMAP problem or more than likely directly related to php-imap. I have tried to get a core dump according to the documents at: http://bugs.php.net/bugs-generating-backtrace.php But while running httpd within gdb I cant seem to access the web server and hence actually try to login to horde via imp. Version-Release number of selected component (if applicable): php-4.1.2-7.2.6.src.rpm How reproducible: Always Steps to Reproduce: -Install imap-2002-1.src.rpm, rebuild, install the associated rpm. ***NOTE: I have tried this with both the 2000c and 2001b rpms from both the stock RH7.2 install and from up2date. -Install libmcrypt-2.5.7.tar.gz -vi /etc/ld.so.conf and add /usr/local/lib -run ldconfig; check that lib is accessible. -Install mhash-0.8.18.tar.gz -run ldconfig; check that lib is accessible. -Install mcrypt-2.6.4.tar.gz -run ldconfig; check that lib is accessible. -rpm -ivh php-4.1.2-7.2.6.src.rpm -change to SPEC dir and edit php.spec adding to the top of the configure options --with-mcrypt \ -rpmbuild -ba php.spec -service httpd stop -rpm -e php php-imap php-pgsql php-mysql php-ldap (only ones installed) -I have /etc/php.ini backed up (known working copy only mods are file uploads enabled and <? allowed) -rpm -ivh php php-imap etc from the newly created rpms. -cd /usr/share; rm -rf pear; tar xvfz /root/horde/pear-1.1.tar.gz ***NOTE: I have attempted only using PEAR from the rpm php install as well with no luck. -cp /etc/php.ini.BAK /etc/php.ini -service httpd start -access horde imp login. Actual Results: php module crashes Expected Results: php to authenticate via an imap connection and login. Additional info:
Comment 1 Jason Nielsen 2003-07-17 14:38:40 UTC
Mistake: Not a totally stock RH 7.2 (I was thinking of the 7.3 system I attempted to use). This system has been run through up2date up until a month or so ago. The only known non-stock setup is we are using Courier-0.39. But I would like to note that I was using the imap and imap-devel packages from RH during compilation. AMOF php will not compile without them. More specifically rfc822.h If I remember correctly. - Jason
Comment 2 Joe Orton 2003-07-17 14:44:20 UTC
If you remove all your self-compiled php RPMs, and install the binary RPMs via up2date (or from FTP or whatever), does php-imap work?
Comment 3 Jason Nielsen 2003-07-17 17:17:52 UTC
I have put together a truly stock RH7.2 machine. Did all the compilation as stated above etc. But this time I set up the apache server on this new machine (vmware). I then wrote a php script that will connect to the original 7.2 server, login via imap and list my mailboxes. This worked. I moved this php script to the production 7.2 server and attempted to use it and it failed. The same rpms are installed on both systems. I simply moved the php rpms from the new 7.2 machine to the old one as before just to insure I had the same ones. So my current view is this is NOT a php src.rpm problem. Nor an mcrypt/libmcrypt/mhash problem. I also do not believe this is a Courier issue since I am connecting to the same imap server in both cases. So the question is what on this older 7.2 server (up2date machine) has changed that would cause the imap authentication/connection to fail even when using php rpms from a machine that they work on or using the rpms from Redhat? Considering this is now obviously a problem on our side I suppose this bug can be closed as a user side issue or the like. I suppose next Ill try to run all the up2date patches to the test machine and see if it continues to work.
Comment 4 Jason Nielsen 2003-07-17 17:18:29 UTC
Yes. If I use the .rpm files from update.redhat.com php-imap works.
Comment 5 Joe Orton 2005-01-25 16:46:23 UTC
Thanks for the report. This is a mass bug update; since this release of Red Hat Linux is no longer supported, please either: a) try and reproduce the bug with a supported version of Red Hat Enterprise Linux or Fedora Core, and re-open this bug as appropriate after changing the Product field, or, b) if relevant, try and reproduce this bug using the current version of the upstream package, and report the bug upstream. c) report the bug to the Fedora Legacy project who may wish to continue maintenance of this package.