How does one build the mysql extension for PHP 5.6?

Question

I am working to install PHP 5.6 and 7.0 side-by-side to facilitate migrating from PHP 5 to 7.

I am using Ondřej Surý's Ubuntu PPA, https://launchpad.net/~ondrej/+archive/ubuntu/php , which provides co-installable versions of PHP 5.6 and 7.0.

Both PHP versions work beautifully side-by-side, but there's one snag: I'm unable to build the mysql extension for PHP 5.6 (even though I'm able to build it for 7.0).

(I'm well aware that the mysql extension is obsolete and that it should be abandoned in favor of a more modern alternative. Yet, it is unreasonable for me to expect customers whose legacy applications depend on it to refactor their code while PHP 5.6 is still supported. So, I'm left with little choice in the matter...)

For anyone not familiar with this co-installable PPA, the version number is appended to the binaries, so the paths to the various PHP executables are as follows:

# ls -lah /usr/bin | grep "php"
-rwxr-xr-x  1 root   root     13K Dec 31 03:24 dh_php
lrwxrwxrwx  1 root   root      21 Feb 23 09:51 php -> /etc/alternatives/php
-rwxr-xr-x  1 root   root    3.6M Feb 23 06:37 php5.6
-rwxr-xr-x  1 root   root    3.5M Feb 23 06:58 php7.0
lrwxrwxrwx  1 root   root      25 Feb 23 10:06 php-cgi -> /etc/alternatives/php-cgi
-rwxr-xr-x  1 root   root    3.6M Feb 23 06:37 php-cgi5.6
-rwxr-xr-x  1 root   root    3.4M Feb 23 06:58 php-cgi7.0
lrwxrwxrwx  1 root   root      28 Feb 23 10:06 php-config -> /etc/alternatives/php-config
-rwxr-xr-x  1 root   root    4.1K Feb 23 06:37 php-config5.6
-rwxr-xr-x  1 root   root    4.2K Feb 23 06:58 php-config7.0
lrwxrwxrwx  1 root   root      24 Feb 23 10:06 phpize -> /etc/alternatives/phpize
-rwxr-xr-x  1 root   root    4.7K Feb 23 06:37 phpize5.6
-rwxr-xr-x  1 root   root    4.6K Feb 23 06:58 phpize7.0

Here's what I've tried:

# cd ~

# git clone https://git.php.net/repository/pecl/database/mysql.git

# cd mysql

# phpize5.6
Configuring for:
PHP Api Version:         20131106
Zend Module Api No:      20131226
Zend Extension Api No:   220131226

# ./configure --with-php-config=/usr/bin/php-config5.6
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for a sed that does not truncate output... /bin/sed
checking for cc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking how to run the C preprocessor... cc -E
checking for icc... no
checking for suncc... no
checking whether cc understands -c and -o together... yes
checking for system library directory... lib
checking if compiler supports -R... no
checking if compiler supports -Wl,-rpath,... yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for PHP prefix... /usr
checking for PHP includes... -I/usr/include/php/20131226 -I/usr/include/php/20131226/main -I/usr/include/php/20131226/TSRM -I/usr/include/php/20131226/Zend -I/usr/include/php/20131226/ext -I/usr/include/php/20131226/ext/date/lib
checking for PHP extension directory... /usr/lib/php/20131226
checking for PHP installed headers prefix... /usr/include/php/20131226
checking if debug is enabled... no
checking if zts is enabled... no
checking for re2c... no
configure: WARNING: You will need re2c 0.13.4 or later if you want to regenerate PHP parsers.
checking for gawk... gawk
checking for MySQL support... yes, shared
checking for specified location of the MySQL UNIX socket... no
checking for the location of libz... no
checking for MySQL UNIX socket location... /var/run/mysqld/mysqld.sock
checking how to print strings... printf
checking for a sed that does not truncate output... (cached) /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by cc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking for gawk... (cached) gawk
checking command to parse /usr/bin/nm -B output from cc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if cc supports -fno-rtti -fno-exceptions... no
checking for cc option to produce PIC... -fPIC -DPIC
checking if cc PIC flag -fPIC -DPIC works... yes
checking if cc static flag -static works... yes
checking if cc supports -c -o file.o... yes
checking if cc supports -c -o file.o... (cached) yes
checking whether the cc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
configure: creating ./config.status
config.status: creating config.h
config.status: executing libtool commands

So far, so good.

The problem occurs during make. I've included only a portion of the output because I'm certain that the same issues appear repeatedly.

# make
/bin/sh /root/mysql/libtool --mode=compile cc -DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 -I. -I/root/mysql -DPHP_ATOM_INC -I/root/mysql/include -I/root/mysql/main -I/root/mysql -I/usr/include/php/20131226 -I/usr/include/php/20131226/main -I/usr/include/php/20131226/TSRM -I/usr/include/php/20131226/Zend -I/usr/include/php/20131226/ext -I/usr/include/php/20131226/ext/date/lib  -DHAVE_CONFIG_H  -g -O2   -c /root/mysql/php_mysql.c -o php_mysql.lo
libtool: compile:  cc -DZEND_ENABLE_STATIC_TSRMLS_CACHE=1 -I. -I/root/mysql -DPHP_ATOM_INC -I/root/mysql/include -I/root/mysql/main -I/root/mysql -I/usr/include/php/20131226 -I/usr/include/php/20131226/main -I/usr/include/php/20131226/TSRM -I/usr/include/php/20131226/Zend -I/usr/include/php/20131226/ext -I/usr/include/php/20131226/ext/date/lib -DHAVE_CONFIG_H -g -O2 -c /root/mysql/php_mysql.c  -fPIC -DPIC -o .libs/php_mysql.o
In file included from /root/mysql/php_mysql.c:63:0:
/root/mysql/php_mysql_structs.h:114:2: error: unknown type name 'zend_resource'
  zend_resource *default_link;
  ^
/root/mysql/php_mysql_structs.h:115:2: error: unknown type name 'zend_long'
  zend_long num_links,num_persistent;
  ^
/root/mysql/php_mysql_structs.h:116:2: error: unknown type name 'zend_long'
  zend_long max_links,max_persistent;
  ^
/root/mysql/php_mysql_structs.h:117:2: error: unknown type name 'zend_long'
  zend_long allow_persistent;
  ^
/root/mysql/php_mysql_structs.h:118:2: error: unknown type name 'zend_long'
  zend_long default_port;
  ^
/root/mysql/php_mysql_structs.h:122:2: error: unknown type name 'zend_long'
  zend_long connect_errno;
  ^
/root/mysql/php_mysql_structs.h:123:2: error: unknown type name 'zend_long'
  zend_long connect_timeout;
  ^
/root/mysql/php_mysql_structs.h:124:2: error: unknown type name 'zend_long'
  zend_long result_allocated;
  ^
/root/mysql/php_mysql_structs.h:125:2: error: unknown type name 'zend_long'
  zend_long trace_mode;
  ^
/root/mysql/php_mysql_structs.h:126:2: error: unknown type name 'zend_long'
  zend_long allow_local_infile;
  ^
/root/mysql/php_mysql.c:119:2: error: unknown type name 'zend_resource'
  zend_resource *active_result_res;
  ^
/root/mysql/php_mysql.c:414:32: error: unknown type name 'zend_resource'
 static void _free_mysql_result(zend_resource *rsrc)
                                ^
/root/mysql/php_mysql.c:425:40: error: unknown type name 'zend_resource'
 static void php_mysql_set_default_link(zend_resource *link)
                                        ^
/root/mysql/php_mysql.c: In function 'php_mysql_select_db':
/root/mysql/php_mysql.c:372:57: error: request for member 'ptr' in something not a structure or union
    _mysql_result = (MYSQL_RES *)mysql->active_result_res->ptr; \

It seems that the mysql extension's source code is no longer compatible with the PHP 5.6 API.

Given that the mysql extension compiles perfectly fine under PHP 7.0 on the same server, one must wonder if the extension source was updated to work with 7.0.

I attempted to find earlier versions of the mysql extension's code, but https://pecl.php.net/package/mysql refers users only to http://git.php.net/?p=pecl/database/mysql.git;a=summary , which appears not to have any meaningful version history, such as an older branch that is designed to work with PHP < 7.0.

What else might I try? Maybe I am overlooking something silly...

Thank you for any suggestions!

UPDATE: Solution

Per the Accepted Answer, I was fetching PHP 7 source when I needed PHP 5.6 source.

This was the solution (be sure to adjust your own versions, paths, and service commands as necessary):

# git clone --depth=1 -b PHP-5.6 https://git.php.net/repository/php-src.git
# cd ./php-src/ext/mysql
# phpize5.6
#./configure --with-php-config=/usr/bin/php-config5.6
# make
# make install
# printf "; configuration for php mysql module\n; priority=20\nextension=mysql.so" > /etc/php/mods-available/mysql.ini
# ln -s /etc/php/mods-available/mysql.ini /etc/php/5.6/fpm/conf.d/20-mysql.ini
# service php5.6-fpm reload

Personally, I would just say that you shouldn't update your PHP versions if you want to use the MySQL extension as it could be unstable with later versions of PHP. — Matt, Feb 23 '16 at 21:50
serves you right for bending over backwards just to keep your clients potentially at risk. update your software, might take a week but you only need to do it once. — I wrestled a bear once., Feb 23 '16 at 21:52
why not use a userspace replacement layer for myql_* functions mapping onto mysqli. that should also allow you to more easily port those applications (if not even search and replace might do it). I don't want to question your question, but normally for mysql_* this is rather straight forward IIRC. — hakre, Feb 23 '16 at 21:52
for your make problem: could it be that you have the PHP binary API for 7 available (where you could build) but you need to switch it for 5.6 first so you can build there, too? — hakre, Feb 23 '16 at 21:54
Thanks, @Matt. Are you including PHP 5.6 in "later versions of PHP"? Ultimately, I'd like to provide my users with the ability to run their applications on PHP 5.x, while at the same time providing them the ability to test their applications on PHP 7.x. For reasons I won't belabor here, this is most simply accomplished using a single server. (I'm not interested in setting-up a second, dedicated server on which for them to test their applications on PHP 7.x.) — Ben Johnson, Feb 23 '16 at 21:55
@hakre Regarding your first comment, that's an interesting idea. I wonder if something like that would work for an application such as phpBB. As far as I know, phpBB is still bound to `mysql_*`... — Ben Johnson, Feb 23 '16 at 21:58
@Pamblam Thanks, but I'm not in a position to jump-in and start modifying my clients' code. They have been apprised of the risks and they continue to use `mysql_*` functions by their own volition. — Ben Johnson, Feb 23 '16 at 22:06
@hakre Regarding your second comment, yes, that is entirely possible, but I was (or tried to be) careful to use the 5.6-specific binaries while building the extension, as demonstrated in the commands that I issued. The API version is apparent in the output (PHP Api Version: 20131106) and the correct include directory seems to be used (`/usr/include/php/20131226`). Is there anything more specific that I seem to have overlooked? — Ben Johnson, Feb 23 '16 at 22:09
I'm not fluent with compiling PHP extensions, so nothing I spotted I fear to comment. Sounds reasonable that you checked the API version AFAIK it's a good check-point. Is it then perhaps the other way round? That the source code of the mysql extension is not for that API? I don't know when zend_long was introduced but quick checked with lxr.php.net it's not in 5.6 but in 7 (guess 64 bit long streamlining) so from the messages you try to compile PHP 7 extension source code against PHP 5.6. — hakre, Feb 23 '16 at 22:23
@hakre I think that's a reasonable assessment, and I agree that it is the most likely scenario. (Thank you for doing the due diligence re: zend_long!) This hearkens back to last part of my original question: is there a historical repository of the `mysql` extension's code-base available? The first commit to the current repository was on 2015-03-04. Obviously, the extension was under development well before then... maybe scrubbing the older source from the record was intentional. Even so, surely, it exists somewhere... — Ben Johnson, Feb 23 '16 at 22:56
Most likely before that date you find it within the PHP core repository as that extension always shipped with PHP. — hakre, Feb 23 '16 at 23:01

score 5 · Accepted Answer · answered Feb 24 '16 at 00:24

5

You are building a PHP 7 extension source with PHP 5.6. You have to fetch 5.6 sources. One way might be to fetch the 5.6 branch from php-src.git or from a source distribution tarball and then run phpize in the ext/mysql directory.

$ git clone -b PHP_5_6 git@git.php.net:/php-src.git php-5.6
$ cd php-5.6/ext/mysql
$ phpize5.6

answered Feb 24 '16 at 00:24

johannes

15,807
3
44
57

1

BAM! That was it! Thank you for "teaching a man to fish", johannes! Here's what I ended-up doing: # git clone --depth=1 -b php-5.6.16 https://https://git.php.net/repository/php-src.git # cd ./php-src/ext/mysql # phpize5.6 # ./configure --with-php-config=/usr/bin/php-config5.6 # make # make install # printf "; configuration for php mysql module\n; priority=20\nextension=mysql.so" > /etc/php/mods-available/mysql.ini # ln -s /etc/php/mods-available/mysql.ini /etc/php/5.6/fpm/conf.d/20-mysql.ini # service php5.6-fpm reload Again, THANK YOU! I deeply appreciate your insight on this one! – Ben Johnson Feb 24 '16 at 03:00

How does one build the mysql extension for PHP 5.6?

UPDATE: Solution

1 Answers1