configure: error: libjpeg.(a|so) not found. php 5.2.17

configure: error: libpng.(a|so) not found. php 5.2.17

単にlibjpeg-devel, libpng-develがインストールされていないなら、

yum install libjpeg-devel

yum install libpng-devel

でインストールすればいい。しかし、これはもうやったのに、上記エラーが出る場合、32bit（i386）のライブラリがインストールされていない可能性がある。

# ls -la /usr/lib | grep libjpeg
lrwxrwxrwx   1 root root      17  5月 20 15:58 libjpeg.so -> libjpeg.so.62.0.0
lrwxrwxrwx   1 root root      17  5月 20 15:58 libjpeg.so.62 -> libjpeg.so.62.0.0
-rwxr-xr-x   1 root root  134268  1月  6  2007 libjpeg.so.62.0.0

のように、/usr/lib の中に、ライブラリが入っているか確認するといい。もしかしてなかったりしませんか？　次に６４ビット用ライブラリも確認してみよう。

# ls -la /usr/lib64 | grep libjpeg
lrwxrwxrwx  1 root root      17  5月 20 15:17 libjpeg.so -> libjpeg.so.62.0.0
lrwxrwxrwx  1 root root      17  7月  2  2010 libjpeg.so.62 -> libjpeg.so.62.0.0
-rwxr-xr-x  1 root root  138936  1月  6  2007 libjpeg.so.62.0.0

こちらは有ったりしませんか？
なんだ、６４bitのしかないなら、

./configure –with-libdir=lib64

のように指定すればいいではないか。でもやってみると、今度は、mysql_clientがないとか言われたりする。今度は32ビット版のライブラリしかないものが見つからなくなってしまう。。。困ったもんだ。

もし、yumでインストールしたlibjpegやlibpngのライブラリが６４ビット版はあり、３２ビット版がないという状況の場合、yumでi386のパッケージを除外する設定がされている可能性があります。普通、libjpeg, libpngは、yumインストールすると３２ビット版、６４ビット版の両方がインストールされるはずだからです。以下のように確認してみよう。

# cat /etc/yum.conf

設定の中に、

exclude=*.i386

のような記述があればコメントアウトする必要がある。これでyum install libjpeg-develで、３２ビット版のライブラリもインストールされるはずだ。

/etc/yum.repos.d/

の中にあるファイルに関しても確認してみル必要があるかもしれない。

おそらくopensslの複数バージョンの混在が原因ではないかと思います。RPM版のopenssl0.9.8eが入っており、別途ソースインストールで、/usr/local/openssl にopenssl1.0.0cを入れていました。

MySQL5.5では、コンパイル時にCmakeを使うようになり、設定方法が以前と変わっており、opensslのインストールPREFIXを指定できずに（方法があるのかもしれませんが、、、）、デフォルトのディレクトリ/usr からライブラリを組み込むようで、RPM版のopenssl0.9.8eが組み込まれました。

一方、PHPではopensslのインストールディレクトリを指定できるので、/usr/local/openssl のopenssl1.0.0cを組み込もうとしたところ、MySQL5.5からクライアントライブラリを組み込む指定もしていたので、MySQL5.5のopenssl0.9.8eとPHP5.3のopenssl1.0.0cがコンフリクトして「セグメンテーション違反」となって、コンパイルできなかった。

なので、opensslは複数バージョンのDSOモジュールがあると競合するようだ。仕方なく、PHPには、/usrのパスを指定してopenssl0.9.8eを組み込んだ。

さて、Apache2.2には、opensslのパス指定ができるので、/usr/local/openssl のopenssl1.0.0cを組み込んでいました。このアパッチにlibphp5.soを読み込ませるわけだが、そうするとApache2.2のopenssl1.0.0cと、PHP5.3およびMySQL5.5に組み込まれたopenssl0.9.8eがコンフリクトするのではなかろうか。PHPコンパイル時のPHP x MySQLのコンフリクトのようにエラーが出ればいいが、Apache起動時にエラーも吐かずに立ち上がらないという状況はいかにも困った。

