当前位置：文江博客话题详情

简单的共享库

发布于 2024-09-28 19:29:16 字数 153 浏览 3 评论 0原文

STD 库是共享库还是什么？出于好奇。
有没有详细介绍共享静态库开发的书籍？
有教程吗？

ps（我正在使用 netbeans 、 eclipse 、 anjuta ）并且教程没有用，因为我试图了解实际发生的情况。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

白日梦 2024-10-05 19:29:17

在我的平台（Ubuntu Maverick）上是：

g++ test.cpp
ldd a.out

linux-vdso.so.1 =>  (0x00007fffee1ff000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f18755fd000)
libm.so.6 => /lib/libm.so.6 (0x00007f187537a000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f1875163000)
libc.so.6 => /lib/libc.so.6 (0x00007f1874de0000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1875920000)

注意上面的 libstdc++.so.6。

使用 cmake 创建共享库非常容易。

1.
安装 cmake 2.6 或更高版本。

2.
使用您的库的代码创建文件 test.cpp。

3.
创建文件 CMakeLists.txt：

cmake_minimum_required(VERSION 2.6)
project(TEST)
add_library(test SHARED test.cpp)

4。
运行 cmake 创建 makefile：

cmake -G "Unix Makefiles"

5.
运行 make 来构建您的共享库。

通过 CMake，您还可以使用以下命令生成 Eclipse CDT 项目

cmake -G "Eclipse CDT4 - Unix Makefiles"

您还可以找到一篇关于该主题的有趣文章以及更多参考

On my platform (Ubuntu Maverick) it is:

g++ test.cpp
ldd a.out

linux-vdso.so.1 =>  (0x00007fffee1ff000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f18755fd000)
libm.so.6 => /lib/libm.so.6 (0x00007f187537a000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f1875163000)
libc.so.6 => /lib/libc.so.6 (0x00007f1874de0000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1875920000)

Note libstdc++.so.6 above.

With cmake creating a shared library is very easy.

1.
Install cmake 2.6 or later.

2.
Create a file test.cpp with the code for your library.

3.
Create a file CMakeLists.txt:

cmake_minimum_required(VERSION 2.6)
project(TEST)
add_library(test SHARED test.cpp)

4.
Run cmake to create a makefile:

cmake -G "Unix Makefiles"

5.
Run make to build your shared library.

With CMake you can also generate an Eclipse CDT project using the following command

cmake -G "Eclipse CDT4 - Unix Makefiles"

You can also find an interesting article on the topic with further references here.

回复收藏 0 原文

游魂 2024-10-05 19:29:17

1.) STD 库是共享库还是什么？

我不知道。可能是两者之一。可能两者都有。有关系吗？除非您正在处理一些非常奇特的东西，例如用于系统重建的独立静态链接二进制文件，否则只要编译器/系统知道如何链接它，您就不太可能关心它。

简而言之，代码可以位于静态库中，在这种情况下，它会链接到最终（编译/生成）的可执行文件中，并且这些二进制文件可能会变得非常大。或者它可以位于共享库中，在这种情况下，该库是动态加载的，并且多个应用程序可以（理论上）共享一个公共内存映像。除非您正在做一些非常大的事情，并且将在多个应用程序之间共享，否则我会质疑使用共享库是否明智。额外的麻烦，尤其是调试麻烦，是不值得的。如果没有多个同时运行的应用程序，就没有节省...

为了制作静态库，我会将一堆文件编译成目标文件...而不是使用 ar和randlib。例如：

g++ -c foo1.C -o foo1.o
g++ -c foo2.C -o foo2.o
ar -rv libfoo.a foo1.o foo2.o
ranlib libfoo.a

随后，我只需将该库链接到：

g++ testfoo.C -o testfoo -L. -lfoo

请注意，如果您使用多个库，则 -lbar1 -lbar2 的顺序 (g++ testfoo.C) 命令行很重要！它确定哪些库可以调用其他库中的函数/方法。循环依赖不好！

对于 foo1.o foo2.o 文件到 ar，顺序没有区别。

动态库...

前段时间，在一个古老的fedora core 3系统下，我在玩linux下的共享库。当时，我会编译我的共享库，例如 fooLibrary.c，其中：

