2017-12-27 49 views
-1

私は最終的にオープンソースになるCスタティックライブラリを開発中ですので、WindowsとUbuntuでクロスコンパイルして移植性の問題を回避します。NetBeansを使用しているLinuxスタティックライブラリのシンボルがありません

私が抱えている問題は、オブジェクトファイルの1つのシンボルがLinuxビルドから省略されていることです。 Windows上でVS2015を使用してライブラリを構築すると、すべてのシンボルが表示されます。

私はほとんどWindows用の開発に慣れていますので、ほとんどのビルドシナリオではIDEを使用することに甘んじています。 UbuntuではNetBeansを使用していますが、問題がgccを理解しているかどうか、またはNetBeansが正しく設定されていないかどうかはわかりません。

詳細

Ubuntuの16.04LTS使用GCC(Ubuntuの)5.4.0

のNetBeans IDE 8.1のC/C++

ライブラリは3つのソースファイルと2つのヘッダファイルで構成されています

queue.c --> queue implementation 
memutil.c --> memory utilities 
mylib.c --> main library implementation 

queue.h --> included by queue.c and mylib.c 
mylib.h --> header file for the static library 

mylib.hヘッダーには、のヘッダー情報が含まれています3210ソースファイル。コマンドラインのMEMCHECKシンボルに依存する条件でラップされています。ソースファイルのmemutil.cのコードと同様です。 MEMCHECKシンボルはライブラリをビルドするときに定義されますが、Linuxビルド後にlibmylib.anmを実行すると、memutil.oオブジェクトファイルのシンボルは表示されません。 Windowsでmylib.libファイルを見ると、memutil.objのすべてのシンボルが表示されます。

mylib.hヘッダーだけを含むスタブアウトソースファイルを追加すると、すべてのシンボルがlibmylib.aライブラリに存在します。私はヘッダファイルの相互作用の機能不全のいくつかの並べ替えがあると推測しているが、私はそれが何であるか、またはそれを修正する方法を見つけるために見ていない。私は、私が考えることができるように多くの異なる言葉遣いでGoogleからこれを鼻をついたが、喜びはない。ヘッダファイルのインクルードにスタブ

gcc -c -g -Wall -DMEMCHECK -MMD -MP -MF "build/queue.o.d" -o build/queue.o queue.c 
gcc -c -g -Wall -DMEMCHECK -MMD -MP -MF "build/memutil.o.d" -o build/memutil.o memutil.c 
gcc -c -g -Wall -DMEMCHECK -MMD -MP -MF "build/mylib.o.d" -o build/mylib.o mylib.c 

ar -rv dist/Debug/GNU-Linux/libmylib.a build/queue.o build/memutil.o build/mylib.o 
ar: creating dist/Debug/GNU-Linux/libmylib.a 
a - build/queue.o 
a - build/memutil.o 
a - build/mylib.o 
ranlib dist/Debug/GNU-Linux/libmylib.a 

BUILD SUCCESSFUL (total time: 3s) 

このために修正することはできません、それは次のことができます。ここでは

は、NetBeansは、出力を構築するディレクトリノイズのすべての少ないですか?それは動作しますが、それは非常に原油のようです。さらに、gccで必要でありVS2015では必要ではないとは本当に信じられません。

+1

少し毛深いことがありますが、 '-E'オプションでコンパイルすることを検討することもできます。これは、プリプロセッサが実行された後のソースコードを表示するので、 '-DMEMCHECK'があなたがしなければならないと思っていることをしているかどうかを知ることができるはずです。あなたのコードは、 '#include'の後ろに終わりに向かっています。出力をファイルにリダイレクトすることもできます。 'gcc -E code.c> ppCode.c' https://stackoverflow.com/questions/3742822/preprocessor-output – yano

+0

は' -Wextra'フラグを付けてコンパイルすることをお勧めしますより多くの警告。 – yano

+0

@yano:条件付きで問題が発生した場合、Windowsビルドもうまくいくと思います。 –

答えて

0

まあ、私は解決策を見つけましたが、私は正確にはわからないので、これを受け入れられた答えとしてマークしていません。なぜ解決策です。

私は、コンパイラの行に-Mxxフラグに気づい:

gcc -c -g -Wall -DMEMCHECK -MMD -MP -MF "build/... 

だから私はGoogleに行き、このサイトが見つかりました:Auto-Dependency Generation、ビルドの依存関係の生成と追跡をMake扱う持つカバーしています。

その後、私は、私はこの1つ見つけるまでNetBeansで一つ一つのメニュー項目を通じてコーミング開始:

ツール - >オプション - > C/C++ - 生成されたmakefile

に依存性チェックを有効にし、[オン/オフ]>を

私はそのスイッチをクリアし、欠けているシンボルがすべてライブラリに表示されました。ただし、-Mxxフラグは、ビルド出力のコンパイラ行にまだ表示されていました。現在、NetBeansのmakefile生成では、ビルドの設定とターゲットに基づいて、ビルド時にmakefileを生成するために、約5つの別々のmakefileテンプレートと3つまたは4つの異なるXML設定ファイルが使用されます。私は、自動依存フラグがそのスイッチを反転させることによって不活性にされたかどうかを知ることができませんでした。

しかし、私は正しく、上記のウェブサイト上の情報を読んでいる場合は、それらの-Mxxフラグが実際にMakeの支援でGCCが使用するので、私は、彼らが何かに基づいて異なる解釈を持っているだろうかわからないんだけどさNetBeansはそうしました。それらのmakefileテンプレートにはたくさんの置換がありますが、私がAutoconfig/Makeウィザードではないので、私は単にそれを逃したかもしれません。

明らかに、実際には、ライブラリユーティリティの関数プロトタイプが含まれていないため、ライブラリヘッダファイルには含まれていません(クライアントのインクルードファイルコード) - NetBeans依存性チェッカーは、これらの関数がライブラリ内で必要ないと判断しました。

関連する問題