OSをSolarisからRed Hat Enterprise Linux Serverへ移行します。このとき、Solaris上C言語で作成したプログラムについて、どのような注意点・修正が必要でしょうか?具体的な移行作業を示して下さい。

【OS情報】
Solaris(SunOS 5.10、CC:Sun C 5.8 2005/10/13、GCC:version 3.4.3、32bit)
Red Hat(Enterprise Linux Server release 5.3、CC:GCCへのリンクまたはsunstudio12.1、GCC:4.1.2.20080704(Red Hat 4.1.2-44)(GNU Make 3.81)、64bit)
【なんとなく分かっていること(これらを掘り下げて回答として頂いてもかまいません)】
1.アーキテクチャが異なるため再コンパイルが必要、その際Makeのオプションを変更
→コンパイル時の注意点は?オプションの変換方法は?
2.エンディアンが異なるため、バイトオーダー指定部分の改修
→例えばどんなコーディングが該当する?
3.CC判定がより厳しくなるため、プログラムの厳密さを向上させる
4.使用ライブラリ名が異なるためインクルードファイルを変更
5.その他、コーディング作法(関数によって宣言方法や引数の数が異なる)の修正
6.32Bitから64Bitへ変わる事への対応
3.4.5.6.→例えば?
7.なるべく工数を少なくするには?ツール(無償)などが存在する?

回答の条件
  • URL必須
  • 1人2回まで
  • 登録:2009/11/25 18:27:54
  • 終了:2009/12/02 18:30:04

回答(2件)

id:dev_zer0 No.1

dev_zer0回答回数332ベストアンサー獲得回数252009/11/25 20:31:32

ポイント35pt

昔、同じようなことをしたことがあるので


> 1.アーキテクチャが異なるため再コンパイルが必要、その際Makeのオプションを変更

> →コンパイル時の注意点は?オプションの変換方法は?

makeのバージョンは同じだったので変えてない


> 2.エンディアンが異なるため、バイトオーダー指定部分の改修

> →例えばどんなコーディングが該当する?

ネットワークへの読み書き、バイナリデータの読み書きを適当にしているコーディング

例えばJPEGからSOIセグメントを取得する場合

short s; /* shortは2byteを仮定 */

fread(&s, sizeof s, 1L, fp);

if (s == 0xFFD8) { /* SOIが来た場合 */ }

とかしていると、Solarisでは思ったとおり動きますが、

Linux(インテルのCPU)だと思ったとおりには動きません。


> 3.CC判定がより厳しくなるため、プログラムの厳密さを向上させる

出現した警告を片っ端から潰していく

# 予めどれぐらいの警告が出てくるのか取りあえずコンパイルしてみた方がいい


> 4.使用ライブラリ名が異なるためインクルードファイルを変更

> 5.その他、コーディング作法(関数によって宣言方法や引数の数が異なる)の修正

大昔のソース(bzeroとかを使っているようなK&R以前の代物)とかなければ問題ないと思う

しかし、シグナルやGUIが絡んでくると各OSごとに挙動が変わるので厄介です

http://www.fenix.ne.jp/~G-HAL/comp/sig.txt


> 6.32Bitから64Bitへ変わる事への対応

最低でも2038年問題を発生させないように

time_tを使うべきところでintを使ってしまっている箇所は修正する


> 7.なるべく工数を少なくするには?ツール(無償)などが存在する?

autotoolに対応していれば無問題なんだけど、多分対応させていないでしょ?

id:mattn No.2

mattn回答回数104ベストアンサー獲得回数232009/11/25 23:08:30

ポイント35pt

http://www.hatena.ne.jp/

1.アーキテクチャが異なるため再コンパイルが必要、その際Makeのオプションを変更

→コンパイル時の注意点は?オプションの変換方法は?

プログラム本体はそれ程、影響出ないかもしれません。主にバイナリやネットワークストリームを生で扱う場合に影響します。

2.エンディアンが異なるため、バイトオーダー指定部分の改修

→例えばどんなコーディングが該当する?

shortであればhtons/ntohs、longであればhtonl/ntohlを使用して変換します。

もしくは自前でビットシフトする事で実現出来ますが、せっかくマルチプラットフォームに出来るチャンスなので前者が望ましいかと思います。

3.CC判定がより厳しくなるため、プログラムの厳密さを向上させる

一度どれくらいエラーが出るか

# make -k > build.log

で確かめて見ると良いです。

4.使用ライブラリ名が異なるためインクルードファイルを変更

これをやる際、出来れば#ifdefを使って以前までの処理を残しておくと良いです。

あまりに差分が激しい様であれば、OS毎にソースを分けた方が良い場合もあります。

5.その他、コーディング作法(関数によって宣言方法や引数の数が異なる)の修正

最近はK&Rな宣言するソースも少ないので、gccを使っているのであればそれ程影響する事はないと思います。

6.32Bitから64Bitへ変わる事への対応

上記で述べた様にバイナリやネットワークストリームを扱わないのであれば、問題ないかと思いますが、依存していたライブラリが64Bitに移行する事で、呼出側の変数型の変更を強制される場合もあります。

7.なるべく工数を少なくするには?ツール(無償)などが存在する?

やはりautotoolsです。

ただしautotoolsが解決してくれるのではなく、実際にはautotoolsを使ってOSやアーキテクチャを切り分け易くなるだけですので、工数は下がるどころが上がる可能性もあります。

32bit/64bit、また複数のOSをサポートしたフリーソフトウェアのソースコードを眺めるのが一番良いかと思います。

  • id:smileless
    HPがマイグレーションプログラムを開催しているようですが、参加する暇がありません・・・
    http://h50146.www5.hp.com/products/servers/integrity/campaign/solaris/seminar.html
  • id:smileless
    http://mediajam.info/topic/971203
    レッドハットと日本IBMがSolarisユーザーにサーバ移行プログラムを提供しているようですね。
    無償で利用はできないか・・・

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません