I am having a problem using xdebug w/PHP.
When I start Apache, xdebug does not load. In the log file it says:
"Cannot load Xdebug - it was built with configuration
API220131226,NTS,debug, whereas running engine is API220131226,NTS"
What does that mean? Which of the two, PHP or xdebug, is built incorrectly?
I am using:
Linux RHEL 7 on EC2
PHP 5.6 (Built from Source)
XDebug 2.3.3
PHP build options:
./configure --with-apxs2=/usr/bin/apxs --with-mysqli --with-libdir=/lib64 --enable-mbstring --with-gettext --with-libxml-dir=/usr/local/bin --enable-debug
XDebug build options:
./configure --with-libdir=/lib64
Other people on SO have mentioned that maybe the wrong phpize was being used.
I only have one copy of 'phpize' located in /user/local/bin
php-config --version returns 5.6.12
Solved!
When building PHP, make sure to use options --enable-debug --enable-phpdbg.
I had added options to the ./configure step.
The solution was to use "make distclean".
Related
I'm using CentOS 7 and building a PHP 7.4.10 rpm from source. We've previously been using PHP 7.2 with gmp located at /usr/lib64/, so ./configure in the spec file takes --with-gmp=/usr/lib64. This works with no problem, and I've also tested that it still works with PHP 7.3.22. Building PHP 7.4.10 however hits this error: configure: error: Unable to locate gmp.h.
$ locate gmp.h
/usr/include/gmp.h
$ locate gmp.so
/usr/lib64/libgmp.so
/usr/lib64/libgmp.so.10
/usr/lib64/libgmp.so.10.2.0
%build
cd %{_builddir}/php-%{version}
export CC=/usr/local/gcc/bin/gcc
export CXX=/usr/local/gcc/bin/g++
export CFLAGS="-O3 -m64 -isystem/usr/local/gcc/include -L/usr/local/gcc/lib64 -Wl,--rpath=/usr/local/gcc/lib64 "
export CXXFLAGS=$CFLAGS
./configure --with-gmp=/usr/lib64 --enable-bcmath --enable-ftp --with-curl --with-openssl --enable-mbstring
make -j8
$ rpm -qa | grep -i gmp
gmp-devel-6.0.0-15.el7.x86_64
gmp-6.0.0-15.el7.x86_64
I've tried putting a symlink between /usr/include/gmp.h and /usr/lib64/gmp.h, which didn't work.
I've also tried adding -isystem/usr/include and -isystem/usr/include/gmp.hto CFLAGS, CPFLAGS, and CXXFLAGS.
I'm especially baffled since something seems to have changed for PHP 7.4, but I can't find any upgrade notes for it.
--with-gmp=/usr/lib64 searches for the files in /usr/lib64/include and /usr/lib64/lib64. You need to use --with-gmp=/usr or --with-gmp=shared.
It's usually quite helpful to consult distribution build scripts when encountering such issues, such as the PHP 7.4 RPM SPEC file for CentOS. Further below, you will see references to %{_prefix}, which stands for /usr.
I have just built and installed (./configure, make, make install) the actual php version 5.6.9 (from http://php.net/downloads.php) on my Debian squeeze.
Typing php --version in the console brings PHP 5.6.9, as expected.
Now I want to use this version in (a newly restarted) apache2 and to test I use
<?php phpinfo(); ?>
The website shows PHP 5.3.3.
What am I missing? Where do I have to connect apache2 to php and how? Which module or library I have to replace? Where?
I solved it usig the tipps from sergey (see remarks above)
install apache2-dev
locate apxs (which was on /usr/bin/apxs2)
change to the php source package:
configure --with-apxs2=/usr/bin/apxs2 --with-mysql
make clean (! VERY IMPORTANT: Otherwise it won't compile!)
make
make test
make install
works now!
Two addidional notes for joomla users
a) configure --with-apxs2=/usr/bin/apxs2 --with-mysql --with-zlib
(uses zlib)
b) change "mysqli" to "mysql" in the old joomla/configuration.php files.
I'm trying to cross compile php for arm and have good progress but I'm totally stuck where it wants to run the php itself (have no idea why). as it is an arm binary and not intel (my building platform) it won't run:
/bin/sh: /path-to-build/sapi/cli/php: cannot execute binary file
How can I fix this? The configure script understood I'm cross compiling but didn't do anything about it (from configure log):
checking whether the C compiler (/path-to-compiler/arm-none-linux-gnueabi-gcc) is a cross-compiler... yes
I'm compiling php-5.3.6 with configure command line:
export CC=/path-to-cc/arm-none-linux-gnueabi-gcc
../configure --prefix=/prefix-path/ --host=arm-none-linux-gnueabi
--disable-libxml --disable-dom --disable-openssl
--without-iconv --without-openssl --disable-simplexml
--disable-xml --disable-xmlreader --disable-xmlwriter
--without-pear --without-sqlite --without-sqlite3
--disable-pdo --without-pdo-sqlite
I was able to resolve this my own by disabling phar. I hope disabling so much modules won't break something internal.
Build without cross compiling and then, when cross compiling, point to the host version of php by overrididing a variable in the makefile on the command line when running make.
Something like:
make PHP_VAR_NAME=path to php built for host
I managed to compile PHP for arm with the following parameters:
export PATH="$PATH:/toolchains/gnu_cortex-a9_tools/usr/bin"
export ARCH=arm
configure script:
./configure --build=x86_64-unknown-linux-gnu --host=arm-linux-uclibcgnueabi --prefix=/usr/arm CC="arm-linux-uclibcgnueabi-gcc --sysroot=/toolchains/gnu_cortex-a9_tools/" --disable-libxml --disable-dom --without-iconv --without-openssl --disable-simplexml --disable-xml --disable-xmlreader --disable-xmlwriter --without-pear --without-sqlite3 --disable-pdo --without-pdo-sqlite --disable-phar
followed by
make
I managed to solve similar issue while cross-compiling PHP 5.6.0 by editing Makefile after running configure script. Just replace all occurrences of
$(top_builddir)/$(SAPI_CLI_PATH)
with
/usr/bin/php
Where /usr/bin/php is your host php cli. Make sure it is installed, e.g., sudo apt-get install php5-cli for Debian/Ubuntu.
After doing so phar extension builds fine
Here is a quick overview:
I just finished compiling PHP 5.3.5 and made the attempt to compile "--with" a number of different extensions. Among the extensions that I need are mbstring and intl. I can manually phpize, configure, make, make install the mbstring extension and it seems to work fine. However, I am unable to do the same for intl.
My ./configure line looks like this:
./configure --with-openssl --with-pcre-regex --enable-calendar
--with-curl --enable-exif --enable-ftp --with-gd
--with-mhash --enable-mbstring --with-mysql --enable-zip
--enable-intl --with-icu-dir=...
The code compiles without problem: ./configure... make, make install
I used the php.ini-production for my php.ini configuration and I configured Apache to use php-cgi for a specific domain, and that works fine as well.
A quick:
<?php phpinfo() ?>
reveals that I am in fact running the newer version of PHP. However, the extensions specified in the "./configure..." line do not show up anywhere on the PHP info page.
After a bit of scouting I found that I could run phpize on a single extension in the PHP source folder, then compile a build of the specific module and install it in my PHP extension directory. After adding:
extension=MY_EXT
in my php.ini, the extension showed up on my phpinfo() page.
So can anyone explain why --with-mbstring doesn't seem to have an effect on my compilation?
I had no compilation problems for the intl extension, but moving the intl.so file to my PHP extensions directory and adding an extension line in my php.ini has no effect.
From php.net, have you tried
If your ICU is installed to a
non-standard directory then you might
want to specify its location in
LD_LIBRARY_PATH environment variable
so that dynamic linker can find it: $
export LD_LIBRARY_PATH=/opt/icu/lib
Otherwise, if PHP and ICU are
installed to their default locations,
then the additional options to
`configure' are not needed.
Can anyone direct me to or write their experiences installing Apache and PHP on Snow Leopard?
I had this working in the past on Leopard, it would die after a security update, but was as simple as:
$ ./configure --enable-layout=Darwin --enable-mods-shared=all
$ make
$ sudo make install
and I was up and running again.
Since the Snow Leopard update I get the following issue on make command
libtool: link: cannot find the library `/usr/lib/libexpat.la' or unhandled argument `/usr/lib/libexpat.la'
make[2]: *** [htpasswd] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
As most of you know Snow Leopard (SL) is based on 64-bit architecture, and when you install Xcode 3.2 that comes with SL the gcc compiler defaults to 4.2.1 and seems to default to x86_64 not i386.
Thanks to the following websites:
http://hivelogic.com/articles/compiling-mysql-on-snow-leopard/
http://projects.serenity.de/php/
http://dawsdesign.com/drupal/comment/reply/30#comment-form
http://pixelchimp.net/blog/pixel-chimp/reverting-php-53-5210-snow-leopard(most helpful for finding the other sites)
http://www.kevinkorb.com/post/24
http://www.latko.org/2009/01/31/compiling-64-bit-apachephp-on-mac-os-x-1056/
http://www.gen-x-design.com/archives/recompiling-php-5-3-on-snow-leopard-with-freetype-support/
My Solution:
Follow the instructions on hivelogic.com for installing MySQL on SL
Install Apache 2.2.14 via instructions on http://projects.serenity.de/php/ - it uses 2.2.13 but replacing a 13 with a 14 is easy right? ;) After Apache (x86_64) is installed do the following:
cd /usr/local/apache2/bin
cp httpd /usr/sbin/
cp apachectl /usr/sbin/
As mentioned on http://www.kevinkorb.com/post/24
Compile and install packages (freetype,gettext,libjpeg,libpng,mcrypt,mhash,etc) mentioned right after the Apache install instructions on http://projects.serenity.de/php/ until IMAP, if you need IMAP then try the instructions mentioned in the url above but I didn't install since I didn't need it.
NOTE: These all compiled as x86_64 with the exception of libpng which required the the following to be compiled as 64-bit:
*export CFLAGS="-arch x86_64" ./configure
This is where all the head banging on a desk and trial and error occurred. The installation of PHP 5.3.0. The biggest issue is with ICONV which has linking issues. I searched all over Google and some others were successful by editing the iconv.c file and the Makefile by adding -lresolv to the EXTRA_LIBS= after the ./configure string was executed. I was not so lucky, but still needed to make the edits for the --without-iconv parameter to work. Also --with-xmlrpc would not work. For the iconv hacks please refer to this blog entry
So here is my ./configure string:
./configure
--prefix=/usr/local/php5
--without-iconv
--with-apxs2=/usr/local/apache2/bin/apxs
--enable-pdo
--with-gd
--with-zlib
--with-jpeg-dir=/usr/local
--with-png-dir=/usr/local
--with-libxml-dir=/usr/local
--with-curl
--with-mcrypt
--with-pdo-mysql=/usr/local/mysql
--with-mysqli=/usr/local/mysql/bin/mysql_config
--with-mysql=/usr/local/mysql
--with-mhash
--with-libxml-dir=/usr/local
--with-t1lib=/usr/local
--with-xsl
--with-freetype-dir=/usr/local
--with-gettext
--with-bz2=/usr
--with-openssl=/usr
--enable-bcmath
--enable-calendar
--enable-cgi
--enable-exif
--enable-ftp
--enable-gd-native-ttf
--enable-mbstring
--enable-soap
--enable-sqlite-utf8
--enable-cli
--enable-wddx
--enable-zip
make
sudo make install
On a final note, I downloaded PHP-5.3.2-dev (http://snaps.php.net/) and it seems to have fixed the linking issues with ICONV and XMLRPC. The only changes that I've made to the above ./configure string were replace --without-iconv with --with-iconv=/usr/local and added --with-xmlrpc. This is a dev version and I am sure that it still has bugs so use at your own discretion.
If you are having any issues please feel free to comment and I will try to help!
See here:
http://bugs.php.net/bug.php?id=49267
Basically:
Add "-lresolv" to MH_BUNDLE_FLAGS, EXTRA_LDFLAGS and
EXTRA_LDFLAGS_PROGRAM in "Makefile"
Change "ext/iconv/iconv.c"
#define iconv libiconv
to:
#define iconv iconv
As they say, worked for me.
In apache source directory
cd srclib/apr-util/xml/expat
./configure
# OR ./configure --prefix=/{{YOURDIR}}/apache/source/httpd-2.2.22/srclib/apr-util/xml/expat/
sudo make install
# OR make install
Remember to clean up your previous apache install after make install failed
cd {{YOURDIR}}/apache/
ls -la
rm -r bin
rm -r build
rm -r include
rm -r lib
Well if you have no need for a custom built version of PHP than perhaps the one Apple provides will do, but that is not the case, with the person who asked the question, or me for that matter as I seek an answer to the same question. Does anyone else have a suggestion?
Maybe you didnt install the developer tools!
The guys from Liip maintain a great package for PHP and Apache on OS X, with really easy install. The package is very suitable for development. You could check it out here: http://php-osx.liip.ch/
This package installs the (usually) latest PHP 5.3.x/5.4.x on OS X 10.6 (aka Snow Leopard) and OS X 10.7 (aka Lion) in /usr/local/php5. It installs many useful extensions (see below) and ini-settings and is what we at Liip and Local.ch use for our development. It's especially suited for Symfony 2 development. It also provides a decent php.ini with all settings configured according to "Best Practices".
You can then use the standard Apache and install MySQL (x64) with the package from the MySQL website.
Mac OS X Snow Leopard already comes with Apache 2.2 and PHP 5.3 pre-installed. Please see:
http://www.brandonsavage.net/first-glance-apples-snow-leopard/
It is probably best to leave those alone, as they are optimally configured for Snow Leopard.