|
>>3562 瀧上 > たとえばログイン時に「.cshrc」から「環境変数設定ファイル」を > Sourceしたとして、この時「環境変数設定ファイル」から設定した > 環境変数は、サーバDOWNかそれを書き換えるまで確実に保証される > のでしょうか？ setenv で更新したら変更されます。.cshrc を更新しても、 明示的に source したり、ログインしなおさないと反映 されません。 よって、プログラムの先頭で source するか、cron であれば * * * * * . /home/hoge/env.sh && /home/hoge/bin/foo としておくのがよいでしょう (JP1 でも何かしら環境変数を 指定するような設定があるのではないかと想像します)。 > LIBがmakeInstall時に取り込まれるものだとしたら、 そういう意図ではなく、実行時に必要ないろいろなファイルの 置き場所、として書きました。 もし動的ライブラリを使うなら lib/ に置くことになる でしょうね。 でなくて、静的にリンクするなら、ライブラリは src/ の 下だけ置いて、アプリのmake install 時にリンクしmasu. ライブラリ自体は lib/ に make install しません (実行時 には必要ないので)。 で、それはそれとして > 動的なライブラリはUNIXにおける開発ではあまり使用しない > ものなのですしょうか？ についてですが、わたしの場合は静的にリンクする方法を 好みますが、別に動的リンクがダメと言うほどではないです。 業務系では多少のメモリ使用量の多寡ははどうでもよいので、 構成管理のやりやすさだけを考慮すれば構わないと考えます。 で、例えば、 1. ライブラリ関数 func をプログラム A・B・C が使用している。 2. プログラム A に不具合が発生。すぐに修正版をリリース しなければならない。 3. 原因は func であることが判明。しかし func の呼び出し方の 違いから、プログラム B・C ではこの現象は発生しない。 という状況を考えます。 静的にリンクしている場合、もし人的リソースに余裕があり、 func 修正時にプログラム A・B・C のテストをすることができる なら、修正版 func のリリース時にプログラム A・B・C を再 コンパイルすることができます (これが最も望ましい)。 しかし、プログラム B・C をテストする余裕がない場合、 func を修正して再コンパイルし、プログラム A を再コンパイル とすることで、プログラム B・C に影響を与えず func を修正 するという選択肢をとることができます。 ただしこれは プログラム A が使用している func と、プログラム B・C が使用している func が異なる という管理しづらい状況になるため、次期リリース時に全てを 再コンパイルするまでの時間かせぎです。 つまり、静的リンクの場合、 目の前のリスクを少なくしたいなら → プログラム A のみを再コンパイル 構成を単純にしたいなら → プログラム A・B・C を再コンパイル と、状況に応じた選択が可能です。 しかし動的ライブラリだと、動的ライブラリを入れ替えて、 プログラム B・C に不具合が出るかもしれないリスクを負う という選択肢しかありません。 よって、わたしは静的にリンクする方を選びます。 ただし静的リンクの場合、再コンパイル忘れなどで各プログラムが 使用しているライブラリのバージョンが異なる、という状況が発生 する可能性がありますが、この対策として、定期リリース時に商用 環境の - 全ソース・全プログラムを削除 - 最新版のソースを全て再コンパイル - 全プログラムを make install とすれば OK でしょう (最上位ディレクトリで make && make install すれば全アプリ入れ替え完了)。 # 仮に動的リンクを選択したとしても、上記の「定期リリース # ごとに全部インストールしなおす」というやり方は強く # おすすめしておきます。 |