On Tue, 2018-12-25 at 15:01 -0500, John wrote: > On Mon, 2018-12-24 at 23:45 +0100, Christoph M. Becker wrote: > > On 24.12.2018 at 17:31, John wrote: > > > > > The libc-client library was installed yesterday (by dnf download from > > > Fedora) > > > because it is needed for imap support which is the reason I'm re- > > > installing > > > PHP. > > > I have PHP 7.2.9 running at the moment and there was no problem with that > > > installation but it doesn't have imap support installed. > > > > Hmm, did you install a libc-client-*devel* package? A libc-client > > package is not sufficient to compile the extension. > > > > > I copied the link that you referenced and it is identical to the config.m4 > > > file > > > in the PHP 7.3.0 distribution that I downloaded. From your note I think > > > that > > > you feel that this patch is not complete but I don't know how to check. I > > > am > > > willing to try any suggestions that you might have. > > > > My point is (that I think) that configure does not properly check > > whether the necessary stuff is installed, and may yield a strange error > > message otherwise (“error: utf8_mime2text() has new signature, but > > U8T_CANONICAL is missing.”), instead of clearly stating that required > > headers or the actual library are missing. If I'm right, this would be > > a bug (in my opinion), and should be fixed. > > ============================================ > Yes, I had thought of that but Fedora doesn't have a libc-client-devel (or > dev) > available so I figured there must not be one. At your suggestion, I did a web > search and the correct library name is "uw-imap-devel" and I installed that. > Now when I compile the error is "cannot find imap library (libc-client.a) > please > check your c-client installation. This is correct, the libc-client > installtion > from Fedora didn't create a .a file, just libc-client.so. > > That is what I would have expected so I'll have to debug that separately, but > heck, it's a holiday today and I have company coming in about an hour, so I'll > do it tomorrow! > > dnf doesn't report any libc-client.a on the repository either. Wouldn't this > be > the output from the compiler? > > Merry Christmas Christoph, and thanks again for the help. I suspect I will > need > more! > > John ===================================== This is turning into an exercise in stamina! A web search came up with the same error on a Centos PHP 7.3.0 install and the solution is to change the with- libdir parameter from /usr/lib64 to lib64. This seems wrong to me and doesn't create or point to libc-client.a, so the error message is misleading. Then I got "cannot find OpenSSL's <evp.h>", even though it is in /usr/openssl- 1.1.0i/include/openssl and I had with-imap-ssl=/usr/openssl-1.1.0i. Since this error is occurring in the extensions section of the configuration, I tried variations such as "with-imap-ssl=/usr/openssl-1.1.0i/include/openssl without any luck. A web search shows that this is a fairly common problem for people installing PHP 7.3.0 but none of the answers I can find work. It is confusing that the paths to the various supporting files such as openssl vary between different extensions. The instructions seem to imply that the given path is to the base of the install (ie /usr/openssl-1.1.0i in my case) but sometimes refer to the exact path (ie /usr/openssl-1.1.0i/lib) and, apparently, sometimes not (ie /usr/openssl-1.1.0i/include/openssl leads to "cannot find OpenSSL's <evp.h>) As things stand, I seem to be able to take my pick of any error I want by playing with the configuration parameters but I can't get rid of all of them at once. FYI, here is the exact configuration I have at the moment: ./configure prefix=/usr/php-7.3.0 --enable-fpm --with-fpm-user=phpfpm --with- fpm-group=phpfpm --with-fpm-systemd --disable-short-tags --with- openssl=/usr/openssl-1.1.0i/lib --with-pcre-regex --with-imap=/usr/lib64 --with- imap-ssl=/usr/openssl-1.1.0i/include/openssl --with-pgsql=/usr/postgres- 9.6.2/bin --enable-zip --with-pear which leads to the <evp.h> error. Help! John
