基本的に落書き帳／メモ帳／備忘録なので、 わりと間違っていたり、 数分後とか後日とかに見たら、 いきなり消えていたり書き換わっていたりとかあります。
undefined reference to `__gxx_personality_v0'とかエラーが出る。 何かと思ったら、C++ な物を gcc でリンクしようとしていたオチ。 リンク時に -lstdc++ 付けるか、g++ でリンクすれば問題無し。
none /proc/bus/usb usbfs listgid=37,busgid=37,devgid=37,devmode=0664 0 0と書けば、root:operator で -rw-rw-r-- になるらしい……、 がしかし、root:operator は FreeBSD な uid:gid なので、 GNU/Linux だとうまくない。
const int fd1 = open( "/dev/ugen0", O_RDWR ); const int fd2 = open( "/dev/ugen0", O_RDWR );とかやると （/dev/ugen0 は、USBデバイスの活線挿入で生えてくるデバイス）、 ２回目の open() は EBUSY のエラーになる。 でも GNU/Linux で
const int fd1 = open( "/proc/bus/usb/001/002", O_RDWR ); const int fd2 = open( "/proc/bus/usb/001/002", O_RDWR );とかやると （/proc/bus/usb/001/002 は、USBデバイスの活線挿入で生えてくるデバイス）、 ２回目の open() もエラーにならずに成功してしまう。 うーん、どうなんだろう。
ifeq ($(OSTYPE),linux) EXTRA_LIBS = -lrt else EXTRA_LIBS = endifこんな感じ。
error: format string arg not a string typeエラーで蹴られる、何でだろう？。
AC_DEFUN([AC_LANG_WERROR_FUNC],
[m4_define([AC_LANG_WERROR_FUNC_INCLUDED])dnl
ac_lang_werror()
{
case $[]1 in
on) eval ac_c_werror_flag=yes ac_cxx_werror_flag=yes ;;
off) eval ac_c_werror_flag= ac_cxx_werror_flag= ;;
esac
}])dnl
AC_DEFUN([AC_LANG_WERROR],
[m4_ifndef([AC_LANG_WERROR_FUNC_INCLUDED],
[m4_divert_text([DEFAULTS], [AC_LANG_WERROR_FUNC])])dnl
m4_if(
$#, 1, [m4_if(
[$1], [on], [ac_lang_werror on],
[$1], [off], [ac_lang_werror off],
[m4_fatal([$0: wrong argument])])],
$#, 0, [AC_LANG_WERROR([on])],
[m4_fatal([$0: incorrect number of arguments: $#])])[]dnl
])dnl
AC_DEFUN([CHECK___ATTRIBUTE__], [
AC_CACHE_CHECK([for __attribute__ $1], [ax_cv___attribute__$1],
[
AC_LANG_WERROR([on])
AC_COMPILE_IFELSE(
[AC_LANG_PROGRAM(
[[#include
static void foo(void) __attribute__ (($1));
static void
foo(void) {
exit(1);
}
]], [[foo();]])],
[ax_cv___attribute__$1=yes],
[ax_cv___attribute__$1=no]
)
AC_LANG_WERROR([off])
])
if test "$ax_cv___attribute__$1" = "yes"; then
AC_DEFINE(AS_TR_CPP(HAVE___ATTRIBUTE__$1), 1, [define if your compiler has __attribute__ $1])
m4_ifval([$2],[$2])dnl
m4_ifval([$3],[else
$3
])dnl
fi
])
AC_DEFUN([CHECK___ATTRIBUTE__UNUSED_ARG], [
AC_CACHE_CHECK([for __attribute__ unused at argment of functions], [ax_cv___attribute__u
nused_arg],
[
AC_LANG_WERROR([on])
AC_COMPILE_IFELSE(
[AC_LANG_PROGRAM(
[[#include
static void
foo( __attribute__ ((__unused__)) int dummy ) {
exit(dummy);
}
]], [[foo(1);]])],
[ax_cv___attribute__unused_arg=yes],
[ax_cv___attribute__unused_arg=no]
)
AC_LANG_WERROR([off])
])
if test "$ax_cv___attribute__unused_arg" = "yes"; then
AC_DEFINE(AS_TR_CPP(HAVE___ATTRIBUTE__UNUSED_ARG), 1, [define if your compiler has __attribute__ unused at argment of functions])
m4_ifval([$1],[$1])dnl
m4_ifval([$2],[else
$2
])dnl
fi
])
AC_DEFUN([CHECK___ATTRIBUTE__DEPRECATED], [
AC_CACHE_CHECK([for __attribute__ deprecated], [ax_cv___attribute__deprecated],
[
AC_LANG_WERROR([on])
AC_COMPILE_IFELSE(
[AC_LANG_PROGRAM(
[[#include
static void foo(void) __attribute__ ((deprecated)) __attribute__ ((unused));
static void
foo(void) {
exit(1);
}
]], [])],
[ax_cv___attribute__deprecated=yes],
[ax_cv___attribute__deprecated=no]
)
AC_LANG_WERROR([off])
])
if test "$ax_cv___attribute__deprecated" = "yes"; then
AC_DEFINE([HAVE___ATTRIBUTE__DEPRECATED], 1, [define if your compiler has __attribute__ deprecated])
m4_ifval([$1],[$1])dnl
m4_ifval([$2],[else
$2
])dnl
fi
])
if test x$ax_cv___attribute__ = xyes; then
CHECK___ATTRIBUTE__(constructor,,[AC_DEFINE([__constructor__],,[no __constructor__])])
CHECK___ATTRIBUTE__(destructor,,[AC_DEFINE([__destructor__],,[no __destructor__])])
CHECK___ATTRIBUTE__(noinline,,[AC_DEFINE([__noinline__],,[no __noinline__])])
CHECK___ATTRIBUTE__(noreturn,,[AC_DEFINE([__noreturn__],,[no __noreturn__])])
CHECK___ATTRIBUTE__(unused)
CHECK___ATTRIBUTE__UNUSED_ARG
CHECK___ATTRIBUTE__DEPRECATED
CHECK___ATTRIBUTE__(bounded,,[AC_DEFINE([__bounded__(a,b,c)],,[no __bounded__])])
fi
こんな感じかなぁ？。
AC_LANG_WERROR しているので、ウォーニングは全部潰しておかないといけない。
なので、 __attribute__((__deprecated__)) 以外は、
ダミーの呼び出しをかけている。
__attribute__((__deprecated__)) は呼び出しをかけてしまうと駄目なので、
__attribute__((__unused__)) を付けている……、
でも __unused__ が使えなかったりするとこけるのだよね。
Error: Incompatible types: got "SYSTEM.Word" expected "SYSTEM.Word"とか出る。 同じにしか見えないのですが……。
undefined reference to `atexit'とか出た……、 ライブラリが FedoraCore4系 BSD/Linux 2.4.2 の物と Vine 3.2 GNU/Linux 2.4.xx の物が 混じっていただけだった。
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1の３パターンだけだった。途中で切れているし。 翌月は
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1) Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7に増えていた。
volatile bool condition;
bool Function( 省略 )
{
（省略）
condition = false;
while (!condition)
;
（省略）
}
別スレッドで condition に true を代入。
だった。
通常の SCHED_OTHER だと、
while(); でも強制切り替えが入るけれど、
SCHED_FIFO だと強制切り替えが入らないので。
condition = false;
timespec tmp_ts = { 0, 1*1000000L };
while (!condition) {
nanosleep( &tmp_ts, NULL );
}
こんなんでいいのかな。
そもそも pthread_condwait() 使えって話が。
FreeBSD/amd64 の場合。 % env MALLOC_OPTIONS=jz ./malloc_conf_test malloc() 直後 0x511050: 00 00 - 00 00 ここで、確保した領域を 0x31 で埋める free() 直後 0x511050: 31 31 - 31 31 new 直後 0x511050: 31 31 - 31 31 ここで、確保した領域を 0x32 で埋める delete 直後 0x511050: 32 32 - 32 32 new[] 直後 0x511050: 32 32 - 32 32 ここで、確保した領域を 0x33 で埋める delete[] 直後 0x511050: 33 33 - 33 33 % env MALLOC_OPTIONS=JZ ./malloc_conf_test malloc(): 0x511050: 00 00 - 00 00 free(): 0x511050: D0 D0 - D0 D0 new: 0x511050: 00 00 - 00 00 delete: 0x511050: D0 D0 - D0 D0 new[]: 0x511050: 00 00 - 00 00 delete[]: 0x511050: D0 D0 - D0 D0 % env MALLOC_OPTIONS=Jz ./malloc_conf_test malloc(): 0x511050: D0 D0 - D0 D0 free(): 0x511050: D0 D0 - D0 D0 new: 0x511050: D0 D0 - D0 D0 delete: 0x511050: D0 D0 - D0 D0 new[]: 0x511050: D0 D0 - D0 D0 delete[]: 0x511050: D0 D0 - D0 D0 ちゃんと効いています。 割り当てるメモリは、再利用しまくりです。
OpenBSD/i386 の場合。 % env MALLOC_OPTIONS=jz ./malloc_test malloc(): 0x83787010: 00 00 - 00 00 free(): 0x83787010: 31 31 - 31 31 new: 0x83787020: 00 00 - 00 00 delete: 0x83787020: 32 32 - 32 32 new[]: 0x83787030: 00 00 - 00 00 delete[]: 0x83787030: 33 33 - 33 33 % env MALLOC_OPTIONS=jZ ./malloc_test malloc(): 0x87722010: 00 00 - 00 00 free(): 0x87722010: 31 31 - 31 31 new: 0x87722020: 00 00 - 00 00 delete: 0x87722020: 32 32 - 32 32 new[]: 0x87722030: 00 00 - 00 00 delete[]: 0x87722030: 33 33 - 33 33 % env MALLOC_OPTIONS=Jz ./malloc_test malloc(): 0x89dde010: D0 D0 - D0 D0 free(): 0x89dde010: 31 31 - 31 31 new: 0x89dde020: D0 D0 - D0 D0 delete: 0x89dde020: 32 32 - 32 32 new[]: 0x89dde030: D0 D0 - D0 D0 delete[]: 0x89dde030: 33 33 - 33 33 % env MALLOC_OPTIONS=JZ ./malloc_test malloc(): 0x7f792010: 00 00 - 00 00 free(): 0x7f792010: 31 31 - 31 31 new: 0x7f792020: 00 00 - 00 00 delete: 0x7f792020: 32 32 - 32 32 new[]: 0x7f792030: 00 00 - 00 00 delete[]: 0x7f792030: 33 33 - 33 33 Z を付けようが付けまいが、ゼロクリアされている様に見えます。 man malloc(3) に書いてある通り、解放時の消去は行われません。 /etc/malloc.conf で G が付いていたので、割り当てられるアドレスは変化しまくりです。
Debian GNU/Linux な glibc-2.3.2 の場合。 % ./malloc_test malloc(): 0x804a050: 00 00 - 00 00 free(): 0x804a050: 00 00 - 31 31 new: 0x804a050: 00 00 - 31 31 delete: 0x804a050: 00 00 - 32 32 new[]: 0x804a050: 00 00 - 32 32 delete[]: 0x804a050: 00 00 - 33 33 % env MALLOC_CHECK_=3 ./malloc_test malloc: using debugging hooks malloc(): 0x804a050: 00 00 - 00 00 free(): 0x804a050: 00 00 - 31 31 new: 0x804a050: 00 00 - 31 31 delete: 0x804a050: 00 00 - 32 32 new[]: 0x804a050: 00 00 - 32 32 delete[]: 0x804a050: 00 00 - 33 33 ……謎な挙動だ。 解放時に先頭８バイトが消えているが、これは、前後の未使用領域への相対ポインタ、らしい。 デバッガで si してみた要約。 0x40186ed3 in malloc () from /lib/libc.so.6 0x40185790 in malloc_hook_ini () from /lib/libc.so.6 0x40184da0 in ptmalloc_init () from /lib/libc.so.6 0x40184cb0 in ptmalloc_init_minimal () from /lib/libc.so.6 0x401e6da0 in getpagesize () from /lib/libc.so.6 0x401f9ea0 in __register_atfork () from /lib/libc.so.6 0x4012b90c in ?? () from /lib/libc.so.6 0x40187c80 in _int_malloc () from /lib/libc.so.6 0x40188480 in malloc_consolidate () from /lib/libc.so.6 0x40184780 in malloc_init_state () from /lib/libc.so.6 0x40187fed in _int_malloc () from /lib/libc.so.6 0x401867e0 in sYSMALLOc () from /lib/libc.so.6 0x401893f0 in __default_morecore () from /lib/libc.so.6 0x401e6560 in sbrk () from /lib/libc.so.6 0x401e6510 in brk () from /lib/libc.so.6 0x40187060 in free () from /lib/libc.so.6 0x40188260 in _int_free () from /lib/libc.so.6 0x400bdb70 in operator new () from /usr/lib/libstdc++.so.6 0x40186ea0 in malloc () from /lib/libc.so.6 0x40187c80 in _int_malloc () from /lib/libc.so.6 0x400bc660 in operator delete () from /usr/lib/libstdc++.so.6 0x40187060 in free () from /lib/libc.so.6 0x40188260 in _int_free () from /lib/libc.so.6 0x400bdcc0 in operator new[] () from /usr/lib/libstdc++.so.6 0x400bdb70 in operator new () from /usr/lib/libstdc++.so.6 0x40186ea0 in malloc () from /lib/libc.so.6 0x40187c80 in _int_malloc () from /lib/libc.so.6 0x400bc6c0 in operator delete[] () from /usr/lib/libstdc++.so.6 0x400bc660 in operator delete () from /usr/lib/libstdc++.so.6 0x40187060 in free () from /lib/libc.so.6 0x40188260 in _int_free () from /lib/libc.so.6 libc の _int_malloc() と _int_free() をいじってやれば、BSD系な J とか Z が実装できるかな……、 mmap した場合の free() は _int_free() に来ない構造だった。 MALLOC_TRACE だと、brk()系の時は処理されないので駄目。 確保時は malloc.c:_int_malloc() でいいらしい。 解放時は menusage.c:munmap() と malloc.c:_int_free() の２つらしい。 ……。 malloc.c から #include<arena.c> かよ。 ……。 strace してみたら、 そもそも free()/delete/delete[] しない行儀の悪いプログラムだと、_int_free()/munmap() が呼ばれていなかった。 駄目じゃん。
本家値段 ＄1＝￥110換算 再販版定価 量販店Ｙ 量販店Ｂ 量販店Ｔ 量販店Ｄ Rubik's Mini Cube ２×２ ＄6.99- ￥769- ￥1,260- ￥880-(10%) ￥880-(10%) ￥999- なし Rubik's Classic Cube ３×３ ＄11.99- ￥1,319- ￥2,079- ￥1,660-(10%) ￥1,450-(13%) ￥1,299- ￥1,480- Rubik's Revenge Cube ４×４ ＄20.99- ￥2,309- ￥2,940- ￥2,050-(10%) ￥2,050-(10%) ￥2,299- ￥2,480- Rubik's Professor Cube ５×５ ＄30.99- ￥3,409- ￥3,675- ￥2,680-(10%) ￥2,570-(10%) ￥2,999- なし Rubik's Magic Puzzle ４×２ 販売終了？ 販売終了？ ￥2,079- ￥1,660-(10%) ￥1,450-(10%) ￥1,799- なし Rubik's Magic Puzzle ６×２ ＄9.99- ￥1,099- なし なし なし なし なし 送料は不明。全く関係無い別の海外直販の時は千円くらいだった。 ４×２の日本名は「リンク ザ リング」らしい。 ６×２の日本名は「アンリンク ザ リングス」で通称は「マスターマジック」らしい。あれ、日本再販版って、４×２だけなんですが。 ６×２は再販無し？。 ……。 web で検索してみたら、４×２を二個一にして自作している人達がいる……、 がしかし、実物をいじった事が無いので、 あの説明だと糸の掛け方がよく判らない……。 日本版で三個二にすると１つ約￥2,500-が２つできあがり、 通販だと送料千円の仮定で１つ約￥2,100-で ２つだと１つあたり約￥1,600-、 ……。 実際送料っていくらなのよ？。
% sudo apt-get build-dep libc6 % mkdir ~/build/libc6 % cd ~/build/libc6 % apt-get source libc6 % cd glibc-2.3.2.ds1 % dpkg-buildpackage -us -uc -b -rfakeroot -nclog-test-i386-libc で timezone/tst-timezone と posix/annexc が、 log-test-i486-nptl で timezone/tst-timezone と posix/annexc と nptl/tst-cancel17 と nptl/tst-clock2 と nptl/tst-cancelx17 が、 log-test-i686-linux-i686 で iconvdata/bug-iconv3 と timezone/tst-timezone と posix/annexc と rt/tst-clock_nanosleep が、 エラー出ている。よくわからん。
debian/ build-tree/ build-tree/glibc-2.3.2 build-tree/i386-i686 build-tree/i386-libc build-tree/i386-nptl stamp-dir/ふと気づくと、 glibc-doc, libc6-dbg, libc6-dev, libc6-i686, libc6-pic, libc6-prof, libc6-udeb, libc6, libnss-dns-udeb, libnss-files-udeb, locales, nscd と、片っ端から作られていた……。 dpatch-edit-patch hogehoge してみた。 作業ディレクトリ全部消しやがった……。
根拠の無い当てずっぽうのイタズラなので信用しない様に。
３次曲線補間による、内挿と外挿。
確定値 新規口座開設を４万／月と仮定して
パターン 既開設者数のみを見た場合
その１ その２ その３ その４ その１ その２
開始時 0 0万 0万 0万 0万 0万 0万 2007年７月23日
１ヵ月 30万 30万 30万 30万 30万 26万 26万 2007年８月１日
２ヶ月 50万 50万 50万 50万 50万 42万 42万 2007年10月３日
半年 ? 85万 80万 80万 85万 55万 55万
10ヶ月 100万 100万 100万 100万 100万 60万 60万 2008年６月５日
１年 ? 105万 110万 110万 105万 65万
１年半 ? 110万 145万 130万 120万 65万 70万
２年 ? 110万 180万 150万 130万 70万 80万
最近５年の口座開設数は３〜５万／月。
「その１」よりも最終到達値が小さい場合、「解約」が発生してしまう。
「その２」よりも最終到達値が大きい場合、今後の発行ペースが今よりも大きくなってしまう。
「その４」あたりが、それっぽい曲線になる。
すなわち、口座開設者の（半分しか申し込まない｜半分もが申し込む）勘定になる。
……、残りの半分は、敢えて申し込まないか、休眠口座か。
面倒だから／よく判らないから／要らないから、申し込まないと言う人は
それなりにいるだろうけれども、残り半分の全部がそうとは……。
ただまぁ、マネーカード発行開始後は、16歳以上の新規口座開設は強制でマネーカードになるらしいけれど。
新規口座開設を４万／月と仮定した場合、2007年７月下旬の既開設口座は 210〜220万口座くらい？（IRの開示情報を探せば、もっと正確な値が判るが、こんなバカネタで調べるのも面倒）。
申し込みをした人の数の半分くらいの数の人が、敢えて申し込まないと仮定しても、半数が休眠口座と言う勘定に。
休眠口座が半数と仮定すると、
決済件数：2310万件／３ヶ月 → 一人１ヵ月当たり：5.8件、
預金残高：7602億円 → 一人当たり：57万2千円、
投信残高：408億円 → 一人当たり：3万円、
最頻値よりも圧倒的に多くしている少数の人が、平均を引き上げているのだろうか？。それとも妥当な数値なのだろうか？。
根拠の無い当てずっぽうのイタズラなので信用しない様に。
2006/03/15 サービス開始 2006/07/14〜2006/08/31 入会1000ポイント 2006/07/14〜2006/10/01 入会1000ポイント延長 2006/11/23〜2007/01/08 入会1000ポイント 2007/08/01〜2007/10/31 ポイント2.0倍 2007/12/01〜2008/01/31 抽選（5000ポイント100人、1000ポイント330人） 2008/03/20〜2008/05/31 ポイント1.5倍 2008/11/14〜2008/12/31 キャンペーン店舗でオートチャージ付き申込にてビックカメラ500円割引券（5,000円以上買物時限定、有効期限2009/1/31） 抽選キャンペーンは省略採算ラインぶんの固定客の収集は完了した、 と言う事かな？。
http://x.x.x.x:631/EPSON_IPP_Printer EPSON_IPP_Printerらしい。
FontPath /usr/local/share/ghostscript/8.62/libを追加したら、日本語でも印刷できるようになった。 ……、これ、 GhostScript のバージョンが変わる毎に修正しないと駄目だよなぁ、 不便……。
bge0: <Broadcom BCM5750 A1, ASIC rev. 0x4001> mem 0xfe8f0000-0xfe8fffff irq 16 at device 0.0 on pci2 miibus0: <MII bus> on bge0 brgphy0: <BCM5750 10/100/1000baseTX PHY> on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:18:8b:**:**:**
fxp0: <Intel Pro/100 VM Network Connection> port 0x2000-0x203f mem 0xf0101000-0xf0101fff irq 20 at device 8.0 on pci3 fxp0: MII without any PHY! device_attach: fxp0 attach returned 6とか出て NIC を認識せず、nfs_root のマウントに失敗して止まる。 FreeBSD/amd64 GENERIC でも FreeBSD/i386 GENERIC でも変わらず。 FreeBSD の起動メニューから "disable ACPI" を選んでも駄目。 ノートＰＣだから、ちゃんと認識する NIC に交換する事もできない。
Intel(R) PRO/1000 Network Driver - version 7.3.15-k2 Copyright (c) 1999-2006 Intel Corporation. e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI e100: Copyright(c) 1999-2006 Intel Corporation PCI: Setting latency timer of device 0000:03:08.0 to 64 e100: eth0: e100_probe: addr 0xf0101000, irq 20, MAC addr 00:0D:5E:**:**:**…… MAC の 0:D:5E って、NEC らしいのだが……。
set hint.fxp.0.prefer_iomap="1"してみたら、ちゃんと NIC を認識して、 NFS_root をマウントして起動するようになった。 pxeboot の仮想ルート下の /boot/loader.conf で
hint.fxp.0.prefer_iomap="1"追加すれば、全自動で起動できると思う （当分、再度の利用予定が無いので、試す気無し）。
${HOME}/.sylpheed-2.0/trust.crt
が、
ユーザ個別のサーバ証明書データベースらしい。
取り敢えず新規登録したければ、
そのファイルに追加したいサーバの証明書を追加してやれば良いみたい。
閲覧とか詳細表示とかは、
openssl コマンドでごにょごにょすればいいっぽい。
Error: Couldn't find 'UniJIS-UCS2-HW-H' CMap file for 'Adobe-Japan1' collection Error: Unknown CMap 'UniJIS-UCS2-HW-H' for character collection 'Adobe-Japan1' Error: Unknown font tag 'C2_0' Error (****): No font in showとか出て、UCS-2 で記述された PDF だけ表示されない。 ${HOME}/.xpdfrc の cMapDir と toUnicodeDir で指定したディレクトリが 存在していなかった。 どうやら、先日、ghostscript-gnu から ghostscript-gpl に上げた時に、 ディレクトリ構成が変わったらしい。
cMapDir Adobe-Japan1 /usr/local/share/ghostscript/8.62/Resource/CMap toUnicodeDir /usr/local/share/ghostscript/8.62/Resource/CMapと書いたら、UCS-2 な PDF も表示できる様になった。 cMapDir と toUnicodeDir は、ディレクトリを再帰的には見てくれないらしい。 ghostscript のバージョンを上げるとディレクトリ名が変わってしまう辺り、 嫌な感じ。
cMapDir Adobe-Japan1 /usr/local/share/fonts/adobe-cmaps/aj16/CMap toUnicodeDir /usr/local/share/fonts/adobe-cmaps/aj16/CMapでいけた。 Adobe 純正の CMap でないと、何か足らないらしい。