Tetsuo Handa
from-****@I-lov*****
2010年 4月 6日 (火) 21:08:05 JST
熊猫です。 > こちらのほうは、 ncurses を準備するのが困難な環境向けに ccs-editpolicy-agent を > 用意したけれども、 ccs-loadpolicy や ccs-savepolicy などは ncurses を準備するのが > 困難な環境であっても使いたいので、 ncurses に依存したマルチコールバイナリという状態を > 解消して必要なプログラムだけを選べるようにするつもりです。ライブラリ化の要望が > 出ているため、共有ライブラリを使う形で作成する手順について勉強し、６月下旬の > http://www.apc.ehdo.go.jp/seminar/course/10semi22294.html までに > CAT760 （ http://tomoyo.sourceforge.jp/incoming/cat760.avi ）でも使えるような > 状態にしたいと考えています。 ということで、マルチコールバイナリ状態を解消し、 ncurses に依存する ccs-editpolicy と ccs-queryd 以外は ncurses ライブラリとリンクさせない形に 変更してみました。また、共有ライブリとして /usr/lib/ccstools.so.1 を利用し、 個々のプログラムのサイズの増加を抑えられるようにしました。 http://sourceforge.jp/projects/tomoyo/svn/view/trunk/1.7.x/ccs-tools/ccstools/?root=tomoyo どのように使われる共有ライブラリにするかが未定なので、どの処理をライブラリに 含めるかで迷っています。ということで、（特に宍道さんに）質問です。 どのように共有ライブラリを使おうと考えていますか？ （１）ccstools パッケージに含まれていない別のアプリケーション（例えばＧＵＩ プログラム）から /usr/lib/ccstools.so.1 をリンクしたいと考えていますか？ それとも、 ccstools パッケージ（に含まれている /usr/sbin/ccs-\* ）から だけしかリンクされないと考えていますか？ （２）（１）が前者の場合、 /usr/lib/ccstools.so.1 のソースは ccs-tools パッケージとは分離したほうが都合が良いですか？ （３）（１）が前者の場合、別のアプリケーションから呼び出せるようにするために /usr/lib/ccstools.so.1 には ccstools パッケージ内では１個のプログラム からしか呼ばれない関数であっても詰め込んだ方が良いですか？ （４）（１）が前者の場合、別のアプリケーションから呼び出せるようにするために /usr/lib/ccstools.so.1 内の関数は static 関数として宣言しないように する方が良いですか？ Revision 3580 では（１）が後者で、 ccs-tools のリリース毎にバイナリ互換性が 無くなる（必要に応じて ccstools.so.2 ccstools.so.3 ・・・と増えていく）ことを 問題視しない方針で、 ccstools パッケージ内で１回しか呼ばれていない処理は ライブラリには含めない（個々のプログラムに直接埋め込む）ようにし、 ccstools パッケージのプログラムが直接呼び出さない変数や関数は static 変数／関数として 宣言するという仕様になっています。
TOMOYO
Fork