これらのopensslコンフリクトの仮説をもとに、Apache2.2もopenssl0.9.8eを組み込んでコンパイルし直し、PHP5.3も同様にコンパイルしなおしたところ、動きました。。。。

./symfony openpne:install

を実行した際に、

Couldn’t locate driver named mysql

と怒られたなら、それはPHPにpdo_mysqlエクステンションが入っていないから。ソースディレクトリからエクステンションをコンパイルする。

cd /usr/local/src/php/php-5.2.5/ext/pdo_mysql/
phpize
./configure –with-php-config=/usr/local/php5/bin/php-config \
–with-pdo-mysql=/usr/local/mysql5.0
make
make install

でインストールし、php.iniに、

extension=pdo_mysql.so

を加えてApacheリスタート。
起動ＯＫと出て、安心できない。ブラウザでPHPのページをみると閲覧できない。Apacheが起動していない。。。

php -i

で、確認しようとすると、

php: symbol lookup error: /usr/local/php5/lib/php/20060613/pdo_mysql.so:
undefined symbol: php_pdo_declare_long_constant

とでる。これは、/usr/local/php5/include/php/ext/pdo/php_pdo_driver.hのバージョンがよろしくないようだ。PHPをソースインストールした際のソースディレクトリからコピーしてやる。

cp /usr/local/src/php/php-5.2.5/ext/pdo/php_pdo_driver.h \
/usr/local/php5/include/php/ext/pdo/php_pdo_driver.h

いったんpdo_mysqlをアンインストールする。

rm -f /usr/local/php5/lib/php/20060613/pdo_mysql.so

上記、ソースから再度インストール。make cleanしてからね。これでApache再起動でいけました。OpnePNEもインストール完了。

<?php
for ( $i=1; $i<=1000000000; $i++ ) {
$src .= ’1234567890′;
if ( !preg_match( ‘/<(.+?)>/’, ‘<’.$src.’>’, $matches ) ) {
echo “not match at “.$i;
break;
}
}
?>

上記コードでは、決して「not match at ???」とは表示されることはないように思われるだろう。しかし実際はそうではない。実行してしばらく待つと以下の結果が出る。

not match at 10000

(.+?)というサブキャッチパターンにマッチする文字列が、10000×10文字＝10万文字になった時点で、マッチしなくなり、echoして、breakしていることが分かるはずだ。ちなみに、以下のコードでは、どうだろう。

<?php
for ( $i=1; $i<=1000000000; $i++ ) {
$src .= ’1234567890′;
$src2 .= ’1234567890′;
if ( !preg_match( ‘/<(.+?)><(.+?)>/’, ‘<’.$src.’><’.$src2.’>’, $matches ) ) {
echo “not match at “.$i;
break;
}
}
?>

上記の場合、以下のような結果となる。

not match at 5000

おわかりだろう。やはり10万文字だ。(5000×10文字)＋(5000×10文字)＝10万文字なのである。

そんな長い文字をサブキャッチなんかしないといわれるかもしれない。しかし、私がこれに気付いたのは、XML-RPCのリクエストのパースを実装していた時だ。XML-RPCで、データを登録するリクエストにおいて、<base64></base64>タグで、画像データを受け取った際に、preg_matchのサブキャッチパターンで中身を取得したのだ。結果、大きな画像を受け取ったときに、マッチしないという事態に陥ったのだ。

たちが悪いのは、エラーをはいてプログラムが停止するのではなく、単にマッチしなくなって次の処理に進んでしまうことだ。ぜひ、気をつけていただきたい。

Warning: session_start() [function.session-start]: open(/tmp/sess_ｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘｘ, O_RDWR) failed: Permission denied (13) in /virtual/ｘｘｘｘ/public_html/index.php on line xx

これはCGI版では、セッションファイルが、/tmp/にて、FTPユーザー権限で書きこまれ、一方モジュール版ではApacheユーザー権限で書きこまれるからだ。それで、CGI版PHPで作成されたセッションファイルをモジュール版PHPから読み込む際にパーミッションエラーとなるのだ。逆もまたしかり。

Warning: ftp_put() [function.ftp-put]: Ok to send data. in /path/to/script.php on line 99

