NetBSD/macppc (8.0) で pkgsrc/www/apache24 が作れない問題 の続き。
gccについて
gccのドキュメントにこの関数の解説がある。
ちなみに、gcc-4.6 までは ‘‘Built-in functions for atomic memory access’’ という見出しだが、gcc-4.7 からは ‘‘Legacy __sync built-in functions for atomic memory access’’ となり、新しい __atomic 系の解説が続くようになっている。（この節の変更は、誤りや細かい表現の修正のみ。）
いずれのバージョンにしても、こんな記述がある。
Not all operations are supported by all target processors. If a particular operation cannot be implemented on the target processor, a warning is generated and a call to an external function is generated. The external function carries the same name as the built-in version, with an additional suffix ‘_n’ where n is the size of the data type.
雑に訳すと：
すべてのオペレーションがすべてのターゲットプロセッサでサポートされているわけではない。
そのターゲットプロセッサで特定のオペレーションをインプリメントできない場合は、警告が生成され、外部関数の呼出しが生成される。
その外部関数はビルトイン版と同じ名前をもち、追加の接尾辞 ‘_n’（nはデータ型のサイズ）が付く。
よって、
32ビットのmacppcやi386は、64ビットのオペレーションに対応していない。
対応していないので、__sync_fetch_and_add_8 のように _8 のついた外部関数の呼出しが生成される。
……というのは、ほぼ仕様通りと言える。（ただし、この時点で警告は出ていない気がする。）
ただ、その外部関数が用意されていないのがダメなだけで……。
前述の通り既にLegacy扱いなので、今更修正はしてくれないでしょう。
aprについて
apr の configure では、この __sync 系関数があるかどうかをテストしている。なければ使わないので問題は起きない。しかし、32ビットというか unsigned long でのテストプログラムしかなくて、これが通れば 64ビットのもの (builtins64.c) も動く前提になっているのがダメ。
ちゃんと直すなら、32ビットと64ビットを別にテストして、builtins.c/mutex.c と builtins64.c/mutex64.c を使い分けるようにすべきでしょうか。手を抜くなら64ビットだけテストするのでも良いかも。
macppcだと問題が出て、i386だと問題が出ないのは、configure の中の
case $host_cpu in
i[456]86) force_generic_atomics=yes ;;
*) force_generic_atomics=noのあたりで回避できてるから。ズルい（？）。
apache (httpd) について
apr_atomic系の64ビット版は特に使ってない気がする。
以上。