g++ -shared -Wl,-soname,libfooLibrary.so.1 -o libfooLibrary.so.1.0 -fPIC fooLibrary.c -ldl

当时我正在使用 LD_PRELOAD，所以我有一个小脚本来运行我的程序确实如此：（

export LD_PRELOAD=libfooLibrary.so ; export LD_LIBRARY_PATH=. ; ./myTestProgram

请注意，我不希望在运行g++、ls、等命令时设置LD_PRELOAD >cd 等，因为我正在拦截系统调用。）

（仅供参考：strace 玩起来也很有趣......您还应该查看strace >ldd 和 nm。）

您可能需要查看诸如 dlopen() 和 dlsym() - 用于手动访问动态库...

哦，还有环境变量 LD_LIBRARY_PATH 将目录添加到动态库的默认搜索路径中...

（关于调试，让我提一下，当我拦截malloc()时，我发现内部某处dlopen()/dlsym() 是对 malloc() 的调用。这意味着我需要先使用malloc()，然后才能手动加载提供真正malloc()的库。调试那个很有趣……）

PS 还有一个想法：您可能想查看 gcc/g++ 的命令行选项。那里有很多有用的信息...

http://gcc.gnu.org/onlinedocs/gcc-4.5.1/gcc/index.html#toc_Invoking-GCC

1.) Is the STD library a shared library or what is it?

I have no idea. Could be either. Probably both. Does it matter? Unless you are dealing with something really exotic like a stand-alone statically linked binary for system rebuilding, as long as the compiler/system knows how to link it in, you are unlikely to be concerned with it.

In a nutshell, code can be in static libraries, in which case it's linked into the final (compiled/generated) executable and those binaries can become quite large. Or it can be in a shared library, in which case the library is dynamically loaded and multiple applications can (theoretically) share one common memory image. Unless you are doing something that is quite large, and that will be shared across multiple applications, I'd question the wisdom of going with shared libraries. The additional headaches, especially debugging headaches, are rarely worth it. And without multiple concurrently running applications, there's no savings...

To make a static library, I'd compile a bunch of files into object files... Than use ar and randlib. E.g.:

g++ -c foo1.C -o foo1.o
g++ -c foo2.C -o foo2.o
ar -rv libfoo.a foo1.o foo2.o
ranlib libfoo.a

Subsequently, I'd just link that library in:

g++ testfoo.C -o testfoo -L. -lfoo

Note that if you are using multiple libraries, the ordering of -lbar1 -lbar2 on that (g++ testfoo.C) command line is important! It determines which libraries can call functions/methods in other libraries. Circular dependencies are BAD!

With respect to foo1.o foo2.o files to ar, the ordering makes no difference.

Dynamic libraries...

Some time ago, under an ancient fedora core 3 system, I was playing around with shared libraries under linux. Back then, I would compile my shared library, say fooLibrary.c, with:

g++ -shared -Wl,-soname,libfooLibrary.so.1 -o libfooLibrary.so.1.0 -fPIC fooLibrary.c -ldl

At that time I was playing with LD_PRELOAD, so I had a little script to run my program that did:

export LD_PRELOAD=libfooLibrary.so ; export LD_LIBRARY_PATH=. ; ./myTestProgram

(Note that I did NOT want LD_PRELOAD set when running commands like g++, ls, cd, etc as I was intercepting system calls.)

(FYI: strace is also fun to play with... You should also check out ldd and nm.)

You may want to look at things like dlopen() and dlsym() -- for manually accessing dynamic libraries...

Oh, and the environment variable LD_LIBRARY_PATH adds directories to the default searchpath for dynamic libraries...

(With respect to debugging, let me just mention that when I intercepted malloc(), I found that somewhere inside dlopen()/dlsym() were calls to malloc(). Meaning that I needed to use malloc() before I could manually load the library that provided the real malloc(). Fun times debugging that one...)

PS One more thought: You may want to review the command-line options to gcc/g++. There's a lot of useful info in there...

http://gcc.gnu.org/onlinedocs/gcc-4.5.1/gcc/index.html#toc_Invoking-GCC

回复收藏 0 原文

~没有更多了~