![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
・学研の「科学」/「学習」が休刊
することになったそうな。
小学館の「小学5/6年生」も休刊するそうなので、少子化の流れには逆らえないといったところだろうけど、 毎月、学研のおばちゃんが届けてくれる「科学」をワクワクしながら待っていた世代からすると、ずいぶん寂しいところがあるな。
今から思えば、文字通り子供だましだっただろうけど、酸とアルカリの実験セットとか、日光写真の実験セットとかを宝物のように思っていたっけ。
最近だとゲームボーイとかの学習ソフトの方がマルチメディア的で受けるんだろうけど、ソフトウェアではなく実際のモノをイジる意味というのはあると思うんだけどなぁ。
個人的には、スパコンに予算を付けるよりも、こっちを支援する方が将来の科学技術立国に有効な気がしないでもない。
・libuuid
最近のPlamoでは、libuuidがe2fsprogs由来の libuuid.so.1 系と OSSP uuid 由来の libuuid.so.16 の2種があって気にはなっているのだけど、 どうも Ｌｉｎｕｘ用のソフトウェアの多くは e2fsprogs 由来で uuid_generate() を持つ libuuid.so.1 系を期待しているらしい。 ただ、configure スクリプトとかで libuuid の存在のみをチェックしている場合、 それが e2fsprogs 由来か OSSP uuid 由来かまではチェックしていないことがあり、 リンク時に uuid_generate() が無い、などというエラーになる場合もある模様（libSM-1.1.1 とか）
気になったので少し追いかけてみたところ、OSSP uuid では /usr/include/uuid.h というヘッダーファイルを用意して、その中では
/* workaround conflicts with system headers */ #define uuid_t __vendor_uuid_t #define uuid_create __vendor_uuid_create #define uuid_compare __vendor_uuid_compare #include <sys/types.h> #include <unistd.h> #undef uuid_t #undef uuid_create #undef uuid_compare
みたいな定義をして、uuid_t の定義はシステム提供のインクルードファイルに任せようとしているようだけど、実のところ通常の Linux 環境のインクルードファイルには uuid_t を定義している部分がないので、/usr/include/uuid.h をインクルードするだけでは uuid_t の定義が定まらない感じ。
一方、e2fsprogs 由来の libuuid では /usr/include/uuid/uuid.h というヘッダファイルを用意して、その中では
#include <sys/types.h> #ifndef _WIN32 #include <sys/time.h> #endif #include <time.h> typedef unsigned char uuid_t[16];
のような形で uuid_t を明示的に定義している。
OSSP uuid でも configure 時に --with-dce を指定して DCE(Desktop Common Environment だっけ？） 1.1 との互換機能を有効にしてやると、 /usr/include/uuid_dce.ht というヘッダファイルを作って、そこでは
/* DCE 1.1 uuid_t type */
typedef struct {
#if 0
/* stricter but unportable version */
uuid_uint32_t time_low;
uuid_uint16_t time_mid;
uuid_uint16_t time_hi_and_version;
uuid_uint8_t clock_seq_hi_and_reserved;
uuid_uint8_t clock_seq_low;
uuid_uint8_t node[6];
#else
/* sufficient and portable version */
unsigned char data[16];
#endif
} uuid_t;
typedef uuid_t *uuid_p_t;
みたいな定義をしているので、どうも OSSP uuid は、デフォルトでは DCE 1.1 以降の環境を想定して、 システム側に uuid_t の定義があるものと考えているけど、標準の Linux 環境ではシステム側に uuid_t の定義は無いので、 うまく噛みあってない感じ。
手元でビルドしているパッケージはたいてい e2fsprogs 由来の libuuid を期待しているようなので、OSSP uuid はそれを必要とする パッケージに組み合わせるか、static link してしまうくらいの方がいいのかも知れない。
