目次
この投稿では、g ++を使用してダイナミックライブラリを生成するプロセスについて説明します。最終的に、C ++ライブラリ関数と同じように、ダイナミックライブラリをリンクすることで、自分で作成した関数を呼び出すことができます。function.c合計function.hファイルをに配置する必要はなくなりました。プロジェクトディレクトリ。
1.ダイナミックライブラリファイルlibxxx.soを生成します
1.ダイナミックライブラリの利点
私は2つのファイルを持っていると仮定しますfunction.hとfunction.c、これはある宣言や定義関数目的球の。
ダイナミックライブラリが生成されていない場合、別のファイルでmain.c関数を呼び出したいときはfunction()、function.h合計function.cをmain.c同じパスにコピーする必要があります。私は10件のプロジェクト内の関数を使用している場合は、私が持っているfunction()し、コピーfunction.hしてfunction.cいないだけで面倒である10回をコピーするだけでなく、メモリの無駄。
ダイナミックライブラリがある場合は、関数を呼び出すたびにfunction()、g ++でコンパイルするmain.cときに-lfunctionオプションを追加するだけで済みます。つまり、関数ライブラリにリンクする必要があります。このように、プロジェクトがいくつあっても、必要なダイナミックライブラリは1つだけです。
2.ダイナミックライブラリファイルlibxxx.soを生成します
function.hおよびを含むfunction.cディレクトリで、Linuxターミナルを開き、次のコマンドを実行します。
g++ function.c -I ./ -fPIC -shared -o libfunction.so
このコマンドの説明は次のとおりです。
- function.cは、操作するターゲットソースファイルです
- そのため
function.c、g ++でコンパイル#include "function.h"するときにファイルの場所を指定する必要があります。ではG ++を使用して、コマンド、識別するためのオプションここでは、我々の立場をし、-Iコマンド./ **で、同じパスに、現在の場所のパスを表し./**。function.h-I.h文件function.hfunction.c - -fPICは、位置に依存しないコードが生成されることを意味します（理論を含む、Baiduを自分でお願いします）
- -sharedは、このコマンドの目的がダイナミックライブラリを生成することであることを示します
- -oは出力ファイルの名前を指定するために使用され、-olibfunction.soはファイル名が生成されることを意味します
libfunction.so
生成されたダイナミックリンクライブラリがlibfunction.soという名前であるのはなぜですか？固定フォーマットですか？
それは確かに固定フォーマットです。
Linuxシステムのダイナミックリンクライブラリには、libxxx.soという名前を付ける必要があります。ここで、xxxは人間によって定義され、通常はライブラリ名です。
このように、g ++ライブラリg++ main.c -lxxxとリンクすると、リンクに使用できます。その中で、main.cは、関数ライブラリxxxを呼び出すためのソースファイルであり-lxxx、xxxライブラリにリンクすることを意味します。
2.ダイナミックライブラリファイルlibxxx.soをシステムディレクトリに移動します
①
ためには、G ++見つけるlibxxx.so、我々はしなければならない移動libxxx.so指定されたシステムディレクトリに。** g ++ **は、デフォルトで実行時にライブラリファイルを検索するために自動的にこのディレクトリに移動します。
次のコマンドを実行します。
sudo cp libxxx.so /lib/x86_64-linux-gnu/
このようにlibxxx.soして、ディレクトリに移動すると/lib/x86_64-linux-gnu/、g ++はデフォルトで/lib/x86_64-linux-gnu/ディレクトリ内のライブラリファイルを自動的に検索します。
②
またfunction.h、指定された場所に設置する必要があります。
次のコマンドを実行します。
sudo mkdir /usr/include/function
sudo cp function.h /usr/include/function
このように、それfunction.hを入れてください/usr/include/function。このディレクトリは、ヘッダーファイルを自動的に見つけるg ++のデフォルトディレクトリでもあります。同時に、ライブラリのほとんどのヘッダーファイルは/usr/include/このディレクトリに保存されます。
この時点で、作業は終了です。プログラムmain.cの関数関数の後に使用する場合、main.cをコンパイルするときだけg++ main.c -lfunction、コマンドを実行できます。それがなくてもfunction.h、function.c移動できます。
今日、Ubuntuフォーラムにアクセスしているときに、他の人の質問に答えるときの規範について話している2006年の投稿に答える知恵を見ました。現在の投稿やブログとは対照的に、そのような規範や考え方で書くことができる人はほとんどいません。私は前任者の才能、知恵、謙虚な態度にため息をつく必要があり、将来的にはこの基準を使用して私の執筆と学習を標準化します。
1. Don't answer questions to which you don't know the answer(不回答自己不知道答案的问题)
2. Explain yourself (解释给自己)
如果自己是提问者，你的回答是否能让自己明白?
3. Give as little assistance as necessary (尽可能的给最少的帮助)
有的时候启发性的回答更为有效.
4. Show your workings (展示你的做法)
5. Use humour judiciously (明智地使用幽默)
有的时候因为不同语境/语言的问题，你的俏皮话可能会让提问者更加困惑。
6. If you can't say something nice don't say anything atall(如果你不能说出有用的内容，就别说)
7. Avoid jargon, baffling acronyms and idiolects(避免行话、令人困惑的缩写词、习惯用语)
8. Never never never just respond with RTFM. Not ever.(永远永远永远不要回复RTFM)
这里的 RTFM 代表"Read The Fucking Manual", "去读该死的手册".
另外一个常见的是: STFW --Search The Fucking Web,
"搜索该死的网络"，或者友好一点的 "Google 一下".
对于中文论坛上，我觉得还有一个尽量不要说 "RPWT" --人品问题
9. Meditate on eternity (永远的深思熟虑)
回答的问题，可能在不久以后会被别人搜索到，看到，甚至是被你将来的老板看到。一
个欠缺思索的回答无疑会降低你在其他技术人员心目中的形象。
10. Keep your newbie mind (保持自己的"新手"思维)
学无止境
保持谦卑。回答并不意味着你是"给予", 可能你也在学习.
不要认为回答了一些问题自己就成了 Guru 了.
---
把问题先交给google，然后再交给你的朋友。。。