共享库和.h文件 [英] Shared libraries and .h files

问题描述

我对如何使用程序共享库的一些疑问。

I have some doubt about how do programs use shared library.

当我建立一个共享库（与-shared -fPIC开关）使我从一个外部程序的某些功能。
通常我做的dlopen（）来加载库，然后对dlsym（），以上述的功能链接到一些函数指针。
这种方法不涉及包括任何.h文件中。
有没有一种方法（）及避免做的dlopen;对dlsym（），只是包括共享库的.H？

When I build a shared library ( with -shared -fPIC switches) I make some functions available from an external program. Usually I do a dlopen() to load the library and then dlsym() to link the said functions to some function pointers. This approach does not involve including any .h file. Is there a way to avoid doing dlopen() & dlsym() and just including the .h of the shared library?

我的猜的，这可能是C ++程序如何使用存储在系统中的共享库code。即只包括文件stdlib.h等。

I guess this may be how c++ programs uses code stored in system shared library. ie just including stdlib.h etc.

推荐答案

尼克，我认为所有的其他的答案实际上是回答你的问题，这是你如何链接库，但是你的方式那句你的问题建议你有个误区的标头文件和库之间的差异。它们是不相同的。你需要的两个的，而且他们没有做同样的事情。

Nick, I think all the other answers are actually answering your question, which is how you link libraries, but the way you phrase your question suggests you have a misunderstanding of the difference between headers files and libraries. They are not the same. You need both, and they are not doing the same thing.

建立一个可执行文件有两个主要阶段，编译（这将您的源成一种中间形式，包含可执行二进制指令，而不是一个可运行的程序），以及联（结合这些中间文件合并为一个正在运行的可执行文件或库）。

Building an executable has two main phases, compilation (which turns your source into an intermediate form, containing executable binary instructions, but is not a runnable program), and linking (which combines these intermediate files into a single running executable or library).

当你做 GCC -c program.c ，你是编译和生成 program.o 。这一步是在那里的标题的事情。您需要的#include＆LT;＆stdlib.h中GT; 在 program.c 来（例如）使用的malloc 和免费。 （同样需要的#include＆LT; dlfcn.h中＆GT; 为的dlopen 和则dlsym ）。如果你不这样做，编译器会抱怨它不知道这些名称，并以一个错误终止。但是，如果你的#include 标题中的编译器的不的插入code你打电话到功能program.o 。它只是插入的参考的给他们。究其原因是为了避免code重复：在code仅将需要通过你的程序的每一个部分一次访问，所以如果你需要进一步的文件（ module1.c ， module2.c 等），即使它们的所有的使用的malloc 你只会一起的malloc 的一个副本，多次提到结束。这单拷贝是在标准present的库的无论是它的共享或静态的形式（ libc.so 或文件libc.a ），但这些都没有在源引用，编译器不知道他们。

When you do gcc -c program.c, you are compiling, and you generate program.o. This step is where headers matter. You need to #include <stdlib.h> in program.c to (for example) use malloc and free. (Similarly you need #include <dlfcn.h> for dlopen and dlsym.) If you don't do that the compiler will complain that it doesn't know what those names are, and halt with an error. But if you do #include the header the compiler does not insert the code for the function you call into program.o. It merely inserts a reference to them. The reason is to avoid duplication of code: The code is only going to need to be accessed once by every part of your program, so if you needed further files (module1.c, module2.c and so on), even if they all used malloc you would merely end up with many references to a single copy of malloc. That single copy is present in the standard library in either it's shared or static form (libc.so or libc.a) but these are not referenced in your source, and the compiler is not aware of them.

链接器的是的。在链接阶段你做 GCC -o程序program.o 。然后，链接器将搜索你通过它的命令行上的所有库，找到的单的你打过电话未在自己的code定义的所有函数的定义。这正是 -l <​​/ code>做（因为其他人解释）：告诉链接你需要使用库列表。他们的名字往往很少做与你在previous步骤所用的标题。例如，要获得使用则dlsym 你需要 libdl.so 或 libdl.a ，让您的命令行应为 GCC -o程序program.o -ldl 。要使用的malloc 或大部分功能在性病的* .h 头需要的libc ，而是因为库使用的每个的C程序是的自动的链接（因为如果你做了 -lc ）。

The linker is. In the linking phase you do gcc -o program program.o. The linker will then search all libraries you pass it on the command line and find the single definition of all functions you've called which are not defined in your own code. That is what the -l does (as the others have explained): tell the linker the list of libraries you need to use. Their names often have little to do with the headers you used in the previous step. For example to get use of dlsym you need libdl.so or libdl.a, so your command-line would be gcc -o program program.o -ldl. To use malloc or most of the functions in the std*.h headers you need libc, but because that library is used by every C program it is automatically linked (as if you had done -lc).

很抱歉，如果我进入了很多细节，但如果你不知道其中的差别，你会想要。这是很难做的，如果你没有C语言编译如何工作的感觉。

Sorry if I'm going into a lot of detail but if you don't know the difference you will want to. It's very hard to make sense of how C compilation works if you don't.

最后一件事：的dlopen 和则dlsym 不连接的正常方式。它们用于要动态地确定要基于是，不管什么原因，只在运行时可用信息的行为有什么特殊情况。如果你知道你要调用在编译时（真在99％的情况），则不需要使用 DL * 功能什么功能。

One last thing: dlopen and dlsym are not the normal method of linking. They are used for special cases where you want to dynamically determine what behavior you want based on information that is, for whatever reason, only available at runtime. If you know what functions you want to call at compile time (true in 99% of the cases) you do not need to use the dl* functions.

这篇关于共享库和.h文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！