From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.0.1) Gecko/20021003 Description of problem: I am using RH 8.0 with sendmail. I needed to install PHP with mhash support and have recompiled it. After installing the new RPM binaries, I noticed I lost support for the mail() function. When I re-compiled, I noticed that the logs said that it didn't find sendmail, But sendmail is in its default RH8.0 RPM location /usr/sbin/sendmail I have also tried recompiling default PHP rpms WITHOUT mhash support with the default SRC PHP RPM's. I receive the same problem. It seems if anybody recompiles PHP SRC rpm's they will wind up with out sendmail support. I have also installed sendmail-devel to see it that was the issue. It turns out it was installed all along. This is how I am recompiling... rpmbuild -bp php-blah.spec 1>bp.log -then- rpmbuild -bb php-blah.spec 1>bb.log I receive these errors. [joel@mail SPECS]$ cat bb.log | grep sendmail checking for sendmail... no checking for sendmail... no Installing Mail/sendmail.php Installing Mail/sendmail.php Any suggestions on how to fix this or point PHP in the right direction of where sendmail is located?? Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: This is how I am recompiling... rpmbuild -bp php-blah.spec 1>bp.log -then- rpmbuild -bb php-blah.spec 1>bb.log Actual Results: [joel@mail SPECS]$ cat bb.log | grep sendmail checking for sendmail... no checking for sendmail... no Installing Mail/sendmail.php Installing Mail/sendmail.php Additional info: After you install the new binaries, restart apache and view a php page that uses the mail() function, it does not work.
Have you got a broken symlink as /usr/sbin/sendmail by any chance? The alternatives system means /usr/sbin/sendmail is a symlink; if this symlink is dangling PHP will fail to detect sendmail. What's the output of: # ls -l /usr/sbin/sendmail
lrwxrwxrwx 1 root root 21 Nov 19 16:30 /usr/sbin/sendmail -> /etc/alternatives/mta I have two threads going on at the discussion groups so far, here are the links. None of the suggestions have been sucessful. The only part that I have been succesful on was to copy part of the PHP code to shell and execute it. It worked and brought up the default location like it is supposed to. Here are links to my threads. In these posts you will read more than enough documentation on what I have tried and what has not worked. I think for the most part, I need to force PHP to see the sendmail in the /usr/sbin/ directory, but I don't know what parameters to pass in the spec file. https://listman.redhat.com/pipermail/psyche-list/2002-November/007084.html https://listman.redhat.com/pipermail/psyche-list/2002-November/007107.html https://listman.redhat.com/pipermail/redhat-list/2002-November/158265.html Have you been able to recreate the problem??
Yes, reproduced here; curious.
Ah ha. I bet you are rebuilding the SRPM as a user, rather than as root? The bug is that the search path isn't being traversed correctly; the configure script is actually only looking in $PATH for the sendmail binary. (this is a bug, it is programmed to look in /usr/sbin and a few other places too, but the correct code isn't being genereated)
I am doing everything as root. Or should I say as su-root not reloggin in as the root user. But then again, that is a bad habit of constructing everything by loggin is as root all the time. The only way I was able to force it to work. To put this in the spec file above the listing. We will see how far we get. # Put the sendmail directory in # # # PROG_SENDMAIL="/usr/sbin": export PROG_SENDMAIL
So is this a bash bug, or an autoconf bug? If I run the configure script as a user, only the first element of my path is searched correctly. If I run as root, all elements are searched. autoconf's output looks proper, but I can't explain why bash's behavior differs. As a user, the sendmail search produces this from "sh -x ./configure ...": + set dummy sendmail + ac_word=sendmail + echo 'configure:7215: checking for sendmail' + echo -n 'checking for sendmail... ' checking for sendmail... + test '' = set + as_save_IFS= + IFS=: + IFS= + test -z /bin + test -f /bin/sendmail + IFS= + test -z /usr/bin:/usr/bin:/usr/sbin:/usr/etc:/etc:/usr/ucblib:/usr/lib + test -f /usr/bin:/usr/bin:/usr/sbin:/usr/etc:/etc:/usr/ucblib:/usr/lib/sendmail + PROG_SENDMAIL= + test -n '' + echo 'configure:7248: result: no' + echo no Based on that, it looks like bash grabs the first word from the "path" (extended by autoconf) based on IFS=:, but IFS is reset in the loop, so on the second iteration, it tries to grab a new word based on a different IFS variable. That doesn't happen to root. The IFS variable is still reset in the loop, but "for" searches all elements, as if the path had been broken up into an array properly to begin with: + set dummy sendmail + ac_word=sendmail + echo 'configure:7215: checking for sendmail' + echo -n 'checking for sendmail... ' checking for sendmail... + test '' = set + as_save_IFS= + IFS=: + IFS= + test -z /bin + test -f /bin/sendmail + IFS= + test -z /sbin + test -f /sbin/sendmail + IFS= + test -z /usr/bin + test -f /usr/bin/sendmail + ac_cv_path_PROG_SENDMAIL=/usr/bin/sendmail + echo 'configure:7233: found /usr/bin/sendmail' + break 2 + PROG_SENDMAIL=/usr/bin/sendmail + test -n /usr/bin/sendmail + echo 'configure:7245: result: /usr/bin/sendmail' + echo /usr/bin/sendmail
It's an bug in the autoconf macro AC_PATH_PROG, which was fixed in autoconf 2.54. Private bug 69354 was filed against this exact issue already.
Thanks guys for your help. The insertion into the PHP code worked for me. On to the next problem... You can close this issue out if you want.
autoconf 2.56 is now available in Raw Hide which has a fix for this bug, so I'm marking this CLOSED/RAWHIDE. Upgrading to this new autoconf before rebuilding PHP is the recommended fix for this problem.