我编写了一个用户空间应用程序，其中C使用插件库与低级 Linux 内核驱动程序进行交互plugin.so。我使用打开 DLL dlopen()。我有一个信号处理程序，在收到信号dlclose()时SIGINT调用。dlclose()代码审查后，我收到了不能从信号处理程序调用的反馈注释。如果是，为什么会这样？
我们一直在将 Java 和 .NET API 库转换为 C++，并试图找出将编译版本分发给其他开发人员以与他们的自定义应用程序一起使用的最佳方法。应该是静态库还是动态库？
我们需要为 Win32 和 Win64 创建（我想每个目标操作系统都有调试版本和发布版本）。考虑到我在尝试确保所有引用的库都匹配（/MT 与 /MD）时遇到的所有挫败感，我想知道是否需要在这里做出一个决定来简化其他开发人员的工作。
当我dumpbin /all <static library file name> | find /i "msvc在静态库上运行时，我看不到任何运行时引用（与在 .exe 或 .dll 上执行相同操作时不同）。这是否表明运行时尚未链接，并且这使开发人员在开发和构建自己的应用程序时可以更灵活地创建 /MT 或 /MD？
哪种方法可以让开发人员的生活更轻松？
我在 Ubuntu Eclipse 上遇到此错误，该错误不会消失：
Invoking: GCC C++ Linker
g++ -L/usr/lib/i386-linux-gnu -o "GLUT" ./src/GLUT.o -lglut -lGLU
/usr/bin/ld: ./src/GLUT.o: undefined reference to symbol 'glEnable'
//usr/lib/i386-linux-gnu/mesa/libGL.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
我搜索了过剩：
# find / -name *glut.so*
/usr/lib/i386-linux-gnu/libglut.so.3
/usr/lib/i386-linux-gnu/libglut.so.3.9.0
/usr/lib/i386-linux-gnu/libglut.so
然后我转到：项目属性> C/C++ 构建> 设置 GCC C++ 链接器> 库：
// added
Libraries (-l): glut GLU
Library search path (-L): /usr/lib/i386-linux-gnu
错误还是一样。关于我应该错过哪一步有什么建议吗？非常欢迎所有评论。
我有一个 .so 库，我想用另一个长度更长的字符串替换其中硬编码的字符串。是否可以？
lib.c 包含：
#include <stdio.h>
void testFunction()
{
printf("This is the testFunction from lib.so");
}
我用这个命令编译文件：
g++ -fPIC -shared lib.c -o lib.so
在 lib.so 上运行 nm 后，我发现 testFunction 变成了 _Z12testFunctionv。为什么？我认为在使用 dlsym 加载函数时这是一个大问题。
根据 Davis Kings 在该问题中的回答：Create a Shared Library for dlib，我为 Dlib 创建了共享库，并将它们链接到一个使用 Dlib 面部检测来检测相机图片中的面部的程序，使用以下命令：
cd dlib-19.0/dlib
mkdir build
cd build
cmake ..
make
sudo make install
还有-ldlib选项。
我可以编译并执行该程序，但是面部检测速度非常慢。
我在 Windows 上使用 Visual Studio 2013 尝试了相同的程序。当我使用调试模式时，面部检测也非常慢，但在发布模式下运行得很好。所以我想，共享库也可能处于调试模式，并尝试使用以下命令强制它们处于发布模式：
cd examples
mkdir build
cd build
cmake ..
cmake --build . --config Release
sudo make install
但结果却和之前一样。
有谁有一个想法，原因可能是什么，它这么慢？
感谢您的帮助。
我有一个基本的 makefile 来编译编译共享库所需的 C 文件，我有一个错误，因为 makefile 无法识别：
SOURCES=/home/test/project/sources
OBJECTS=/home/test/project/objects
$(OBJECTS)/%.o:$(SOURCES)/%.c
$(CC) -fPIC -c $^ -o $@
sharedlib: $(OBJECTS)/%.o
$(CC) -shared -o libsharedlib.so $<
当我运行 make 时，我发现目标没有规则：$(OBJECTS)/%.o需要sharedlib. 虽然规则是在 sharedlib 之前写的。
我继承了一个遗留项目，它利用 *.lib 中的一些外部函数。据我所知，使用 *.lib 的语法是正确的，并且可以在他们使用的任何 Visual Studio 版本中构建。（即有一个extern“C”原型文件，并且所有函数签名都是正确的）。
构建时，我收到“错误 LNK2019：函数中引用的无法解析的外部符号 _A86_ReadConfigReg@12”
我非常有信心这与 *.lib 文件有关，因为 *.lib 文件的名称中包含“A86”...还有一个同名的 *.dll。
我转到项目属性 -> 链接器 -> 输入并在“其他依赖项”中列出 *.lib 文件名，但没有运气。我尝试添加包含目录，将 *.lib 和 *.dll 复制到可执行位置。但没有运气。
我该如何修复这个错误？
我可以在我的库项目中加载外部库吗？如果是。我怎样才能做到这一点。与 Q 库？或者通常包含在 pro 文件 LIBS += -L /lib -lmylib 中并将 *.h 文件添加到项目中？
对不起我的英语不好））））
我正在尝试在以下机器上运行 Quartus 13.0：
parrot 4.18.0-parrot10-amd64 #1 SMP Debian 4.18.10-1parrot10 (2018-10-06) x86_64 GNU/Linux.
我已经完成了 Quartus 13.0 的安装，当我尝试执行它时出现以下错误：
quartus: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory
我已经阅读了堆栈溢出和其他网站中的所有相关问题，但没有人为我工作。
在寻找那个文件时，我找到了它。我试图做一个硬链接，但它也不起作用。搜索结果：
??[pepbd@parrot]?[~]
???? $ls -ld $(locate -r libpng.*\.so.*)
lrwxrwxrwx 1 root root 19 nov 19 17:09 /usr/lib/x86_64-linux-gnu/libpng16.so.16 -> libpng16.so.16.34.0
-rw-r--r-- 1 root root 210864 jul 10 13:17 /usr/lib/x86_64-linux-gnu/libpng16.so.16.34.0
-rw-r--r-- 1 root root 18272 oct 14 21:59 /usr/lib/x86_64-linux-gnu/vlc/plugins/codec/libpng_plugin.so