I am using Yocto to create a build including apache2 but I have a hard time adding php support. I had it running previously (read: last year) but since then there have been changes to the meta-webserver layer in meta-openembedded. From the README file in meta-webserver:
"This layer used to provide a modphp recipe that built mod_php, but
this is now built as part of the php recipe in meta-oe. However, since
apache2 is required to build mod_php, and apache2 recipe is in this
layer and recipes in meta-oe can't depend on it, mod_php is not built
by default. If you do wish to use mod_php, you need to add "apache2"
to the PACKAGECONFIG value for the php recipe in order to enable it."
I have added the following line to php in my own layer:
PACKAGECONFIG_append = " apache2"
But I get compilations error when it can't find what appears to be apache include files when compiling mod_php (I include only one error below, I get a similar error for ap_config.h as well):
In file included from /home/martin/Yocto/poky/rpi/tmp/work/x86_64-linux/php-native/5.6.12-r0/php-5.6.12/sapi/apache2handler/mod_php5.c:26:0:
| /home/martin/Yocto/poky/rpi/tmp/work/x86_64-linux/php-native/5.6.12-r0/php-5.6.12/sapi/apache2handler/php_apache.h:24:19: fatal error: httpd.h: No such file or directory
| compilation terminated.
Has anyone managed to compile apache2 with php support lately and can give some assistance on how to do it? Thanks!
With valued help from Armin Kuster I managed to solve my issue. Armin noticed that PACKAGECONFIG_append = " apache2" overrides the existing PACKAGECONFIG and sets "apache2" only. Based on his suggestion I changed my bbappend file to include the following:
DEPENDS = "apache2"
RDEPENDS_${PN} = "apache2"
PACKAGECONFIG = "sqlite3 apache2 ${#bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam', '', d)}”
I don’t know if the DEPENDS and RDEPENDS are necessary any longer but they don’t seem to hurt.
I then realised that just adding 'php' to my layer.conf doesn't build the binaries like they did in the past. I had to explicitly specify php-cli and php-modphp. My layer.conf now includes this:
IMAGE_INSTALL_append = " apache2 php php-cli php-modphp"
With this the PHP recipe builds and includes both the php binary and the php apache module. However, the file /etc/apache/modules.d/70_mod_php5.conf does not load the PHP module since the PHP5 environment variable is not defined (see default file below). I didn't know where to specify the environment variable so instead I ended up overriding this file in my own layer and in my version I simply removed the IfDefine.
# vim: ft=apache sw=4 ts=4
<IfDefine PHP5>
# Load the module first
<IfModule !sapi_apache2.c>
LoadModule php5_module /usr/lib/apache2/modules/libphp5.so
</IfModule>
# Set it to handle the files
AddHandler php5-script .php .phtml .php3 .php4 .php5
AddType application/x-httpd-php-source .phps
DirectoryIndex index.html index.html.var index.php index.phtml
</IfDefine>
I hope that this can be of help to others with the same issue.
To add PHP support with apache in yocto , make the following changes in the bitbake recipe file.
Below is the diff output of the php.inc file
10c10
< openssl libmcrypt"
---
> openssl libmcrypt apache2-native apache2"
52c54,55
< EXTRA_OECONF = "--enable-mbstring \
---
> EXTRA_OECONF = "--with-apxs2=${STAGING_BINDIR_CROSS}/apxs \
> --enable-mbstring \
129c132
< if ${#bb.utils.contains('PACKAGECONFIG', 'apache2', 'true', 'false', d)}; then
---
> if ${#bb.utils.contains('PACKAGECONFIG', 'apache2', 'true', 'true', d)}; then
200c203
< PACKAGES = "${PN}-dbg ${PN}-cli ${PN}-cgi ${PN}-fpm ${PN}-fpm-apache2 ${PN}-pear ${PN}-phar ${MODPHP_PACKAGE} ${PN}-dev ${PN}-staticdev ${PN}-doc ${PN}"
---
> PACKAGES = "${PN}-dbg ${PN}-cli ${PN}-cgi ${PN}-fpm ${PN}-fpm-apache2 ${PN}-pear ${PN}-phar ${MODPHP_PACKAGE} ${PN}-dev ${PN}-staticdev ${PN}-doc ${PN} ${PN}-modphp"
236a240
> #FILES_${PN} += "${sysconfdir}"
Hope , this helps to work out :)
Related
I'm using the latest PHP packages available from https://launchpad.net/~ondrej/+archive/ubuntu/php .
When I build and install the OCI8 extension, everything appears to be in order, but despite enabling the extension in the PHP-FPM configuration, its presence is not reflected in the output from phpinfo().
The following Gist details the exact process that I'm using to configure, build, and install the OCI8 PHP extension:
https://gist.github.com/cbj4074/fa761f60b6f8db431539d76ebfba828e
The very same process and configuration work perfectly well on Ubuntu 16.04 LTS, so it seems that there is some fundamental difference on Ubuntu 18.04 LTS, whether with the operating system or the PHP packages in question.
As a bit of important (and I suspect relevant to this issue) background information, on Ubuntu 18.04 LTS, the extension fails to load in the CLI environment out-of-the-box, with the error:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20160303/oci8.so' - libmql1.so: cannot open shared object file: No such file or directory in Unknown on line 0
I resolved the issue like so:
# echo 'LD_LIBRARY_PATH="/opt/oracle/instantclient_12_2"' >> /etc/environment
I thought that perhaps adding the LD_LIBRARY_PATH to the PHP-FPM environment configuration might resolve the equivalent issue there:
# echo "env['LD_LIBRARY_PATH'] = /opt/oracle/instantclient_12_2" >> /etc/php/7.2/fpm/pool.d/www.conf
# systemctl restart php7.2-fpm
This does indeed cause the LD_LIBRARY_PATH value, as specified, to be reflected in both the Environment section of phpinfo() (when rendered via PHP-FPM + NGINX and requested from a browser) and the PHP Variables section, as $_SERVER['LD_LIBRARY_PATH'].
Oddly, even with PHP-FPM's logging set to debug, I don't see any trace of the libmql1.so error that I experience with the CLI. The OCI8 extension simply fails to load, silently. display_startup_errors = On in PHP-FPM's effective php.ini, too.
I elected to see if the OCI8 extension works in Apache, on the same server, and it does, provided I add export LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2 to /etc/apache2/envvars; in its absense, Apache complains on startup:
PHP Warning: PHP Startup: Unable to load dynamic library 'oci8.so' (tried: /usr/lib/php/20170718/oci8.so (libmql1.so: cannot open shared object file: No such file or directory), /usr/lib/php/20170718/oci8.so.so (/usr/lib/php/20170718/oci8.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
None of this business with the LD_LIBRARY_PATH is necessary on Ubuntu 16.04 LTS, and based on my observations herein and the comments regarding https://stackoverflow.com/a/45242468/1772379 , that changed in Ubuntu 17.10 and Ubuntu 18.04 LTS.
Has anybody else tried this, on Ubuntu 18.04 LTS, specifically?
I've tried this on two different Vagrant VMs, laravel/homestead box 6.0.0, and ubuntu/bionic64 box v20180509.0.0, and the behavior is the same in both.
Any other ideas would be most appreciated!
EDIT 1:
I asked about this issue on the package maintainer's GitHub tracker and he suggested that the problem stems from failing to set an appropriate RPATH at compile time.
I explain in my reply that I am setting an appropriate value, but the issue remains closed.
I do notice an interesting detail, however, which is that the compiled extension on Ubuntu 18.04 uses RUNPATH (and not RPATH, which is used in Ubuntu 16.04). If PHP-FPM ignores RUNPATH, and looks only for RPATH, it would explain this behavior.
EDIT 2:
This still-open report looks like an excellent candidate for having introduced the observed behavior:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859732
(discovered through comments on use RPATH but not RUNPATH? )
EDIT 3:
On a commenter's advice, I reexamined updating the ld configuration before building the extension and that resolved the issue! I had tried this before, but must have overlooked something between build attempts:
# echo /opt/oracle/instantclient_12_2 > /etc/ld.so.conf.d/oracle-instantclient.conf
# ldconfig
I still don't know why LD_LIBRARY_PATH doesn't work as it should in this instance, but adding the Instant Client library path to the linker configuration seems a better approach besides.
EDIT 4:
I stated in my previous edit that modifying the ldconfig constitutes a better approach, but came to realize (on a commenter's good advice) that doing so can cause undesirable library conflicts, because the effects are system-wide.
In hindsight, it makes sense to minimize the "collateral damage" from runtime library linkage modifications by limiting them to the execution environment via the LD_LIBRARY_PATH. Accordingly, I am motivated to determine why this does not work on Ubuntu 18.04 LTS.
I feel that I have established definitively that the PHP-FPM daemon ignores LD_LIBRARY_PATH on Ubuntu (and has since at least Ubuntu 16.04 LTS; see Comments for explanation).
The ld.so(8) manpage states (in relation to the order in which runtime library paths are searched):
Using the environment variable LD_LIBRARY_PATH (unless the executable is being run in secure-execution mode; see below). [sic] in which case it is ignored.
As yet, I cannot think of any other reason for which the path would be ignored. Of secure-execution mode, the same document says:
Secure-execution mode
For security reasons, the effects of some environment variables are voided or modified if the dynamic linker determines that the binary
should be run in secure-execution mode. (For details, see the discussion of individual environment variables below.) A binary is exe‐
cuted in secure-execution mode if the AT_SECURE entry in the auxiliary vector (see getauxval(3)) has a nonzero value. This entry may
have a nonzero value for various reasons, including:
* The process's real and effective user IDs differ, or the real and effective group IDs differ. This typically occurs as a result of
executing a set-user-ID or set-group-ID program.
* A process with a non-root user ID executed a binary that conferred capabilities to the process.
* A nonzero value may have been set by a Linux Security Module.
Firstly, Secure-Execution Mode seems not to be in effect, as the PHP executables don't exhibit this flag (AT_SECURE is 0):
LD_SHOW_AUXV=1 /usr/sbin/php-fpm7.1 -daemonize --fpm-config /etc/php/7.1/fpm/php-fpm.conf
AT_SYSINFO_EHDR: 0x7ffc569e1000
AT_HWCAP: 178bfbff
AT_PAGESZ: 4096
AT_CLKTCK: 100
AT_PHDR: 0x55ceab0c4040
AT_PHENT: 56
AT_PHNUM: 9
AT_BASE: 0x7f823c77f000
AT_FLAGS: 0x0
AT_ENTRY: 0x55ceab19e360
AT_UID: 0
AT_EUID: 0
AT_GID: 0
AT_EGID: 0
AT_SECURE: 0
AT_RANDOM: 0x7ffc56962349
AT_HWCAP2: 0x0
AT_EXECFN: /usr/sbin/php-fpm7.1
AT_PLATFORM: x86_64
It occurred to me that the child FPM pool processes might exhibit different AT_SECURE values, but the output is identical for the PHP-FPM daemon itself, as well as any child processes. The parent and the children all have the following values:
# od -t d8 /proc/851/auxv
0000000 33 140722944548864
0000020 16 395049983
0000040 6 4096
0000060 17 100
0000100 3 93903778242624
0000120 4 56
0000140 5 9
0000160 7 140365152313344
0000200 8 0
0000220 9 93903779136352
0000240 11 0
0000260 12 0
0000300 13 0
0000320 14 0
0000340 23 0
0000360 25 140722944193929
0000400 26 0
0000420 31 140722944196579
0000440 15 140722944193945
0000460 0 0
Secondly, none of these reasons seem to apply, given the following:
1) There is no indication that PHP-FPM or its child processes have real and effective user or group IDs that differ (thanks to https://unix.stackexchange.com/a/202359 for this command):
# ps -e -o user= -o ruser= | awk '$1 != $2'
systemd+ systemd-timesync
systemd+ systemd-resolve
beansta+ beanstalkd
message+ messagebus
daemon root
systemd+ systemd-network
# ps -e -o group= -o rgroup= | awk '$1 != $2'
systemd+ systemd-timesync
systemd+ systemd-resolve
beansta+ beanstalkd
message+ messagebus
daemon root
systemd+ systemd-network
2) The binaries in question do not have any capabilities (the following commands produce no output):
# getcap /usr/lib/php/20170718/oci8.so
# getcap -r /opt/oracle/instantclient_12_2/
3) I have ensured that AppArmor is disabled (it doesn't have a policy that should affect PHP-FPM, anyway):
# systemctl disable apparmor
Synchronizing state of apparmor.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable apparmor
# reboot
# aa-status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
So, why does PHP-FPM ignore LD_LIBRARY_PATH, if not for any of the aforementioned reasons?
EDIT 5 (Solution):
An astute commenter, #vinc17 , points-out that on systems running systemd, environment variables, such as LD_LIBRARY_PATH, are not necessarily propagated to processes that are started via a systemd Unit.
In other words, PHP-FPM isn't "ignoring" LD_LIBRARY_PATH, but rather, it is not being conveyed to the process. And attempts to set LD_LIBRARY_PATH within the PHP-FPM configuration are futile, because it's too late to do anything useful with the value.
On this advice, it occurred to me to set LD_LIBRARY_PATH in the systemd context, namely, in the Unit file(s) that start the PHP-FPM daemon(s), in which case PHP-FPM loads the OCI8 extension successfully.
Needless to say, we want to avoid editing the package maintainer's file (to avoid conflicts during future upgrades), so we extend it instead:
# mkdir /etc/systemd/system/php7.1-fpm.service.d
# touch /etc/systemd/system/php7.1-fpm.service.d/environment.conf
To this file we add the following:
[Service]
Environment=LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2
And to make the change effective:
# systemctl daemon-reload
# systemctl restart php7.1-fpm
For a more complete example, which addresses multiple co-installed PHP versions, please see my post at https://github.com/oerdnj/deb.sury.org/issues/865#issuecomment-395441936 .
First, Debian bug 859732 is a completely different issue (I would even say an opposite issue): for this bug, several versions of the library are present in the search path (one in some directory specified by LD_LIBRARY_PATH and a different one in some directory specified by the run path), but the wrong one is chosen by the dynamic linker.
In your case, the problem is that the requested library is not found anywhere in the search path. Note also that in your case, it is PHP that seems to try to open the library (via dlopen?), since the message starts with "PHP Warning:". However, it seems that the mechanisms are the same as with usual dynamic linking.
After installing the library, what you need is at least one of:
Nothing special if the library has been installed in a directory that is searched by default. Since you get an error, this is not your case.
Providing the directory in a run path, which must be specified at compile time of the software that will need the library. The problem is that under Linux, this is not done in standard by the build tools, and it may be complex to do it right without breaking other things. However, in the context of dlopen, the software (here, PHP) may have set up what one can call a "plugin search path", where you can put your libraries.
Providing the directory in LD_LIBRARY_PATH. This is what you tried, but your LD_LIBRARY_PATH seems incorrect. Libraries are usually installed in subdirectories named lib (or lib32 or lib64 in specific cases). So, export LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2 seems wrong. Search for the full pathname of the library oci8.so, and just take the directory part of this pathname for LD_LIBRARY_PATH.
Note: strace may be useful to see what directories are considered to search for the libraries. EDIT: ldd and objdump -p are other useful tools to find what's going on with the search paths.
EDIT 2: Another point to note when choosing to use a run path is that indirect library dependencies are found when RPATH is used, but not when RUNPATH is used (so, in this latter case, all dependencies also need to have a run path if they depend on other libraries so that all libraries can be found without resorting to LD_LIBRARY_PATH). This is documented in recent versions of the ld.so(8) man page:
Using the directories specified in the DT_RUNPATH dynamic section attribute of the binary if present. Such directories are searched only to find those objects required by DT_NEEDED (direct dependencies) entries and do not apply to those objects' children, which must themselves have their own DT_RUNPATH entries. This is unlike DT_RPATH, which is applied to searches for all children in the dependency tree.
This is probably why, without using LD_LIBRARY_PATH, this was working with 16.04 (where RPATH is used) but not with 18.04 (where RUNPATH is used).
I use apache httpd on Centos7 (SELinux) and am trying to create an output filter to modify all served html pages. I've browsed some tutorials on how to create them, but I keep stumbling on step one even before I get to the coding part.
Currently I have this in my httpd.conf
ExtFilterDefine portal_header mode=output intype=text/html cmd="/var/www/root/main/portal/portal.php"
SetOutputFilter portal_header
To pinpoint my problem I have deleted all the actual code in the file /var/www/root/main/portal/portal.php for the moment and currently it looks like this
#!/usr/bin/php
<php?
/* test */
?>
But when I know try to access any html on the server I get "500 Internal Server Error". After commenting out the SetOutputFilter line in httpd.conf the pages work so the error is generated by the filter.
In my error log it reads
[Fri Feb 10 14:36:55.458174 2017] [ext_filter:error] [pid 171495] (13)Permission denied: [client 10.2.8.109:49278] AH01458: couldn't create child process to run `/var/www/root/main/portal/portal.php'
[Fri Feb 10 14:36:55.458215 2017] [ext_filter:error] [pid 171495] (13)Permission denied: [client 10.2.8.109:49278] AH01467: can't initialise output filter portal_header: aborting
I have at least
changed the file permissions to 777
verified that php is located at /usr/bin/php and owned by apache group with proper rights
tried to add and remove ScriptAlias and/or SetHander cgi-script for the directory in httpd.conf
tried with completely empty script file
but none of the above has any effect. The only change in matters was that when I deliberately mis-spelled the file name I got "No such file or directory" error instead.
Does anyone have an idea what I should do to make this work? For the moment I would be happy to see the script to even do nothing at all, if it just didn't break, and only afterwards add some functionalities into it.
UPDATE: I was able to pinpoint the problem to SELinux policies, since after disabling them (setenforce 0) the error vanished. So currently I'm trying to figure out how I should alter the policies.
I ran into a similar problem when trying to improve on a simple sed filter command.
According to the https://httpd.apache.org/docs/2.4/mod/mod_ext_filter.html documentation it should be possible to use a command like sed as a filter and indeed it does:
The following filter works for me and replaces global links to local ones so that i can use a docker image with data from an existing site.
# Filter configuration
# mod_ext_filter directive to define a filter which
# replaces text in the response
#
ExtFilterDefine fixtext mode=output intype=text/html \
cmd="/bin/sed s#http://ceur.ws.org#http://capri:8880#g"
<Location "/">
# core directive to cause the fixtext filter to
# be run on output
SetOutputFilter fixtext
</Location>
when trying to replace the sed command with accessing a script with
"cmd=/root/bin/filter.sh"
I got the error message :
AH01458: couldn't create child process to run `/root/bin/filter.sh'
AH01467: can't initialise output filter fixtext: aborting
which is your original reason for your question.
Now i am also looking for a better solution and tried:
cmd="/bin/bash /root/bin/filter.sh"
assuming that the shebang resolving might be the culprit. Interestingly i then get:
AH01461: apr_file_write(child input), len 0
AH01468: ef_unified_filter() failed
and that's why i am already posting this answer in the hope I'll find a proper solution soon or others might be able to help because the list of related AH014## error codes is getting longer in this Q&A thread.
See https://github.com/omnigroup/Apache/blob/master/httpd/modules/filters/mod_ext_filter.c for the relevant source code.
I am assuming that the apr_proc_create is not capable of calling scripts using a shebang. So my workaround was to
call the command directly
switch to awk
Working apache filter.conf
# Filter configuration
# mod_ext_filter directive to define a filter which
# replaces text in the response
#
ExtFilterDefine fixtext mode=output intype=text/html \
cmd="/usr/bin/awk -f /var/www/filter.awk"
<Location "/">
# core directive to cause the fixtext filter to
# be run on output
SetOutputFilter fixtext
</Location>
working awk script to filter links
# WF 2020-06-03
#
# filter HTML output thru this awk script to fix global links to local ones
#
# you might want to try out this filter from the command line with
# cat /var/www/html/index.html | awk -f filter.awk
#
# setup the replacement
BEGIN {
port=8880
host="capri"
sourceServer="http://ceur-ws.org"
targetServer=sprintf("http://%s:%s",host,port)
}
# for each line
{
# get the line
line=$0
# replace any sourceServer reference with the targetServer reference
gsub(sourceServer,targetServer,line)
# output the modified line
print line
}
/root/bin/filters.sh
#!/bin/bash
# WF 2020-06-02
# filter all html output thru this script
port=8880
host=capri
# substitute all hard links in CEUR-WS with a local link
/bin/sed s#http://ceur.ws.org#http://$host:$port#g
# try out this filter with
# cat /var/www/html/index.html | /root/bin/filter.sh | grep capri
The PHP framework I use needs OpenSSL for various features, but when executing anything related to OpenSSL, I get the following error: "Can't find ordinal 372 in DLL-file C:\wamp64\bin\apache\apache2.4.17\bin\openssl.exe".
I don't know how to correct this at all, I looked everywhere already. I'd appreciate the help, as I don't know how to fix this.
To fix the issue, two things are needed:
1) Make sure that you don't have symbolic links for libeay32.dll and ssleay32.dll in your Apache bin directory
(For example, mine is: C:\wamp64\bin\apache\apache2.4.23\bin)
If you do have symbolic links (i.e. the file size are 0 bytes), you need to download the dlls from Apache Lounge.
For example, I grabbed the two .dll files from the 64-bit version of Apache 2.4.23 hosted at https://www.apachelounge.com/download/
2) Once you have the actual .dll files restored, you need to make sure that WampServer isn't overwriting them. WampServer 3 has a configuration script that runs every time it starts. In that script it will overwrite those .dlls with symbolic links. You must DISABLE that functionality. To do so, comment out the references to those two files in: C:\wamp64\scripts\config.inc.php (mine were located at lines 133 and 139).
That should allow you to enable the mod_ssl module in Apache. You'll also need to uncomment the "Include conf/extra/httpd-ssl.conf" after you get Apache booting properly with mod_ssl enabled. (However, you'll likely need to delete most of whats in there and start over since it includes lots of hardcoded paths and bugs)
... "Can't find ordinal 372 in DLL-file C:\wamp64\bin\apache\apache2.4.17\bin\openssl.exe"
I'm speculating its PEM_SealInit or SSL_CONF_cmd_argv from OpenSSL 1.0.2; or ASN1_i2d_fp or SSL_SESSION_set1_id_context from OpenSSL 1.1.0.
# OpenSSL 1.1.0
$ find $PWD -type f -iname '*.num' -exec grep " 372" {} \;
ASN1_i2d_fp 372 1_1_0 EXIST::FUNCTION:STDIO
SSL_SESSION_set1_id_context 372 1_1_0 EXIST::FUNCTION:
...
# OpenSSL 1.0.2
$ find $PWD -type f -iname '*.num' -exec grep " 372" {} \;
PEM_SealInit 372 EXIST::FUNCTION:RSA
SSL_CONF_cmd_argv 372 EXIST::FUNCTION:
...
You will need to verify it by using dumpbin or Dependency Walker. Also see How can I find the exported function name from ordinal (export by ordinal)? on Stack Overflow.
The ordinals are created using <openssl src>\util\mkdef.pl. You can see the source code from OpenSSL's GitHub presence. Here is 1.0.2 and here is 1.1.0.
Here are the head comments for the file:
#!/usr/local/bin/perl -w
#
# generate a .def file
#
# It does this by parsing the header files and looking for the
# prototyped functions: it then prunes the output.
#
# Intermediary files are created, call libcrypto.num and libssl.num,
# The format of these files is:
#
# routine-name nnnn vers info
#
# The "nnnn" and "vers" fields are the numeric id and version for the symbol
# respectively. The "info" part is actually a colon-separated string of fields
# with the following meaning:
#
# existence:platform:kind:algorithms
#
# - "existence" can be "EXIST" or "NOEXIST" depending on if the symbol is
# found somewhere in the source,
# - "platforms" is empty if it exists on all platforms, otherwise it contains
# comma-separated list of the platform, just as they are if the symbol exists
# for those platforms, or prepended with a "!" if not. This helps resolve
# symbol name variants for platforms where the names are too long for the
# compiler or linker, or if the systems is case insensitive and there is a
# clash, or the symbol is implemented differently (see
# EXPORT_VAR_AS_FUNCTION). This script assumes renaming of symbols is found
# in the file crypto/symhacks.h.
# The semantics for the platforms is that every item is checked against the
# environment. For the negative items ("!FOO"), if any of them is false
# (i.e. "FOO" is true) in the environment, the corresponding symbol can't be
# used. For the positive itms, if all of them are false in the environment,
# the corresponding symbol can't be used. Any combination of positive and
# negative items are possible, and of course leave room for some redundancy.
# - "kind" is "FUNCTION" or "VARIABLE". The meaning of that is obvious.
# - "algorithms" is a comma-separated list of algorithm names. This helps
# exclude symbols that are part of an algorithm that some user wants to
# exclude.
I just encountered the same problem, on Windows and using xampp instead of Wamp.
Doing what's described in the commentaries of this page solved it : PHP cURL Installation.
I copied the 3 .dll files from the PHP installation directory to the apache/bin directory and rebooted xampp.
I had a working Drupal site and I tried to upgrade my 5.5 version to Drupal6. After trying to update the version from the ports collection:
cd /usr/ports/www/drupal6
make install ; make clean
I received an error:
autoconf: required version 2.68 not found
I then went to the ports directory for autoconf and ran: make install ; make clean
Everything installed correctly but when I try to reinstall drupal6 I get the same error message, which is:
=> SHA256 Checksum OK for php-5.3.5.tar.bz2.
===> Patching for php5-gd-5.3.5
===> Applying FreeBSD patches for php5-gd-5.3.5
===> php5-gd-5.3.5 depends on file: /usr/local/bin/phpize - found
===> php5-gd-5.3.5 depends on file: /usr/local/libdata/pkgconfig/xpm.pc - found
===> php5-gd-5.3.5 depends on file: /usr/local/bin/autoconf-2.68 - found
===> php5-gd-5.3.5 depends on shared library: freetype.9 - found
===> php5-gd-5.3.5 depends on shared library: png.6 - found
===> php5-gd-5.3.5 depends on shared library: jpeg.11 - found
===> php5-gd-5.3.5 depends on shared library: t1.5 - found
===> PHPizing for php5-gd-5.3.5
Configuring for:
PHP Api Version: 20090626
Zend Module Api No: 20090626
Zend Extension Api No: 220090626
autoconf: required version 2.68 not found
*** Error code 1
Stop in /usr/ports/graphics/php5-gd.
*** Error code 1
Stop in /usr/ports/graphics/php5-gd.
*** Error code 1
Stop in /usr/ports/graphics/php5-gd.
*** Error code 1
Stop in /usr/ports/www/drupal6.
*** Error code 1
Stop in /usr/ports/www/drupal6.
*** Error code 1
Stop in /usr/ports/www/drupal6.
===> Cleaning for php5-gd-5.3.5
===> Cleaning for drupal6-6.20
My drupal site: jameshayekserv.com/drupal
shows a blank page...
my wordpress site: jameshayekserv.com/wordpress
tells me:
Your PHP installation appears to be
missing the MySQL extension which is
required by WordPress.
I then tried to install the php5 port and get the same exact error as above, autoconf: required version 2.68 not found, although it is installed.
I also tried the command:
make config
while in the php5 directory. I did not see any options pertaining to MySQL
At one point I got tired of using ports and downloaded Drupal-7.0 from the Drupal site and then scp the file to my server.
I then renamed my /usr/local/www/drupal6 folder to RENAMED_drupal6
Placed the drupal-7.0 folder in the /www directory.
I then changed the drupal.conf file from:
jameshayekserv# less /usr/local/etc/apache22/Includes/drupal.conf
Alias /drupal "/usr/local/www/drupal5/"
<Directory "/usr/local/www/drupal5/">
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
to:
jameshayekserv# less /usr/local/etc/apache22/Includes/drupal.conf
Alias /drupal "/usr/local/www/drupal-7.0/"
<Directory "/usr/local/www/drupal-7.0/">
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
I then restarted apache:
apachectl graceful
After thinking I was done I tried to visit my drupal site:
jameshayekserv.com/drupal and was greeted with a blank page.
I can't install from ports after updating, I can't install by placing the folder in the directory and I can't get rid of the "autoconf: required version 2.68 not found" error even though I installed the latest port of autoconf.
I am stuck and down a drupal site with no clue what to do.
Try this:
cd /usr/ports/devel/autoconf-wrapper && make clean && make deinstall && make reinstall
Threre is a hint in /usr/ports/UPDATING about this:
20101204:
AFFECTS: autotools
AUTHOR: autotools#FreeBSD.org
The next stage in the ongoing cleanup of autotools-using ports is
a refactoring of bsd.autotools.mk so that version numbers are no longer
needed within the USE_AUTOTOOLS stanza. There is either
autoconf213/autoconf or automake14/automake (for the legacy versions,
and the currently available versions). This will considerably reduce
the amount of tree-wide patching in future on an update.
IMPORTANT: if you have either devel/autoconf-wrapper or
devel/automake-wrapper installed on your system (and you most likely do)
PLEASE update these ports to their new versions before updating anything
else -- Bad Things[tm] are likely to happen otherwise.
I am getting both modules listed as installed / configured when I use:
php -m
or if I use:
php -i
but when I use:
$m = new Memcache;
// or
$m = new Memcache();
// or
$m = new Memcached();
//or
$m = new Memcached;
I get the following error:
Fatal error: Class 'Memcached' not found
I am running on a Mac - OS X (10.5.7) with default install of apache & php. Additionally, I have memcached running as a daemon on 127.0.0.1:11211 and libmemcache as required by the php-memcached library. I have restarted apache tons of times and even done a machine restart.
Does anyone know why the modules/extensions show up in the command line but not in my phpinfo()? I am literally stumped, after 3 hours of googling, I am just about ready to give up.
Also, please note, my phpinfo() outputs my ini files as follows AND they are both the exact same file:
Configuration File (php.ini) Path: /etc
Loaded Configuration File: /private/etc/php.ini
UPDATE:
Apache is failing to load the extension.
[Fri May 14 04:22:26 2010] [warn]
Init: Session Cache is not configured
[hint: SSLSessionCache] PHP Warning:
PHP Startup: Unable to load dynamic
library
'/usr/lib/php/extensions/no-debug-non-zts-20060613/memcached.so'
- (null) in Unknown on line 0 PHP Warning: PHP Startup: Unable to load
dynamic library
'/usr/lib/php/extensions/no-debug-non-zts-20060613/memcache.so'
- (null) in Unknown on line 0
Does anyone know why or how this would happen? Both of the files referenced above DEFINITELY ARE there. Should I move this question to server fault?
Your webserver is probably using mod_php, which is a seperate bit of code from the standalone (CLI) interpreter. If they are both using the same ini file, and the memcache extension is configured in the ini file, then it sounds like for some reason, the mod_php is failing to load the extension - check your webserver error_log for startup errors.
It may be that the mod_php was compiled without memcache support (most extensions need to have a stub file linked into the php code, even though the bulk of the code is not linked until run time). Or it may be a permissions problem on the shared object file. Or your webserver may be running chroot, and unable to find the extension (which would also mean that although the ini files appear to have the same path, this is relative to different roots).
HTH
C.
because both versions use different php.ini
place your php.ini into location noted in the phpinfo() outout
I would suspect that the issue revolves around permissions. When you run php from comand line, it runs as the user invoking it. When run as an apache module, it runs as "nobody".
I would assume that the memcached.so file, or the directory it's in does not have proper permissions.
I stumpled upon this post and was having the exact same problem with an extension in my php -i but not in phpinfo(). Mine was a permissions problem because of selinux on a CentOS machine. I had to change ownership and permissions and now it is working as expected.
Set php path in environment variables as given below.
Right-click on "My Computer"
Properties
Advanced Tab > Environment Variables
Under System variables, scroll down to find "Path", select and click on Edit.
Add path to your php install on the end (make sure to precede with semi-colon ";"). Example: ";C:\php7"
Click Ok.