前回から随分と時間が掛かってしまった。
少し先へと進めたので、一寸だけ書いておく。
色々と悩んで、Google Geminiに相談することにした。
結果、postfixの吐いていたエラーがほぼ出なくなった。
その上、Spamassassinのsa-update絡みのエラー対処方法も教わった。
様々に範囲が広がっているうちに何処をどう直したか忘れてしまった(^_^;;
とりあえず覚えていること。
postfixのmaster.cf
|
1 |
smtps inet n - n - - smtpd |
の最後に-vvを付けてはいけない。
masterが無理してメッセージを出そうとするので、落ちる筈のところが落ちなく、障害の切り分けが見つけにくいらしい。
それから、main.cfに追加（dnsより先に/etc/localhostを参照）する。
|
1 2 |
smtp_host_lookup = native lmtp_host_lookup = native |
他にも話が変わっていきます。
Google Geminiさんは話しやすいので。
訊ねながらやっていたのはupgradeができないportの更新方法。
こちらも覚えていることを書き連ねておきましょう。
|
1 |
sudo port uninstall --follow-dependents py27 |
py27関係をuninstallする。（とっても古いのが残っていた。この為upgradeに片端から失敗していた）
|
1 |
sudo port -f upgrade icu |
結局icuが何なのか判らないままです。
同様に壊れて動かないのを削除（uninstall）したり、upgradeに失敗するのを回避させまくって（最後の手段見たいのがたくさん提案された）、一応port rev-upgradeが空になるようになりました。
後はclung17がlibxx17関係で壊れていたので、次からのコンパイルにはconfigure.compiler=clangを付けることでclang17関係を無視する方法を教えてもらいました。これは有難いけれど、多分次の時には忘れているので、また尋ねることになるでしょう。
後は、mysql8（元々これのコンパイル失敗から始まった）のserverが動けば安心できるかなぁ。
この先は次回にします。
あ、php84-apache2handllerが動かない。
boost176が無いといけないようだ。
まぁport search boost|grep “^boost”したらboost188まであるようだ。
動くならそちらへ移行しよう。
新しい方が良いとは言わないが、古い環境を残したままだと今回みたいに動かなくなる。
Google Geminiさんは下記のように提案してくれます。
|
1 2 3 4 5 |
# 188がダメな場合はこちらを試してください sudo port clean boost176 sudo port install -s boost176 -python311 -python313 configure.compiler=clang build.args=toolset=clang # php84-apache2handler の場合（バージョンに合わせて読み替えてください） sudo port -f upgrade -s php84-apache2handler configure.compiler=clang |
そしてそれでも動かないときは、エラーlogの内容を参照してさらに別の対応方法を教えてくれます。
configure.compiler=clang: リンク切れで動かなくなっている MacPorts 製のコンパイラを無視し、安定している OS 標準のコンパイラを使います。
-python…: エラーログで落ちていた Python 連携部分のビルドをスキップし、成功率を上げます（PHP の動作には影響ありません）。
まずは 手順1（boost188 を標準コンパイラでビルド） を実行してみてください。今度は Abort trap: 6 が出ずにコンパイルが進みますか？
次に進むための確認:
Building boost188 は Abort trap を出さずに 進み始めましたか？
使用されている PHP の正確なバージョン（php84 以外であれば）を教えてください。
有難いことです。
お陰で幾つかのport ccommandを知りました。
|
1 |
sudo port log boost188|grep error|tail -n 20 |
これだと一々
|
1 |
less /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_boost171/boost171/main.log |
なんて書かなくていい。
いやタブで補完掛けているから入力文字数はずっと少ないけれど……それでもboostはdevel内だと知らないと見つけるのが大変です。
_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_が一緒なので、lsで見てもタブで補完しようとしても出てくるリストが長い長い（sigh）
さて、日が変わりGeminiさんに訊ねながらの続きです。
今日はwebが動かない（Database絡み）ので、mi（macのテキスト編集ソフト）で書いています。
こまめに書き残しておこうと思います。
今度はmariadbが無くなってしまった。（port installedで出てこない）
Geminiさんによるとboost絡みらしい。
現在mariadb-10.11-serverのコンパイル中。
と言っても、初っ端からエラーで止まったので個別にコンパイルです。
必要になるboost187、judy、mariadb-10.11の中のjudyで引っかかったので、port -f install -sとsourceからのコンパイル。（-fは要らないらしいGemini氏談）
sudo port -f install -s judy
は通った。（-sはコンパイル済みでなくsourceの展開かららしい）
次はboost187のコンパイル……失敗。
sudo port -f install -s boost187
を
sudo port -f install -s boost187 configure.compiler=clang
とコンパイラを変えて再実行。
それでもダメ。
Geminiさんに教えてもらった
|
1 2 3 4 5 |
sudo port clean boost187 sudo env CC=/usr/bin/clang CXX=/usr/bin/clang++ \ port install -s boost187 -python311 -python313 \ configure.compiler=clang \ build.args=toolset=clang |
を入れて、再度挑戦。
今度はできました。
Geminiさんの言うことには、
何が起きているか
boost187 のビルドの最初期段階（ビルドエンジン b2 自体を作るステップ）で、システムが勝手に g++（MacPorts版のリンク切れコンパイラ）を呼び出そうとして、案の定 Abort trap: 6（ICU 76が見つからない） で自爆しています。
configure.compiler=clang を指定しても、Boostの内蔵スクリプトがそれを無視して g++ を探しに行ってしまう「Boost特有の頑固さ」が原因です。
解決手順：環境変数でコンパイラを力ずくで教え込む
MacPortsの引数だけでなく、シェル変数の CC と CXX を直接指定して、壊れた g++ を絶対に使わせないようにします。
以下のコマンドを試してください：
|
1 2 3 4 5 |
sudo port clean boost187 sudo env CC=/usr/bin/clang CXX=/usr/bin/clang++ \ port install -s boost187 -python311 -python313 \ configure.compiler=clang \ build.args=toolset=clang |
* env CC=… CXX=…: これにより、Boostの bootstrap.sh が g++ を探す前に、OS標準の安定した clang を使うよう強制します。
* -python…: 以前と同様、エラーの火種になりやすい Python 連携を外してビルドを確実に通します。
これで、あの Abort trap: 6 を出さずに Building boost187 が走り出せば、MariaDBの復活まで一気に進めます。
この「env付きコマンド」で、今度はビルドが動き出しましたか？
（もしこれでも Abort trap が出る場合は、まだどこかに古いライブラリの影が潜んでいます）
だそうです。
一時間経って（お昼食べてきた）もmariadbのコンパイルは終わっていませんでした。
86％のところでずっと止まっています。
Geminiさんは、
MariaDB のビルドプロセスにおいて、この sql ディレクトリ（サーバー本体のロジック） はファイル数が非常に多く、かつ一つ一つのファイルのコンパイルが非常に重いため、パーセント表示がなかなか進まない「最大の山場」です。
現在の状況のポイント
コンパイラの動作: 指定通り /usr/bin/clang++ が動いており、Abort trap（リンク切れエラー）も出ていません。
依存関係: boost/1.87 や openssl3 など、昨日から今日にかけて整えたライブラリ群を正しく参照しています。
と説明してくれました。
次に困ったちゃんなのが、mariadbは10.2からのバージョンアップだったので、その儘10.2の環境を利用していたこと。これが今回の再インストール時に10.11に置き換えられてしまったのです。今まで“なあなあ”で済ませていたことが裏目に出た……
logやdbの中のmariadb-10.11ディレクトリを使うよう、mariadb-10.2からコピーして……動きました。
なので、これが書き込めます。
最後に、Geminiさんとの遣り取りを。
僕の
今日はブログ（ここまでの結果）を更新しておしまいにしたいと思います
Geminiさんも登場します
お楽しみに
に対してGeminiさんのお答え
High Sierraという「手強い環境」を、ソースビルド（-s）と根気で見事に攻略された記録は、同じ悩みを持つ他のMacPortsユーザーにとっても、非常に貴重な知恵袋になるはずです。
ブログの更新、頑張ってください！また何か新しい実験や、別のポートで「おや？」と思うことがあれば、いつでもお気軽に話しかけてくださいね。
今日は本当にお疲れ様でした。ブログの公開、楽しみにしています！
【本日のミッション：完全完了】
MacPorts 整合性: 異常なし (rev-upgrade パス)
Webサーバー: 復旧 (PHP 8.4 + MariaDB 10.11)
名前解決: 復旧 (bind9)
それでは、よい夕べをお過ごしください。ブログ更新、いってらっしゃい！
話していて楽しいですね＞Geminiさん