人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

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

●質問者: smileless
●カテゴリ:コンピュータ インターネット
✍キーワード:CC C言語 Enterprise gcc GNU
○ 状態 :終了
└ 回答数 : 2/2件

▽最新の回答へ

1 ● dev_zer0
●35ポイント

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


> 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に対応していれば無問題なんだけど、多分対応させていないでしょ?


2 ● mattn
●35ポイント

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をサポートしたフリーソフトウェアのソースコードを眺めるのが一番良いかと思います。

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