のようなエラーに出くわすことはないだろうか。この場合、PHPが動作しているマシンのiptablesに注意が必要である。FTPログインはできたものの、相手からデータ通信のコネクションが張れないままタイムアウトしているのであろう。

通信相手のFTPサーバがアクティブモードで動作している場合、こちらから相手FTPサーバの２１番ポートにコネクトしたのち、相手FTPサーバの２０番ポートから、 こちらが通知した1024-65535の間のポートにコネクトしようとしてくる。

なので、こちら（PHPが動作しているマシン）のiptablesのINPUTチェーンで制限を加えている場合、INPUTチェーンでは、 1024-65535の間のポートが空いている必要が出てしまう。
これはあまりにも危険だし、その必要もない。以下のようにする。

iptables -L

を行い、INPUTチェーンに

ACCEPT  all  –  anywhere  anywhere  state RELATED,ESTABLISHED

の行があることを確認する。これは、確立済みのコネクションと、関連するコネクションを許可するものだ。なければ以下のように作る。

iptables -I INPUT 5 -p udp -m state –state ESTABLISHED,RELATED -j ACCEPT

上記、5の部分は挿入するINPUTチェーンの行番号です。

次にiptables関連のカーネルモジュールを確認する。

lsmod

を実行し、ip_conntrack_ftpと、ip_nat_ftpの行があることを確認し、ないものを入れる。それぞれ以下の通り。（多くの場合、ip_conntrack_ftpは入っている。）

modprobe ip_conntrack_ftp
modprobe ip_nat_ftp

これで、アクティブモードのFTPサーバに対して、PHPでFTP通信ができるようになった。

このままではサーバが再起動したら元に戻ってしまう。
/etc/sysconfig/iptables-config
で、使用するモジュールを以下のように設定する。

IPTABLES_MODULES=”ip_nat_ftp”

service iptables save

■実態参照とは

XML文書内で直接記述できない文字や記号（たとえば、 “<” や “>” など）を表記する際に用いられる記述方法です。以下のようなものがある。

• 「&」 ・・・ 「&amp;」
• 「< 」・・・ 「&lt;」
• 「> 」・・・ 「&gt;」
• 「” 」・・・ 「&quot;」
• 「’ 」・・・ 「&apos;」

XML内の、<description>タグ、<content>タグなどの中にHTMLを記述する場合、多くの場合以下のような記述を用いる。

<description>
<![CDATA[
<h1>タイトル</h1>
<p>文章がここにはいる</p>
]]>
</description>

このようにしてCDATAセクションを使うことで、実態参照を用いずに記述することが可能である。しかし、CDATAを使わずに実態参照を用いて記述されているXMLも数多く存在する。

<description>
&lt;h1&gt;タイトル&lt;/h1&gt;
&lt;p&gt;文章がここにはいる&lt;/p&gt;
</description>

このようになる。

■実態参照が使われたXMLをパースする際の問題

こういったXML文書をlibxml2.7.0以降を使ったPHP関数でパースすると、実態参照だけが消失し、以下のような見るに堪えない結果となる。

h1タイトル/h1
p文章がここにはいる/p

さくらインターネットのレンタルサーバでは、各種ミドルウェアのバージョンアップが早く、libxml2.7.2などがすでに導入されており、そのサーバを利用している場合、RSSやXMLから情報収集しているプログラムで不具合が生じることになるだろう。

■対処方法

専用サーバであれば、libxmlのバージョンを2.6.30に落とすなどして対処できるが、そうでない場合には別の対処が必要となるだろう。考えられるひとつの方法は、XML内の実態参照をデコードし、CDATAを使った記述に書き換えた上でパースすることだ。以下にPHPでそれを行うための関数を示す。

function insertCDATA( $xml_str )
{
$target_tags = array( ‘description’, ‘content’, ‘content:encoded’ );
foreach ( $target_tags as $tag ) {
$ent = false;
if ( preg_match_all( ‘/<’.$tag.’[^>]*>(.*?)<\/’.$tag.’>/ims’, $xml_str, $matches ) ) {
if ( is_array( $matches[1] ) && count( $matches[1] ) ) {
foreach ( $matches[1] as $m ) {
if ( !preg_match( ‘/^<!\[CDATA\[/im', $m ) &&
preg_match( '/&gt;|&lt;|&amp;|&quot;|&apos;/ims', $m ) ) {
$ent = true;
break;
}
}
}
if ( !$ent ) { continue; }
$encode = mb_detect_encoding( $xml_str );
$xml_str = preg_replace(
'/(<'.$tag.'[^>]*>)(?!\s*<!\[CDATA\[)(.*)(<\/'.$tag.'>)/Ueims',
'"\\1<![CDATA[".html_entity_decode("\\2",ENT_COMPAT,"$encode")."]]>\\3″‘, $xml_str );
}
}
return $xml_str;
}

この関数にXML文字列を渡すと、<description>タグ、<content>タグ、<content:enceded>タグを調べて、そこに実態参照があれば、CDATAによる記述に書き換えて返してくれます。

RSSをパースする際に、MagpieRSS（http://magpierss.sourceforge.net/）をご利用の方も多いだろう。このライブラリもlibxml2.7.xの影響を受ける。その場合、rss_fetch.incを開き、上記の関数を書き加えたうえで、_response_to_rss関数のはじめの部分を以下のように書き換えてやるといい。

/*===============================================*\
Function:   _response_to_rss
Purpose:    parse an HTTP response object into an RSS object
Input:      an HTTP response object (see Snoopy)
Output:     parsed RSS object (see rss_parse)
\*===============================================*/

function _response_to_rss ($resp) {
/* ++++++++++++++++++++ Simple Eye changed +++++++++++++++++++ */
//    $rss = new MagpieRSS( insertCDATA($resp->results), MAGPIE_OUTPUT_ENCODING, MAGPIE_INPUT_ENCODING, MAGPIE_DETECT_ENCODING );
/* ++++++++++++++++++++ Simple Eye changed +++++++++++++++++++ */
$rss = new MagpieRSS( $resp->results, MAGPIE_OUTPUT_ENCODING, MAGPIE_INPUT_ENCODING, MAGPIE_DETECT_ENCODING );

・・・・・・・・つづく・・・・・・・・・

■■　以下のエラーを検証する　■■

Warning: Unknown(): Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively. in Unknown on line 0

PHP バージョンが 4.2.3 とそれ以前には、たとえ register_globals が無効の場合でもグローバルスコープでセッション変数の初期化を 許してしまうドキュメント化されていない特徴/バグがあります。 この機能を使用している場合で session.bug_compat_warn も有効にしている場合、 PHP 4.3.0 とそれ以降のバージョンでは警告が発されます。 この特徴/バグは、 以下のディレクティブを無効にすることで無効にすることが可能です。

session.bug_compat_42
session.bug_compat_warn

上記の「この機能を使用している場合」に相当しているかどうかを ＰＨＰがどんな条件で判断しているかを６つのケースから考える。

●エラーが出ない[case1.php]

（$_SESSIONのキーとグローバル変数が違う場合）

<?php
session_start();
$bbb = $_GET['abc'];
$_SESSION['aaa'] = $bbb;
?>

●エラーが出ない[case2.php]

（$_SESSIONのキーとグローバル変数が同じ場合でも、外部からの変数を受け取っていない場合）

<?php
session_start();
$aaa = ‘abc’;
$_SESSION['aaa'] = $aaa;
?>

●エラーが出る[case3.php]

（$_SESSIONのキーとグローバル変数が同じ場合で、かつ、外部からの変数を受け取っている場合）

<?php
session_start();
$aaa = $_GET['abc'];
$_SESSION['aaa'] = $aaa;
?>

●エラーが出る[case4.php]

（$_SESSIONのキーとグローバル変数が同じ場合で、その$_SESSIONが外部からグローバル変数とは関係ない外部変数を受け取っている場合）

<?php
session_start();
$aaa = ‘abc’;
$_SESSION['aaa'] = $_GET['abc'];
?>

●エラーが出る[case5.php]

（$_SESSIONのキーとグローバル変数が同じ場合で、その$_SESSIONが外部からグローバル変数とは関係ない外部変数を別のグローバル変数を介して受け取っている場合）

<?php
session_start();
$aaa = ‘abc’;
$bbb = $_GET['abc'];
$_SESSION['aaa'] = $bbb;
?>

●エラーが出ない[case6.php]

（$_SESSIONのキーとグローバル変数が同じものがある場合で、その$_SESSIONとは別の$_SESSIONが外部変数を受け取っている場合）

<?php
session_start();
$aaa = ‘abc’;
$bbb = $_GET['abc'];
$_SESSION['aaa'] = $aaa;
$_SESSION['ccc'] = $bbb;
?>

●結論（エラーが出る条件）

①$_SESSIONのキーと同じ名前のグローバル変数がある

例）　$_SESSION['aaa']　と　$aaa

②その$_SESSIONが間接的、直接的を問わず、何らかの外部変数を読み込んでいる

例１）　$_SESSION['aaa'] = $_GET['abc'];

例２）

$bbb = $_GET['abc'];
$_SESSION['aaa'] = $bbb;

●回避策

php.iniの以下のディレクティブをOffにする

session.bug_compat_42
session.bug_compat_warn

http://dd.cron.ru/dbg/

●ソースコード取得

http://dd.cron.ru/dbg/downloads.php

●インストールマニュアル

http://dd.cron.ru/dbg/installation.php

●準備

①ＰＨＰをインストールしよう。

②PREFIX/bin/にphpizeが作成されていることを確認する。

③ソースdbg-2.11.32-src.tar.gzをダウンロード

④次のプログラムがインストールされていることを確認。

autoconf 2.13　以降

automake 1.4　以降

libtool 1.3.3　以降

●ソース展開

/usr/local/src/dbg/でソースを展開する

tar xzvf dbg-2.11.32-src.tar.gz

●スクリプトdeferphpizeを調整

deferphpizeの初めの方にあるphpizeへのパスを適切なものにする

cd dbg-2.11.32

vi deferphpize

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・

#!/bin/sh

phpize=${phpize:-”/usr/local/php/bin/phpize”}

if test -f $phpize; then

$phpize

else

echo “You have to make and install php first. Make sure phpize script is located at $phpize”

exit 1

fi

・・・

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・

●deferphpizeを走らせる

./deferphpize

これにより、dbg.soライブラリがPHPのモジュールサブディレクトリに作成される。

私の場合は、/usr/local/php/lib/php/extensions/no-debug-non/zts-20050922/dbg.so

に作成された。これを/usr/local/php/lib/php/extensions/dbg.soに移動した。

PHP4の場合、ソースディレクトリの/usr/local/src/dbg/dbg-2.11.32/modules/dbg.so

に作成された。

●エラー対処

In file included from /usr/local/src/dbg/dbg-2.11.32/dbg.c:21:

/usr/local/php4-4apache1.3/include/php/main/php_network.h:78:25: openssl/ssl.h: No such file or directory

In file included from /usr/local/src/dbg/dbg-2.11.32/dbg.c:21:

/usr/local/php4-4apache1.3/include/php/main/php_network.h:129: error: syntax error before “SSL”

/usr/local/php4-4apache1.3/include/php/main/php_network.h:129: warning: no semicolon at end of struct or union

/usr/local/php4-4apache1.3/include/php/main/php_network.h:132: error: syntax error before ‘}’ token

/usr/local/php4-4apache1.3/include/php/main/php_network.h:162: error: syntax error before “SSL_METHOD”

make: *** [dbg.lo] エラー 1

このエラーが出たら、openssl-devel パッケージをインストールする必要がある。

yum install openssl-devel

●php.iniの設定

エクステンションへのパスの指定

extension_dir = “/usr/local/php/lib/php/extensions”

利用するエクステンションの指定

extension=dbg.so

dbgのセクション

[debugger]

debugger.enabled=on

debugger.profiler_enabled=on

●apacheの再起動

apacheを再起動させてphpinfo()を表示させて、ZENDのロゴ付近に以下の記述があり、dbgのセクションがあればインストール成功。

This program makes use of the Zend Scripting Language Engine:

Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

with DBG v2.11.32, (C) 2000,2005, by Dmitri Dmitrienko